Unauthorized Tcode Access

[Former Member]

Dear gurus,

I have problem like this:

On November 2010, I see from ST03N that a user has access to tcode FBZ1.

From roles assigned, that user has no access to that tcode (I saw in menu and auth object S_TCODE).

I tried to login as that user, and I can't directly access by typing FBZ1 from the tcode shortcut.

From SUIM -> change document, I see there's no additional role assigned or role change to that user.

What could possibly allow that user to access that tcode?

Thanks for help.

Best Regards,

[Former Member]

Hi,

From roles assigned, that user has no access to that tcode (I saw in menu and auth object S_TCODE).

Please check if any range/wildcard maintained under S_TCODE gives access to the tcode FBZ1. Also verify if any profile is assigned to the user ID (apart from assigned role's profile) via which the user can access FBZ1.

Thanks

Sandipan

[Former Member]

There's no other profile there.

I also have checked from suim for that profile, and there's no authorization for that tcode.

The role has no wildcard for S_TCODE.

As i've mentioned before, I tried to login to that user and can't access FBZ1.

Thanks for help.

Best Regards,

[Former Member]

You might also take a look in table TCDCOUPLES, i think few tcodes call FBZ1 without checking for S_TCODE (Check Indicator= Not maintained which currently is equivalent to 'Do not Check'). Example: F-06, F-28 and F-52.

Thanks

Sandipan

[Former Member]

How can I read that table?

And how do some tcode call other tcode without checking s_tcode?

What triggers that?

Is there button from that tcode that link to other tcode?

Thanks for help.

Best Regards,

[Former Member]

Go to SE16, key in TCDCOUPLES. In the selection screen, put 'Called Transaction' as FBZ1 and execute.

In the output screen, field Calling Transactions are the one's which call Tcode FBZ1 and check corresponding value under "Check indicator" field. X- means S_TCODE checked, N- Do not check S_TCODE, Blank=Equivalent to 'N'.

Now check if user has access to any of the 'Calling Transaction' with 'Check Indicator'= Blank/N values. If they do, then there is a possibility that they execute those transactions and eventually switch over to FBZ1 from within the 'Calling Transaction' without S_TCODE being checked. Hence ST03n/SM20 shows user executed FBZ1.

Cheers

Sandipan

Edited by: Sandipan Choudhury on Jan 7, 2011 12:58 PM

[Former Member]

I see that transaction code that called FBZ1 with no indicator are: F-06, F-28, and F-52.

But that user has no authorization for that tcode too, I've checked.

Thanks for help.

Best Regards,

[Former Member]

Hi,

There are quite a few ways in which S_TCODE kernel check can be bypassed but I don't want to mention them here as of now.

Do you know if user is executing the tcode directly by writing it in the command field?

If not, please check if the user has SE37 authorization and S_DEVELOP with ACTVT=16 and Object Type= FUGR

Thanks

Sandipan

Edited by: Sandipan Choudhury on Jan 7, 2011 4:49 PM

[arpan_paik]

Have you checked the changed history for the roles assigned to user?

Regards,

Arpan Paik

[Former Member]

when you tried to login with that user and checked that you did not have access. Did you again check in ST03N if it still reported as you just tried to access the t-code?

[fernando_zamarripa]

Hi Bobby,

Please consider ST03N saves any try to TCODE access. So please check it tcode FBZ1 access was really granted.

Regards,

Fernando.

[Former Member]

Please consider ST03N saves any try to TCODE access

Have you tried this in any system? As per my knowledge ST03N doesnot records failed transaction attempts under "Transaction, program or jobstep" in business transaction analysis. Only there will be an entry under FCOD (if you select single records option) but the program name will not be FBZ1's program.

You can use SM20 read the detailed log for user and see if the transaction was started successfully or it failed.

Edited by: Sandipan Choudhury on Jan 8, 2011 11:56 AM

[Former Member]

ST03n should not be mistaken for an audit log because it was not built to be one. It records application statistics and their response times, it also compresses the data and renames it

- an audit log should never manipulate data!

So it's your own fault (Bobby) for being confused

Although ti be fair some tools want to "sell" it as an audit trail for themselves, but that is also own fault for believing tge sales pitch.

How the S_TCODE confusion works is that entering it via the ok-code command window or a role menu will first check aurhority in the kernel before starting the application transaction at all --> no record in statistics because the application never started at all.

When navigating, or call transaction or leave to transaction is used, the tcode is infact also starting the application to there are response statistics for it. If the same "not authorized" message is returned during the initialization events of the transaction, then it might look the same to the user but under the bonnet it is different. If you see a very fast response time with only one dialog step, then this is likely to be what happened.

If the message is only a warning or there is no message at all... then the tcode can infact be started and you will see more steps and response time stats.

You can use this in forensics, but it is not an audit log, despite what people might try to convince you of.

Cheers,

Julius

[Former Member]

It is as Julius said.

I don't see FBZ1 appear in ST03n when I tried to login as that user and retry the scenario.

But still, one problem remain unsolved is how could that FBZ1 appear as accessed in ST03n back then.

As I know, that user indeed called transaction FBZ1 and post incoming payment.

Thanks for help.

Best Regards,

[Former Member]

Hi,

Can you verify in SM20 log if the tcode was really started or it failed? There are some methods to bypass S_TCODE Kernel check, (a function module is atleast one of them that I know of), not sure if the user executed the transact from the command field or via one of those methods. Do you have any idea?

[Former Member]

What you are looking for is what happened immediately prior to the FBZ1 call.

If you are fast enough you can get this from transaction STAD before the aggregation takes place of the ST03N data. There are lots of other "skid marks" in the system as well, but the correct tool is as Sandipan has mentioned --> SM20N.

You can also try looking for variant transactions of it in SHD0 or where-used-lists for programmatic calls (though this does not help much if the value is a variable from some data declaration or worst-case a user input...).

However you should not forget that you are basing this wildgoose chase on information from ST03N which is not an audit log. It is certainly not reliable and chances are good that the user did not do anything wrong nor even knows about this.

You must be carefull with such data and drawing conclusions from it!

The most important question: What was the response time and how many steps took place in FBZ1?

Cheers,

Julius

[Former Member]

Dear all,

The system do not have audit log enabled, so there's no data in SM20.

For in ST03N, the steps were 236, response time was 121.

Best Regards,

[Former Member]

Hi Bobby,

As Sandipan and Julius mentioned, you should use SM20N for exact log of transaction run.

Regarding your query:

User may have got the access to unauthorized TCode by Reference user assigned to it. Did you check that any refernce user with that access wasn't assigned to that user?

Regards,

Mohit

[Former Member]

Dear Mohit,

There's no reference user assigned.

We do not have audit log enabled, so it's not good.

Regards,

[Former Member]

Hi Bobby,

I am not giving you a solution as i dont have one, but i can tell you a similar experince i have and a post i found on the forum that gives me a logical reasoning.

I have a set of users who DO NOT HAVE access to the transaction MIRO, but when i run the report of the vendor postings made FBL1N, i find the users name in the list. and when i see the overview of the documents they posted, SAP shows that the user used MR1M transaction to make the posting. here is the tricky part, In ECC6.0 MR1M doesn not exist, then why does it register MR1M as the transaction used........i did my research and here is something i found that gives me a logical answer

[;

in our case....i checked with the users and they indeed were re-procesing IDOC's

maybe, it could help you in your analysis

[andrzej_kloc5]

This message was moderated.

[Former Member]

This message was moderated.

[Former Member]

Check with T_Code: SE97, whether User getting FBZ1 access from other calling transactions.