Access issue

[former_member349600]

Hi Gurus,

Is it possible that user can do lock and unlock for the userid but he cannot change the password of any user.Because as far as I know if the user has change access he/she will have the access for lock/unlock and change password.

Edited by: Pradeep raghav on Sep 21, 2011 8:38 AM

[arpan_paik]

What you did on your own to satisfy your own question?

Regards,

Arpan Paik

[Bernhard_SAP]

Hi

you can create a transaction variant of su01 w/o the password features. Search for shd0 to find some hints on that.

b.rgds, Bernhard

[Former Member]

Hi

you can achive using User group authorization

1. Create a user group ex : Security and assign to all security team members

2. Create a role and maintain S_USER_GROUP

Maintain all user groups excluding "security"

if you assign this role to the security team then they can not able to lock/unlock./pwd reset of their own, but they can reset other groups userids

Regards

Hari

[Former Member]

Hi
> 
> you can achive using User group authorization
> 

No you can't. That will not allow you to differentiate lock & unlock 'vs' password reset for a given set of users.

[Former Member]

HI Alex,

your message was not clear throughly. What I know is, even by restricting with user group, we can still change the password of that user.

[Former Member]

Hi Plaban,

As standard we cannot segregate the activities of lock/unlock and password reset - they share the 05 activity.

S_USER_GRP will allow restriction of activities to groups of users but activity 05 still permits both lock/unlock and password reset unless you take a customising approach.

[Former Member]

Hi alex,

i do not think, value 05 in S_USER_GRP will provide password reset access. i.e if 05 is NOT provided, then also password reset authorization is available.

Edited by: Plaban Sahoo on Sep 22, 2011 3:03 PM

[Former Member]

Hi alex,
> i do not think, value 05 in S_USER_GRP will provide password reset access. i.e if 05 is NOT provided, then also password reset authorization is available.
> 
> Edited by: Plaban Sahoo on Sep 22, 2011 3:03 PM

This does not look right. Test it and you will see lock/unlock and password resets both needs 05.

[Former Member]

What a strange thread...

Luckily Raghav has never closed any question he ever asked on SDN yet, so the show can still go on for a while

[Former Member]

Hi Pradeep

You can use T-code EWZ5. This t-code is used for mass user locking and unlocking.

Thanks-

Guru Prasad Dwivedi

Edited by: guruprasaddwivedi on Sep 21, 2011 4:36 PM

[Former Member]

Hi Pradeep
> 
> You can use T-code EWZ5. This t-code is used for mass user locking and unlocking. 
> 
> Thanks-
> Guru Prasad Dwivedi
> 
> Edited by: guruprasaddwivedi on Sep 21, 2011 4:36 PM

I would like to add that this transaction must be used really, really, really carefully! It is so easy to lock all users in the system. To be honest I wouldn't allow this for anyone who wasn't an uber security administrator (and even then only on a temp basis).

[Former Member]

Hi Alex

Considering the possibility of ranged tcodes in support roles - would this be one for SM01 in that case?

Regards

David

[Former Member]

Hi

EWZ5 is very dangerous and sensitive tcode, if you not sure how to use then will be in trouble

[Former Member]

Hi Alex
> 
> Considering the possibility of ranged tcodes in support roles - would this be one for SM01 in that case?
> 
> Regards
> David

To David: Sorry to go a little off-topic. Was thinking if EWZ5 is with security admin and so is SM01 then is it not a SOD issue? Though I understand the benefit of locking EWZ5.

To OP - There is quite a recent article in Security by Raghu Boddu which explains transaction variant for SU01 using SHDO for almost the same case as you have. His article mentions both the features lock/unlock and password reset..for your case you can just enable one you need.

[Former Member]

Hi David,

EWZ5 requires the usual unlock auths (and possibly more - I don't have a system immediately available with EWZ5) so will be controlled by standard sec objects to restrict. Assuming that it's not the sec roles that are ranged in prod (big assumption ) then should be sufficient level of control without resorting to locking the tx.

It's surprisingly common to hear people who have run the lock without excluding their own user. But for the grace of God I've managed to avoid it so far. In PRD at least.....

[Former Member]

Hi Alex

I'll add this to my notebook for future reference

From a system I currently have access to the unvalidated SU24 entries are:

S_DATASET Authorization for file access Check NO

S_DEVELOP ABAP Workbench Check NO

S_TCODE Transaction Code Check at Transaction Start Check NO

I've had some fun (in threat-ro-spect) seeing my own access swallowed by an enthusiatistic LSMW deleting roles which happened to include me but my reference user still lived on to rescue me so I appreciate the open-eyed OMG stare something bad like this may produce...

cheers

David

Edited by: David Berry on Sep 22, 2011 7:42 PM