Segregate duties and disallow user to modify user

[Former Member]

Hi All;

Please advise if l can do the following:

1. Segregate the duties among the security administrator; mainly for the following tasks;

a. User administrator

b. Authorization administrator

c. Activation administrator

2. Ability to disallow security administrator to modify their own user records

Thanks

Jordan

[Former Member]

Jordan,

I n many companies they follow

User adm is taken care by other team(help desk) / Role base security is taken by other team.

even password reset / lock and unlock user id can also be restricted.

Activation adm = Profile generating

even this is also possible

One user will create a role upto tcode level

another person will generate role.

Best practise to give to one person / team.

Assigning of SAP_ALL / SAP_NEW you can restrict (few them will have this type of authority)

what modification will security person will do?

Let say security person will add basis role to his user buffer, it will be done in development but not in production system, right?

Ps: Best way to start is know the object and how they work for particular transactions(SU01/ PFCG)

Thanks,

Sri

Edited by: sri on Aug 5, 2010 11:14 AM

[Former Member]

Hi,

This is achievable. You control it via the S_USER* auth objects e.g. S_USER_GRP, S_USER_PRO, S_USR_AGR. Read up on the objects via SU21 and you will be able to design restrictions to suit your requirements.

The only one I am unsure of is c. activation administrator. What is activation adminstration?

[Former Member]

Activiation administrator? guessing

Probably just locking and unlocking a user and changing the validity date.

[Former Member]

That's what I thought it could be but have also been at places where they had 1 poor guy who would be responsible for activating profiles (and then latterly generating roles). Maybe the OP will clarify

[Former Member]

Dear All;

Thanks for the contribued information, however l still can't think how to disallow Security Administrator to modifying their own user records.

Image if l am the authorization administrator, l can just create a ZZZ role and assign the tcode Su01, then add his own user into the role ZZZ, then he can actually modify everything.

If l stop the authorization administrotor to create/modify the role, then he can't perform his function as a authorization administrator.

Please advice.

Thanks

Jordan

[Former Member]

Then you didn't read the documentation as suggested earlier.

Please do that and then we are at least on the same "wave length" here...

For the SU01 example you gave, you can also take a look at object S_USER_TCD in addition to the others.

Cheers,

Julius

[Bernhard_SAP]

> Image if l am the authorization administrator, l can just create a ZZZ role and assign the tcode Su01, then add his own user into the role ZZZ, then he can actually modify everything.

Only if the authorization adminstrator is able to assign users to the role, which rather is a task of the user admin --> S_USER_GRP limitation

b.rgds, Bernhard

[Former Member]

Jordan,

In addition to Bein, you can create couple of roles(su01) -> S_USER_GRP, try with different activity values.

And see what we can restrict.

Thanks,

Sri

[Former Member]

in case you want the auth administrator to assign roles also then you willl need to assign the auth adminstrator to a particular user group and then skip this group from the object S_USER_GRP .

[Former Member]

This is possible but it will be suggestable if you have lot of SAP users in your organization . if the number of users are less then it might not be costeffective way of having different team do differnt task .

[Former Member]

This is achieveable. See the FAQ sticky thread at the top of the forum for the SAP note which explains how it works.

> c. Activation administrator

I assume this refers to maintaining the roles of the previous 2 functions (for objects such as S_USER_VAL) and having access to more activities for S_USER_OBJ, config of CUA, the security params and various customizing tables, creating transactions, performing some of the SU25 upgrade steps, approving security related transports, etc. Bar the restrictions on S_USER_VAL (see the documentation in transaction SU21) you can achieve this as well but it is a considerable effort.

Cheers,

Julius

[arpan_paik]

I have seen this approach and worked as well in this model...However all I can say is that SAP Security is itself is small area to wrok on in normal support. Segregating it more deeply will increase resource, ideal time, less knowledge contribution among team member..