Restrict SU01 usage

[Former Member]

Dear Gurus,

I'll have one scenario need your expertise idea and guidance.

I'll created one id with authorization roles SU01 included there.This id purposes for backup to reset /unlock the password if the sap admin not around.My problem is this id manage to reset the sap admin password.How to restrict this id with su01 access but its cannot reset/modify the admin password.its only can reset or modify the users id.

can it be done using auth.object.

Please help me...

Thanks an advance

/Shah

[Former Member]

HI,

You can restrict Su01 by setting authorization objects activity values.

first check the aurthorization objects functionaliy and map the activities for that.

-Srini

[Former Member]

Thanks..

But in auth.object its only have a accessing functionality like 01-create,03-display.any ideas how to restrict this roles cannot change/reset the sap admin.because if i take out the create or modify means its apply to all users and admin id right.

Please help me..

Thanks

/Shah

[Former Member]

Hi,

As per your query you can not define to reset all user password rest of admin.

Anil

[Former Member]

HI Shahril,

Yes, you can restrict the user, so he can't change admin user password.

For that first create one user group using t.code SUGR and assign all user to that group except your admin users. Assign SUPER group to your admin users.

Now create new role for SU01 and and in object S_USER_GRP assigne the group name which you had created.

It will work as per your requirement.

Regards,

Nisit

Edited by: Nisit Patel on Jul 23, 2010 7:21 AM

[Former Member]

Hi,

Thanks for the solution given.

But Nisit I'll follow all your steps,but still cannot.Is it have a steps i missed it or need to configure another object.

Please advice.

Thanks

/Shah

[Former Member]

Hi,

Please create role for SU01 with following Authorization Object and parameter.

S_USER_AUT

Activity 03, 08

Authorization name in user mas *

Authorization Object *

S_USER_GRP

Activity 05

User group in user master main ZGROUP

S_USER_PRO

Activity 03, 08

Auth. profile in user master m *

S_USER_SAS

Activity 01, 06, 22

Role Name *

User group in user master main *

Auth. profile in user master m *

Receiving system for central u *

S_USER_SYS

Activity 78

Receiving system for central u *

S_DEVELOP

Activity 03

Package MGA

Object name *

Object type *

Authorization group ABAP/4 pro *

S_ADDRESS1

Activity 01, 02, 03, 06

Address Group (Key) (Business BC01

S_OC_ROLE

Text field length 15: authoriz *

Please let me know the updated status.

Regards,

Nisit

[Former Member]

Hi Nisit,

Already followed your instruction but still cannot solve it.the sap admin id still can lock/unlocked and change a password.

Please advise...

/Shah

[Former Member]

Hi,

Already i informed you this is not posible because you can restrict only edit,delete,change,display etc instead of any user name.

Anil

[Former Member]

As mentioned nisit, please do follow;

More Details : you can manage users by assiging the users to group and in S_USER_GRP you need to give only those user groups which you want to maintain.

Example : in "S_USER_GRP " give all the values except SUPER; and for admin id you assign user group as "SUPER"

To Test id ; only give the role in which it has values of S_USER_GRP as mentioned.

Also make sure Test id is not getting Authorization "S_USER_GRP = SUPER from other roles and probaly it will work

Thanks.

[Former Member]

If the user ID is locked, then it needs a new password and an unlock - right?

To lock a user's password, just enter an incorrect one 5 times or so and the task is done. You can also script this easily for the admin to lock the password. NOte: This does not lock the account - only the password.

Cheers,

Julius

[Former Member]

Hi Shah,

The easiest way to do this is utilise user groups. What you will need to do is assign your 'high privileged' users to a user group within the SU01 transaction. Do this per user master record in the Logon Tab in SU01 in the User Group Field. For example, you can assign all the users you want to protect to 'SUPER' or 'ADMIN'.

Then you grant access to reset passwords to all but these user groups. So if you decided to assign these users to SUPER then give your password reset access to S_USER_GRP, ACTVT = 05, CLASS = A - R* and T - Z*. This allows the users with this range to reset passwords of all user groups except the SUPER group.

Hope this answers your question. Warm regards,

Jamie

[Former Member]

Hello:

I think all you need to do is assign this user to SUPER user group in logon tab of SU01. Now this user can maintain any user except users belonging to SUPER user group.

If I recall what i read very long ago, like 3 years, users belonging to SUPER group can not maintain each other. This may have changed since then.

But try the above and report it here.

[Henrik1]

Assiging the user to user group SUPER, and not letting the user have access to that group will fix your problem. S_USER_GRP restricts access by user group, but you cannot restrict access if users are not assigned to a user group. So make sure you incorporate mandatory use of user group for all users into your work instructions.

05 is lock/unlock & reset password - there is no way of segregating those actions.

Hope that helps

[Former Member]

Hello Indiana Jones,

> If I recall what i read very long ago, like 3 years, users belonging to SUPER group can not maintain each other. This may have changed since then.

>

> But try the above and report it here.

Apparently if you delete the entire database the SUPER user can logon still and change other SUPER-user's passwords. Please try it and let us know how your system is...

--> You should try it before posting such mythology...

Cheers,

Julius

[Former Member]

Dear All,

I think this issues has been resolved.I'll follow the steps given by Jamie.And its working.

Thanks to all.

/Shah

[Former Member]

Awesome Spellburgh!

Edited by: Uday Kumar on Aug 9, 2010 9:51 PM

[Former Member]

Glad you enjoyed it...

Did you try? The hard-coding of 'SUPER' was not a sustainable idea in my opinion, because it is easy to change and is not at the end of the ALPHA range...

Even protected users such as SAP* and DDIC have been relaxed because hardcoding exceptions cannot be done consistently for such users.

Cheers,

Julius

[Former Member]

Please also take a look at SAP Note 312682 (entries in table PRGN_CUST can influence authority-checks to enable more granular segregation).

Cheers,

Julius