S_USER_GRP showing in SU53 in non security related transactions

[former_member532485]

Hi All,

In a number of diffeernt Basis Release 7 systems, i have come across many cases where users are getting auth errors and when they send me the SU53 it is showing S_USER_GRP with activity 05 (Lock) is missing for the user group of the user that experiences the problem.

In nearly all cases, the error cannot be addressed without assigning this object and values even though the transaction(s) in question has nothing what so ever to do with any security related transactions.

Has any one come across this before and found out the underlying reason why?

I suspect it is something similar to the frequent appearence of object S_CTS_ADMI in SU53s in earlier releases.

Thanks,

Mark

[Former Member]

hi,

have u tried running ST01 Trace ??

[Former Member]

Hi Mark,

Run the report RSABAPSC to detect all the AUTHORITY CHECK for a specific transaction or program.

[Former Member]

Hi Mark

Please check table USOBT_C for list of transactions for which check for object S_USER_GRP has been enalbled in SU24.

Krishna: Thanks for sharing the report name.

Thanks

Anjan

[Former Member]

I've not got to the bottom of this one yet but have never had to assign the S_USER_GRP auths to get it to work. #

What works for me is running a trace/debugging to pick up the important checks. I often also have a role with S_USER_GRP in it that I can assign to get over the "spurious" check and onto the important ones that prevent processing.

[Bernhard_SAP]

Hi,

S_USER_GRP is necessary in SU53 to verify, if other users failed checks should be accessible or not (with F5). As far as I remember it's a hidden check, so it won't show up in ST01....

b.rgds, Bernhard

[Former Member]

Hi Mark,

I realize this is a few years old post and I hope that your issue has been addressed and resolved since then.

However, I've ran into very same issue today and I strongly believe why this has occurred and thought I'd put it out there for anyone else who maybe encountering or may encounter it in future.

One of our Finance user ran into this issue with object - S_USER_GRP, while trying to update notes for a customer. The reason for this error occurrence was that the original note was entered by another user who is no longer with the company and that user has been deleted from the system! Because the user record is not found in the user master, it was throwing this error as it was trying to authenticate against the original user. Once I reinstated that useru2019s account (although account is disabled and validity date is set to termination date), the users in Finance were able to update the record quiet happily.

I hope this helps.

Regards,

Nabil Kazi

SAP BASIS & Security Admin

[Former Member]

Very close and on the right track..

The exact reason is that in many such cases the system wants to do an existence check on the user name and for this attempts to retrieve some of the details of the user via BAPIs.

Up until [SAP Note 1646257|https://service.sap.com/sap/support/notes/1646257] the BAPI by default also requested information about the password hash and it's version and this information is protected by the S_USER_GRP '05' check as it is critical enough to be equivalent to the ability to change the password or eventually obtain it. It is certainly more than display.. If the check fails then it does not return this information which is not needed anyway, but as a consequence "makes noise" all over the place in SU53.

As SU53 (may the fleas of a thousand camels infest it's armpits) always gives the last failed authority-check and not the real one which first failed nor the sequence, it will always show this as being the missing authority and you are forced to grant it to be able to get to the real one (or the previous last failed one...).

The same happens with objects such as S_CTS_ADMI 'TABL', S_TRANSLAT, S_DOCU_AUT, S_PROJECT, etc etc.

If you build roles correctly, then SU53 will become mostly useless. But the specific case of S_USER_GRP has been solved (see above SAP note).

Cheers,

Julius

Edited by: Julius Bussche on Feb 24, 2012 9:31 AM

[Former Member]

This message was moderated.