PFCG & SU01 - Prevent user from maintaining own data ~

[rwarri1]

Hi folks,

Would like to know if anyone has implemented functionality to restrict administrators from maintaining their own data. I have read that his can be done by creating/assigning specific user groups, modifying the roles to include a specific group.

Any other solution ? Enhancement points, user-exits..

Thanks,

Rajesh Warrier

[Former Member]

Hi Rajesh,

Yes you can do enhancement to Functions, use-exits and achieve this. But there will be negative impacts.. like more maintenance effort, problems during upgrades which includes enhancements to functions or user exits used. Its not wise to modify sap delivered functions or exits when we have alternative solutions.

The best way is to use the groups in this case.

Regards,

Ajesh.

[rwarri1]

Hi Ajesh,

Thanks for  you reply.

Are you aware of the specific enhancement/user-exit which can achieve the required functionality ?

You mention that there will be negative impact with enhancement/exit. Can you elaborate more on this.

Cheers !

Rajesh

[Former Member]

Hi Rajesh,

For modifications first you can check for any existing BADIs for the T-code. If doesnt exist you can go for enhancement or user exits.

Disadvantages of doing a enhacement when you have a alternate solution:

1. More development work, thus creating tech specs, func specs, testing....

2. When you upgrade your sytem and these enhancements may be changed overtime (not always)and you might need to do some maintenance. Test to see if its working after the upgrade also. There will be always be risk involved during upgrades with lot of enhancements in the system.

3. The more enhancements you have in the system, more difficult to manage them and to upgrade the system.

To find the Enhancements (BADIS, user exits and others) available for a T-code:

Goto SE93--> Enter T-code  & execute --> Copy Package

Then Goto SE84--> Node ENHANCEMENTS--> Select BADIS, Enhancements or User Exits--> Execute for the given Package--> Result will show the appropriate enhancements available

Hope this answers your question. To find more details on enhancements you can check with your Abapper.

Regards,

Ajesh.

[rwarri1]

Thanks Ajesh. Unfortunately this does not help as we could not find an appropriate enhancement spot / user -exit.

Will have to look at restriction via user groups and roles.

Regards,

[Former Member]

it doesn't make sense to me.  If an administrator wanted to be malicious, he could just assign roles to someone else, change the password, and use that other account.  Or work with someone else to commit fraud.  Or create a dummy user and assign roles to it.  This is the natural risk associated with role provisioning.   If your client is obsessed with admins assigning roles to themselves. then they could mitigate it by running a report of role assignment history by the admin group and scanning for their own accounts. 

[mvoros]

Hi,

you can also restrict role assignment based on role name. So you can split your roles into two groups. Non-critical and critical roles. The critical roles will have a unique prefix and you don't allow admins to assign any critical roles. The admins can use other accounts but they won't be able to escalate their authorization. Obviously, in this case you need to prevent any role modification in production. As you said that admin will be able to assign two business roles and commit fraud but there will be change documents with his name.

Cheers

[Former Member]

Could you tell us why you are attempting this?   When you say maintain own data, do you mean date/time defaults and parameters?   Or their own role assignments?    If role assignments, you may find a way to prevent them from assigning roles to themselves , but they can always assign roles to others who may be working with them, or to temp accounts they created.  It's a normal risk of role provisioning function.  When I've seen admin teams prevented from updating roles, it's usually due to regional reasons and achieved with user groups.

[rwarri1]

I am looking at preventing their own role assignments.

[Frank_Buchholz]

There 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

[rwarri1]

Thanks Frank. We are looking at implementing option a.

Rajesh