- SAP Managed Tags:
During the analysis of a customer incident, I tried to test the behavior of the function module BAPI_USER_GET_DETAIL where some information is restricted due to the maintenance of activity 05 (lock) in the authorization object S_USER_GRP. The customer complained that the maintained activity restricts too much information. He expected the only restriction of the password hashes as this would causes serious security issues.
SE37: BCODE, PASSCODE and PWDSALTEDHASH should be displayed as zeros as this contains no information about the password.
So, I tried to reproduce this case with the specification that a certain test user can see the password hashes for my administrator ID. As the activity 05 comes as default, I wanted to know what happens if I change the activity to 03 (display).
I created a new single role in PFCG (Z_BAPI) which included the transaction SE37 (Function Builder), assigned my test user to that role and manually added the authorization object S_USER_GRP.
Two authorization fields can be maintained in S_USER_GRP: Activity (ACTVT) and the User Groups (CLASS).
Initially the test user has no authorization to execute the function module. To find out which authorization objects and -fields are checked, I ran STAUTHTRACE for the test user and simply executed BAPI_USER_GET_DETAIL in transaction SE37.
Which authorizations came as default can be seen in the authorization fields at the inactive authorization object S_DEVELOP. STAUTHTRACE, at the bottom, shows the fields which were checked by the AUTHORITIY_CHECK. Just to find out which values must be maintained (ACTVT: 16, DEVCLASS: SUSR, OBJNAME: SU_USER) so that the test user is authorized to execute BAPI_USER_GET_DETAIL in SE37.
Afterwards I created a user group (“BAPI”) in SUGR for my administrator ID, assign it to that user group and maintain the authorization field for user groups in authorization object S_USER_GRP.
That’s it!
Said and done, I logged on to the system with my test user and executed SE37. Then I started the function module BAPI_USER_GET_DETAIL and tried to display all information from my administrator ID.
But the return table said: “You are not authorized to display users in group SUPER”.
The reason for this message was that my administrator ID was assigned to user group BAPI as a general user group. A single user can be assigned to several general user groups but there’s only one user group for authorization checks where a user can be assigned to. And this certain user group (for authorization checks) is important in this case because inside the function module BAPI_USER_GET_DETAIL checks the user group for authorization checks and not general user groups.
After I ran SU01 with my administrator ID and replaced “BAPI” in the logon-tab in the field “user group” for authorization check, everything worked as expected.
It makes a difference to which kind if user group you assign the user ID’s. In my documented case the user assignment to a general group had no effect since the user group for authorization checks has been checked. Especially in user administration topics this could cause also serious security issues if you assign the user’s ID to a wrong user group. So, please always check if everything works as expected after maintenance and assignment.
Also have a look to the following links below regarding user groups:
https://help.sap.com/viewer/0182e2bf25e64b2b9743e81300cc9764/6.04.20/de-DE/ff17ebb9ae414aaeae8257f21...
1663177 - SU01: User group as required entry field
https://help.sap.com/doc/saphelp_nw74/7.4.16/de-DE/5f/617ef4bade433b9b7290bee20bc385/frameset.htm
SE37: BCODE, PASSCODE and PWDSALTEDHASH should be displayed as zeros as this contains no information about the password.
So, I tried to reproduce this case with the specification that a certain test user can see the password hashes for my administrator ID. As the activity 05 comes as default, I wanted to know what happens if I change the activity to 03 (display).
I created a new single role in PFCG (Z_BAPI) which included the transaction SE37 (Function Builder), assigned my test user to that role and manually added the authorization object S_USER_GRP.
Two authorization fields can be maintained in S_USER_GRP: Activity (ACTVT) and the User Groups (CLASS).
Initially the test user has no authorization to execute the function module. To find out which authorization objects and -fields are checked, I ran STAUTHTRACE for the test user and simply executed BAPI_USER_GET_DETAIL in transaction SE37.
Which authorizations came as default can be seen in the authorization fields at the inactive authorization object S_DEVELOP. STAUTHTRACE, at the bottom, shows the fields which were checked by the AUTHORITIY_CHECK. Just to find out which values must be maintained (ACTVT: 16, DEVCLASS: SUSR, OBJNAME: SU_USER) so that the test user is authorized to execute BAPI_USER_GET_DETAIL in SE37.
Afterwards I created a user group (“BAPI”) in SUGR for my administrator ID, assign it to that user group and maintain the authorization field for user groups in authorization object S_USER_GRP.
That’s it!
Said and done, I logged on to the system with my test user and executed SE37. Then I started the function module BAPI_USER_GET_DETAIL and tried to display all information from my administrator ID.
But the return table said: “You are not authorized to display users in group SUPER”.
The reason for this message was that my administrator ID was assigned to user group BAPI as a general user group. A single user can be assigned to several general user groups but there’s only one user group for authorization checks where a user can be assigned to. And this certain user group (for authorization checks) is important in this case because inside the function module BAPI_USER_GET_DETAIL checks the user group for authorization checks and not general user groups.
After I ran SU01 with my administrator ID and replaced “BAPI” in the logon-tab in the field “user group” for authorization check, everything worked as expected.
It makes a difference to which kind if user group you assign the user ID’s. In my documented case the user assignment to a general group had no effect since the user group for authorization checks has been checked. Especially in user administration topics this could cause also serious security issues if you assign the user’s ID to a wrong user group. So, please always check if everything works as expected after maintenance and assignment.
Also have a look to the following links below regarding user groups:
https://help.sap.com/viewer/0182e2bf25e64b2b9743e81300cc9764/6.04.20/de-DE/ff17ebb9ae414aaeae8257f21...
1663177 - SU01: User group as required entry field
https://help.sap.com/doc/saphelp_nw74/7.4.16/de-DE/5f/617ef4bade433b9b7290bee20bc385/frameset.htm
