Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

How to find out what transaction uses OB52

john_pietrowski2
Participant
0 Kudos

If I look at S_BCE_68001420 - Information System -> Roles -> By Transaction Assignment for transaction OB52 and a specific userid, I do not find any roles containing this transaction that the user has assigned to him.  But if I log in as the user and execute OB52 I can changed things. 

This user should not be able to run this transaction and it currently does not appear on any of the menus for him.

I assume that OB52 is being used "under the covers" maybe by another transaction, or he has authority to use the authorization objects used by OB52.

How can I find out how the authority is being messed up? 

1 ACCEPTED SOLUTION

mvoros
Active Contributor
0 Kudos

Hi,

probably S_TCODE with manual value like * or O* is causing your issue. That report gives you roles with assigned transactions in menu but that does not mean user can't execute transactions not assigned to menu. There is another report that checks for S_TCODE. Even this is not precise because some transactions have additional checks defined. The easiest way to find your role is to check user's authorization buffer in SU56. You will see profile/role that gives authorization for object S_TCODE.

Cheers

3 REPLIES 3

mvoros
Active Contributor
0 Kudos

Hi,

probably S_TCODE with manual value like * or O* is causing your issue. That report gives you roles with assigned transactions in menu but that does not mean user can't execute transactions not assigned to menu. There is another report that checks for S_TCODE. Even this is not precise because some transactions have additional checks defined. The easiest way to find your role is to check user's authorization buffer in SU56. You will see profile/role that gives authorization for object S_TCODE.

Cheers

0 Kudos

Thanks for the great advice. 

I went into SU56 and found out that we were using SAP_NEW which gave users S_TCODE = * so I removed this profile and it fixed my issue.

Former Member
0 Kudos

Yep, even S_TCODE once was new...  😉

Correct usage is to delete SAP_NEW profiles after the upgrade so that the next upgrade only contains the realy new objects. Few basis folks do this unfortunately and there is no automation for it as the time of removal cannot be predicted.

Perhaps SAP should add a step 2E to SU25 -> delete SAP_NEW subprofiles. That should fix the problem by making it visible to the process.

Cheers,

Julius

ps: If your user(s) could still change the T001B table / views then there is still most likely something wrong with your S_TABU DIS / S_TABU_NAM authorizations in this area!!