Mass Password Change

[former_member759680]

Hello,

Please tell me an easy method for Mass change of Password for a large number of users. The password of all the User should be same and provided by Security Admin.

Thanks.

[Former Member]

Try using ecatt scripts. Below mentioned link has a good example.

http://www.sapsecurityonline.com/tutorials/secatt_user_create.html

[WolfgangJanzen]

> The password of all the User should be same and provided by Security Admin.

Sorry to say - but that's not a smart idea ...

If you search for the keyword "password" in this SDN forum you'll find several postings addressing / discussing this issue.

[former_member759680]

If I had to cahnge the password directly in the DB in table USR02, what would be the exact command?

[jurjen_heeck]

I'd say that's more of an ABAP or BASIS question about updating tables.

I guess you want to paste an encrypted password string directly into this table?

This automatically triggers one standard reaction here:

"Do not update tables directly."

Best explore the CATT/ECATT method.

And use a different password for every user. With a mailmerge based on your ecatt input sheet you can still communicate the password to the correct user.

[WolfgangJanzen]

You cannot do that (since you cannot calculate the salted hash value). I recommend to use the API function BAPI_USER_CHANGE for this operation (to set password as user administrator)

PS: do you know ABAP transaction SU10 ...?

[Former Member]

>

> This automatically triggers one standard reaction here:

> "Do not update tables directly."

Unless you are brave and know what you are doing

If you have to ask, get someone else to do it..........

[WolfgangJanzen]

> Unless you are brave and know what you are doing

Well, you can compare this to performing electrical work (installing wires) in your house. As long as you do not cause any problems (electric hazards, short circuits, or even fire due to overheated cables) you can feel free to do what you want. But if something happens your insurance might refuse to pay. And if someone gets hurt (e.g. a guest touching a cable) you're in deep problems ...

Well, an SAP system is more like a public building rather than a private house.

DIY is not the best strategy in that case.

[Former Member]

>

>

> > Unless you are brave and know what you are doing

>

> Well, you can compare this to performing electrical work (installing wires) in your house. As long as you do not cause any problems (electric hazards, short circuits, or even fire due to overheated cables) you can feel free to do what you want. But if something happens your insurance might refuse to pay. And if someone gets hurt (e.g. a guest touching a cable) you're in deep problems ...

>

> Well, an SAP system is more like a public building rather than a private house.

> DIY is not the best strategy in that case.

Hi Wolfgang.

I agree to an extent (although seeing the standard of commercial wiring I'm not sure I would compare it to ABAP code.....) there are risks with taking this approach.

When a BAPI or tool is available then that is preferable. Lets take the profile generator as an exampl (a bit off topic but still relevant) It very few options for automation (something role expert is trying to address) it doesn't work properly with ecatts and BAPI's are not available. By understanding how components work we can fill what are gaps in the tool via various methods.

We mitigate the risk by knowledge, research and testing. We also should know when our knowledge isn't sufficient & keep well away.

Cheers

Alex

[WolfgangJanzen]

> ... seeing the standard of commercial wiring I'm not sure I would compare it to ABAP code ...

Yep - you are right.

But regarding the "liability" it's still the same - insurances don't care about the quality of work. For them it's only important if someone can be kept responsible for it.

> When a BAPI or tool is available then that is preferable.

> ... it doesn't work properly with ecatts and BAPI's are not available.

Well, in that case SDN might be a good channel to highlight those issues. I'm totally with you that an incomplete API is useless. APIs shall be complete, well-documented, robust and extensible. So much for theory ...

[Former Member]

>

> Yep - you are right.

> But regarding the "liability" it's still the same - insurances don't care about the quality of work. For them it's only important if someone can be kept responsible for it.

Indeed it is, always important to understand all implications of "alternative" actions.

[Former Member]

> Indeed it is, always important to understand all implications of "alternative" actions.

I have my doubts about that "all" being possible. At least for "all" tables... any of which might change or the meaning of the fields could be reinterpreted, or become obsolete.

I would like to make a little confession (I hope you dont think less of me for it..) but I have from time to time directly updated user tables. I have crashed 2 sandboxes which required emergency repairs and a lot of basis help and 1 lab system, which with just one careless mouse-click in a table utility, was damaged so irreperably that no one could logon to the system. We managed eventually to get back in, but it was impossible to do anything meaningfull in it, let alone repair the system. A complete restore was required.

Imagine that happened to your production system.... or you lost all your development work...

I am not judging anybody (as I said, I have done it as well), but wanted to share some lessons learnt the hard (and unexpected) way.

Cheers,

Julius