S_TCODE check on SM30 for IMG parameter transactions

[Former Member]

Hi, all,

I have been searching for awhile to find documentation regarding this issue that I have seen before. I have looked through OSS notes, SAP library and the SAP forums but have not been able to find the documentation (or a fix for that matter).

Specifically, SAP is doing an authorization check on SM30 for parameter transactions where the orginating transaction is SM30 (for example: OX15) regardless of settings in the security tables. There are piece meal notes but nothing is specifically on point. OSS note 947557 kind of makes the same point with SE16.

I am running a SAP R/3 4.6C system.

I specifically remember documentation (I could have sworn it was in the SAP library!) regarding a hard kernel level check in cases where parameter transactions refer specifically to either SE16 or SM30.

Does anyone know of this documentation or a fix for this situation?

[Former Member]

You are perhaps mistaking this "check" for the documented fact in SU24 that if the parameter transaction does not have any entries, then the proposals of the core transaction (SM30) are pulled into PFCG?

This is standard behaviour, and S_TABU_* objects are in "basis" object classes so you are prevented by the application from turning them off... but it (contrary to popular belief...) does not influence the authorization checks in systems of transport/type = CUSTOMER.

A check on the core transaction (SM30) might happen if the parameter transaction does not specify a table or view which exists. It will stop in the screen which is meant to be skipped.

Cheers,

Julius

[Former Member]

Thanks for your response, Julius,

I knew it was going to be something amazingly easy. : )

Updated SU24 with specific C/M on OX15 and ta da! Authorization check stopped on SM30.

Thank you so much!

We were actually seeing the check in ST01.

AUT 0 <- S_TCODE:TCD=SM30

AUT 0 <- S_TABU_DIS:ACTVT=02,DICBERCLS=GC

Now I just have to update 1900 other transactions ; )

[Former Member]

Yes, you should not build roles from traces...

In this case, the paremeter transaction defaults an EDIT parameter together with the view aswell (actvt 02). That is why you see it in the trace, to determine how the system reacts to it - based on your authorizatzions, system settings and "behaviour" even.

The system checks a lot of stuff in the same program for a vast array of transactions. If you tune the proposals in Su24 for the correct values after investigating them for that which you use (visible entry points), then you can re-use them again. So maintain SU24.

If the SAP values (SU22) are misleading or a dog's breakfast, then ideally you should report it to SAP to fix it in the real original system... (in Walldorf

The alternative is that all your colleagues and all their equivalents over the world will ask the same question... or just pop a * into it eventually...

Reconsidering the choice of transaction is sometimes also recommended.

Good luck,

Julius

[Former Member]

> Specifically, SAP is doing an authorization check on SM30 for parameter transactions where the orginating transaction is SM30...

Also, where are you seeing this check?

If you are seeing it in SM20 / SM20N then it is correct, but the context of the calling parameter transaction is not recorded.

Your should not build roles based only on audit logs and traces...

Cheers,

Julius