access to SU01 but only for lock/unlock users

[Former Member]

hi

i want to give access to few Service desk colleagues for lock/unlock passwords in su01 where as all other options should be disabled.

i could see one of the solution as:

you can do this with the authorization object S_USER_GRP, activity 05

additionally you need the auth.object P_TCODE and S_TCODE, both with tcd SU01

Please let me know how to do this step by step (which t-codes)??

Thanks

Rocky

[Former Member]

You just have to create a role and add the tcode SU01. When you go to the authorization tab into the auth object S_USER_GRP - just assign activity 05 - you may want to add 03 as well for display. All other auth objects can be assigned 03.

[Former Member]

>

> You just have to create a role and add the tcode SU01. When you go to the authorization tab into the auth object S_USER_GRP - just assign activity 05 - you may want to add 03 as well for display. All other auth objects can be assigned 03.

Also note that, it will also enable them to reset passwords of users also.

Regards,

Zaheer

[Former Member]

> Also note that, it will also enable them to reset passwords of users also.

Unless the password has been deactivated (which removes the valid code version and deletes the hash), then '05' is not sufficient.

Cheers,

Julius

[Former Member]

>

> > Unless the password has been deactivated (which removes the valid code version and deletes the hash), then '05' is not sufficient.

Julius, i didn't get that deactivation stuff.

Do you mean with password deactivated, 05 is not sufficient for password reset ?

Regards,

Zaheer

[Private_Member_119218]

>

> Julius, i didn't get that deactivation stuff. 
> Do you mean with password deactivated, 05 is not sufficient for password reset ?
> 
> Regards,
> Zaheer

I think Julius is mistaken this time.

I just ran a trace for authorizations as I was setting a password for a user whose password was deactivated and it only checked object S_USER_GRP for this: CLASS= ;ACTVT=05;

So 05 is enough for password reset in all cases. Unless I misunderstood what Julius meant. In that case - shame on me.

(Running R/3 4.7 on 620)

[Former Member]

Lets wait for Julius....

Well he might be sleeping rite now and m also heading for that

Regards,

Zaheer

[Bernhard_SAP]

...you are right... 05 is sufficient for 'reactivation' (which is in fact done by setting a new initial password).

b.rgds, Bernhard

[Former Member]

Thanks Bernhard Hochreiter... guess we don't have to wait for Julius 😛

hope that answers your query Kashyap

[Former Member]

> Phoenix wrote:

> Lets wait for Julius....

> Well he might be sleeping rite now and m also heading for that

Okay okay... you guys are correct and the round of beers is on me

I was confused by the deactivation of the password, which requires ACTVT = '02'.

Sleep tight

Julius

[Former Member]

Aha... he is still up

Thanks for the clarification dude

Gud nite !!

[Private_Member_119218]

>

> Okay okay... you guys are correct and the round of beers is on me 
> 
> I was confused by the deactivation of the password, which requires ACTVT = '02'.
> 
> Sleep tight 
> Julius

I'll have to contradict you again. Password deactivation requires ACTVT = '05'.

(I apologize if it appears that I'm making a sport of this. I'm not.)

[Former Member]

I agree....

http://help.sap.com/saphelp_45b/helpdata/en/52/671725439b11d1896f0000e8322d00/content.htm

Julius...wake up !! Its not over yet

[Former Member]

Ohhh... this is going to be an expensive round. Perhaps I should just call it a day and go back to bed

But, as there are different ways of deactivating a password, there are also different checks. '05' is only one of them:

- Deactivate your own password in transaction SU3 => no checks, as you already must have known the password you are deleting.

- Deactivate the password programatically (and remotely) using BAPI_USER_CHANGE => checks ACTVT = '02'

- Deactivating the password from the administration transactions (SU01 & Co) => checks ACTVT = '05'.

- Deactivating a password in the debugger => ... S_DEVELOP...

- ...

I think we are way off topic now (which is my fault).

Cheers,

Julius

PS @ Zaheer: Are you on release 4.5B?

[Former Member]

My system (ECC6) will not deactivate a password without activity 02 and 05

[Former Member]

Hi Alex,

Instead of hitting the change button (which invokes the '02' check) to make the deactivate button visible on the logon data tab, click on the "Password" button directly in the entry screen => you can deactivate it there with only '05'.

The others are correct. I did not know that either.

Cheers,

Julius

[Former Member]

Ah yes, I see if you go in that way then it's only 05.

[Former Member]

good to see everyone's involvement, so shall i consider it as solution:

You just have to create a role and add the tcode SU01. When you go to the authorization tab into the auth object S_USER_GRP - just assign activity 05 - you may want to add 03 as well for display. All other auth objects can be assigned 03.

[Former Member]

>

> good to see everyone's involvement, so shall i consider it as solution:
> You just have to create a role and add the tcode SU01. When you go to the authorization tab into the auth object S_USER_GRP - just assign activity 05 - you may want to add 03 as well for display. All other auth objects can be assigned 03.

Either that, or as we have learnt here, you can also only give ACTVT = '05' only for the user group which the ID's are assigned to. That way user ID's can be selected using F4 (or known anyway) and reset passwords / (un)lock, etc by these admins from the first screen of SU01 only - in other words, without ACTVT = '03' for the user group, they cannot proceed further and are limited to the buttons on the first screen.

Cheers,

Julius

[Former Member]

i hope this discussion is going in another direction, so please create another forum for this issue,

so that users can serach this issue in future for reference.

thanks for suggestion, i appreciate it.

Regards

[Former Member]

Let me jump in on this melee ...

I assumed from the question that this may be a setup for "helpdesk" support. Another approach I have taken is to create a custom transaction variant and taken out all of the unnecessary buttons, etc. and assigned only activity 03 and 05 on S_USER_GRP - that way if the helpdesk needs to validate info for the user id then can check it in display mode and only do password resets and unlocks. The custom variant gives them a "clean" screen to work from.

[Former Member]

> JC wrote:

> Let me jump in on this melee ...

> I assumed from the question that this may be a setup for "helpdesk" support.

Or... for a "machine operator".... so another approach, if the root cause of this requirement is password locks by folks "having fun".... => then eliminate the password.

See , particularly toward the end of it.

Why else would they want to unlock but not want to (and should not be able to!) change the password.........?

I think I am slowly waking up now

Cheers and enjoy the weekend,

Julius