Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

access to SU01 but only for lock/unlock users

Former Member
0 Kudos
3,679

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

1 ACCEPTED SOLUTION

Former Member
0 Kudos
736

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.

21 REPLIES 21

Former Member
0 Kudos
737

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.

0 Kudos
736

>

> 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

0 Kudos
736

> 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

0 Kudos
736

>

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

0 Kudos
736

>

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

0 Kudos
736

Lets wait for Julius....

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

Regards,

Zaheer

0 Kudos
736

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

b.rgds, Bernhard

0 Kudos
736

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

hope that answers your query Kashyap

0 Kudos
736

> 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

0 Kudos
736

Aha... he is still up

Thanks for the clarification dude

Gud nite !!

0 Kudos
736

>

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

0 Kudos
736

0 Kudos
736

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?

0 Kudos
736

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

0 Kudos
736

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

0 Kudos
736

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

Former Member
0 Kudos
736

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.

0 Kudos
736

>

> 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
0 Kudos
736

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

0 Kudos
736

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.

0 Kudos
736

> 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