You want more control over who can create, change and assign roles to which users in a particular SAP system. This can be done relatively easily using user groups and the authorization objects S_USER_GRP and S_USER_SAS. We will show you how to proceed.
There are many reasons to restrict user administration in individual SAP systems: You have organized user creation and maintenance decentrally and the admins should only be able to edit users from their area. Or you work with an IDM and want to prevent users from being created and edited directly in the system.
The easiest way to restrict this is via the user groups that you can assign to each user in the user master (transaction SU01). This is not a mandatory field by default. If you want to restrict user administration via the user groups, you must change this. But this is the last step.
Create user groups
First create the user groups that you want to use in the future (Transcation SUGR), if they do not already exist in your system.
We use three user groups in our example:
- STANDARD for all dialog users
- TEST for test users
- TECH for technical users
Only test and technical users should be able to be created directly in the system later on. Standard users are managed via an identity management tool (IDM).
Add users to user groups
For the user administration restriction to really work later, ALL users in the system must be assigned to a user group. Users without an assignment are otherwise automatically assigned to the default group that you defined in the last step.
To get an overview, use transaction SU10 and click on the “Authorization data” button. Double-click in the “Group for authorizations” field and use “=” to select all users who do not have an entry in the “User group” field.
Now assign the correct user group to these users. Mass assignments are possible directly in SU10. You can also assign the group to individual users via SU01.
Pronounce S_USER_GRP correctly
Now create a new role or use a suitable existing role to define the authorization object S_USER_GRP.
The admin who is assigned this role should be able to freely manage users with the TECH and TEST user groups in this system in future. They can therefore create, change, delete, block, assign and so on. However, normal dialog users are managed in this system via an IDM. To prevent synchronization errors, these users should be blocked for maintenance in the SAP system itself. The admin only gets a display view for their user master records.
Correctly characterize S_USER_SAS
User administration is fully covered by S_USER_GRP alone. However, this does not apply to role administration. Previously, you could only restrict the role assignment via S_USER_AGR. Here, however, the restriction was only possible to individual, specifically named roles. With the comparatively new object S_USER_SAS, you can also restrict the role assignment according to user groups.
In our example, the admin should also only be able to assign roles to technical and test users directly in the system. We therefore characterize the object with ACTVT: 22 (enter, record, assign) and CLASS: TECH, TEST.
Control roles and deactivate objects
To ensure that the authorizations from your new role do not come to nothing, you must now check the admin’s other roles. Make sure that he does not have any roles in which S_USER_GRP and S_USER_SAS are more extensive.
To be on the safe side, you can use the SUIM (Roles – Roles according to complex selection criteria) to display all roles that contain the objects S_USER_GRP and S_USER_SAS. Deactivate them in all roles except the one you have just created or defined. Then assign this new role to all users who are to manage users and make role assignments.
If you place user administration and role assignment in different hands in your company for security reasons, you must define and assign two different roles accordingly.
Important: Without S_USER_GRP, access to the user master is no longer possible. You should take this into account.
Make user group a mandatory field
Users to whom no user group is assigned can be maintained and changed by any admin – regardless of whether their roles contain a restriction by user group or not.
You must therefore prevent new users from being created without a user group in future. You must therefore make the user group a mandatory field. To do this, go to the USR_CUST table via transaction SM30.
Set “USER_GRP_REQUIRED” here and enter the user group as the attribute that you want to assign as the default value when users are created directly in the system. In our example, all corresponding users should be test users.
Even users who do not have a user group assignment (e.g. because they slipped through in step 2) are now automatically assigned “TEST” by the system.
Important: S_USER_SAS is activated by default in current systems. If this is not the case for you, there is no authorization check on S_USER_SAS when you assign roles, you must activate the check. This is done in the PRGN_CUST table by setting the customizing switch “CHECK_S_USER_SAS” to “YES”.
User groups: procedure for central user administration (CUA)
If your company manages users centrally, i.e. has a central user administration (CUA) in place, you must ensure that the settings in the central and child systems match. You must therefore assign the users to a user group in both systems.
If you implement the restrictions according to user groups in a child system, as described above, users that are created centrally must ALWAYS be assigned to a suitable user group. Otherwise the following happens:
- The user who enters the child system without a user group is automatically assigned the default group.
- An error message appears in transaction SCUL, which requires a valid user group assignment in the central system.
- If you change the user in the central system without it being assigned to a user group there, these changes are NOT adopted in the corresponding child system.