topic Access issue in Application Development and Automation Discussions

Access issue

former_member349600 — Wed, 21 Sep 2011 06:33:51 GMT

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

Re: Access issue

arpan_paik — Wed, 21 Sep 2011 06:38:34 GMT

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

Regards,

Arpan Paik

Re: Access issue

Bernhard_SAP — Wed, 21 Sep 2011 08:14:23 GMT

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

Re: Access issue

Former Member — Wed, 21 Sep 2011 14:04:24 GMT

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

Re: Access issue

Former Member — Wed, 21 Sep 2011 14:26:30 GMT


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.

Re: Access issue

Former Member — Wed, 21 Sep 2011 14:36:06 GMT

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

Re: Access issue

Former Member — Wed, 21 Sep 2011 14:49:28 GMT


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).

Re: Access issue

Former Member — Wed, 21 Sep 2011 16:46:46 GMT

Hi Alex

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

Regards

David

Re: Access issue

Former Member — Wed, 21 Sep 2011 17:27:35 GMT

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

Re: Access issue

Former Member — Thu, 22 Sep 2011 05:12:28 GMT

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.

Re: Access issue

Former Member — Thu, 22 Sep 2011 09:02:37 GMT

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.

Re: Access issue

Former Member — Thu, 22 Sep 2011 12:15:49 GMT


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.

Re: Access issue

Former Member — Thu, 22 Sep 2011 13:02:52 GMT

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

Re: Access issue

Former Member — Thu, 22 Sep 2011 13:08:41 GMT


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.

Re: Access issue

Former Member — Thu, 22 Sep 2011 13:36:14 GMT

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

Re: Access issue

Former Member — Thu, 22 Sep 2011 17:38:24 GMT

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.....

Re: Access issue

Former Member — Thu, 22 Sep 2011 18:41:54 GMT

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