SU01 & PFCG - Prevent admin from assigning himself a role

[former_member669881]

Hello,

how can we prevent a user admin from assigning himself roles with transactions SU01 or PFCG?

Something like the approach described here: http://www.sapfans.com/forums/viewtopic.php?t=110058

Any idea how to implement such a check?

Thanks!

Calin Barbat

[Matt_Fraser]

This is indeed possible to do. The "best practice" for this was laid out in detail years ago in the book "Authorizations Made Easy" published by the R/3 Simplification Group (I don't think they exist anymore) within SAP Labs.

At its core, the idea is that you split your user and authorizations administrators into three roles (which means you need three different people to manage this, plus a "super administrator"):

1. User Administrator
2. Authorization Profile Administrator
3. Authorization Data Administrator

The User Administrator can create, change, and delete users, change passwords, lock and unlock users, and assign users to roles, but can NOT modify or generate roles or authorization profiles, and cannot assign users to "superuser" roles, nor modify any users who are members of the user group SUPER.

The Profile Administrator can display roles and profiles, display users, generate profiles for roles, but cannot change any profiles, cannot change users, and cannot assign profiles. Basically this person is a "check and balance" on the Authorization Data Administrator.

The Authorization Data Administrator can maintain roles, and can display users and profiles, but cannot activate (generate) the profiles.

All three roles should be in a different name range than your standard end user roles. For instance, make them Y.USER_ADMIN, Y.AUTH_PROFILE_ADMIN, and Y.AUTH_DATA_ADMIN, and have all the rest of your (non-administrator) roles be Z.something. All members of these roles should be in the SUPER user group.

So, coming back to your User Administrator that you asked about, they are not able to modify any roles, and they can only assign roles that are in the Z.* range, and only to users who are outside the SUPER user group (thus, not to themselves). You can also make it so that they cannot operate upon any roles that have authorization objects in the S_U* name range, in case a role change slips through that should have been in a Y.* group.

Likewise, the Auth Data Admin and Auth Profile Admin cannot modify any users at all, and they can only operate upon Z.* roles, and they cannot assign S_U* authorization objects to roles. Plus, it takes two of them to make a change to a role: one to make the change, the other to activate it.

The final check is that your Auth Data and Auth Profile Admins should only have those authorizations in your DEV system, so all role changes have to be transported through your landscape like any other change. Assuming they do not have transport authorization, now that's a third check and balance on any changes.

Cheers,
Matt

[Former Member]

Hi Calin,

This is possible, but will require a lot of maintenance going forward with potential upgrades etc.

An alternative solution would be to schedule a background everyday to identify if user X made changes to user X

This is quite easy to do through SM36 - program RSUSR100N (SUIM) with a variant.

The above job can be set to automatically email the manager/supervisor everyday if any changes are made by user X to user X.

Let me know if you'd need assistance.

Regards

Jason

[TammyPowlas]

Hello Calin - I already replied on your earlier question, which seems to have disappeared

Please see this thread and comment from SAP's Frank Buchholz:

https://archive.sap.com/discussions/thread/3147204

"here is no way to prevent maintenance of their *own* role assignments.

However, here are some options to mitigate the risk:

a) Use different user groups in a way that a user administrator cannot maintain his own group of administrators. Only a super administrator should have the authorization to maintain the role (and profile) assignments for user administrators.

b) Restrict the authorizations for S_USER_AGR and S_USER_PRO for activity 22=assign in a way that an ordinary user administrator can only assign 'uncritical' roles and profiles. Only a super administrator should have the authorization to assign 'critical' roles and profiles.

c) Use transaction variants and even a standard transaction variant for the SU01 to block fields which should not be maintainable for specific users. Example: Note 330067 describes how to block the reference user field.

Cheers,

Frank"