MASS USERS INITIALIZED PASSWORDS

[Former Member]

I need to Initialized password of mass users for our training section every month. (maybe schedule it...)

The problem is that I know how to do this with the su01 transaction, but this is take care of only one user each time.

The transaction su10 can`t help me, because I can`t change there the passwords for those users.

I put the users in an "Authoration Group" that i called "train", but till now I did`t find a solution to change the password for them.

Thanks

Oren

[Former Member]

Use transaction SCAT or SECATT if you are working in ECC

Very simple to script a mass password update. There are instructions on sapsecurityonline.com if you aren't familiar with the CATT tool

[Former Member]

Hello Oren,

Welcome to SDN!

There are other options available to you as well. For example, [see this thread|; on mass password changes for some of the options and use the search for related terms.

Kind regards,

Julius

PS @ Alex: Have you tried a "whois" on that domain?

[Former Member]

>

> PS @ Alex: Have you tried a "whois" on that domain?

Hi Julius, I have indeed. I wonder if he is related to the famous family? Certainly been quiet on here for a while.

The list of interview questions is interesting, always good to see what to remove from my list of Q's when I am interviewing!

[Former Member]

Have you considred changing the user type to service IDs so that they won't expire after you reset the passwords?

As the other posters wrote, you can write an eCATT script for the password changes. Search online for eCATT how to; I've found some good references there.

Here's one I found; play around with it to get yourself familiarized; it's a very good transaction code to be know.

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

Also, if they're doing a training refresh every month, they (Basis) has the option of exporting the users before the refresh and importing after, so the passwords should remain the same.

[Former Member]

Hi Julie,

>

> Have you considred changing the user type to service IDs so that they won't expire after you reset the passwords?

An implication would be that people from previous month's trainings and others over time would be able to join all subsequent trainings.

>

> Also, if they're doing a training refresh every month, they (Basis) has the option of exporting the users before the refresh and importing after, so the passwords should remain the same.

You might as well set the passwords of all the users as the same pwd everytime (also using a CATT script) if you are using an "external source" to put (parts of) the user master records back, but how do you then verify which person completed the training as which user (this might even be a strict requirement for persons training evidence for "sensitive" applications).

Besides this, it might not always work, and could bring your training sessions to an unexpected standstill.

My understanding of the question is, how to reset and make the initial password known only to the user who needs the training?

Kind regards,

Julius

[Matt_Fraser]

Interesting, I hadn't thought of the eCATT solution before -- I'll have to check that out. However, another easy solution is LSMW. I used that here to initialize passwords in production for several thousand users when we implemented HR, using passwords based on portions of SSN's and birthdates, so they would be known to the employees but not by anyone else, and so we wouldn't have to manually create and communicate unique passwords for each employee (nor have everyone start with the same initial password -- a bad idea!). While I won't go into the details of how to get those details for the initial passwords (not part of your question), with LSMW you can use as an input file a CSV file with two columns -- in the first, the usernames, and in the second, the passwords matched to those usernames. Then you just record an SU01 'change password' operation, much like was described for eCATT, and parameterize it with the column headers of your input file.

--Matt

[Former Member]

>

> While I won't go into the details of how to get those details for the initial passwords

Well, if one of your end users are reading this, then they might be able to work out all the others (but not on their own)...

Cheers,

Julius

[Matt_Fraser]

We tell them the format, i.e. pxxxxyyyy where 'p' is a lower-case p, xxxx is the last four of their SSN, and yyyy is the year of their birth, so they all know that basic formula. In theory, very few people other than the employee should know both the year of birth and the last four of the SSN (and we hope those few, mostly in HR, are trustworthy or we have bigger problems).

Of course, if we were not using CE, then there is a built-in tool that does this kind of thing, found in transaction HRUSER. Unfortunately, at this time HRUSER is not CE-aware, so for employees with multiple personnel assignments (multiple positions), it would create a user account for each position. That would put us way over our license limit, not to mention being unwieldy for the employees. With a little luck, one of the upcoming enhancement packs might have something in it to make this process easier, but I haven't had a chance to check out their content yet.

One possible issue for the training scenario with this could be that it requires the user change the password, as usual, on first logon, and perhaps for training they don't want that? Changing the user type might alleviate that problem, but would it possible introduce others, with change behavior of some sort? It might not matter in a controlled training environment if it does, though. For our training system, we have a couple hundred standard users created, with defined passwords, and we don't really mind if end-users remember what that password is, as there is limited harm they can cause outside of the classroom (the accounts are not powerful and there is no 'real' data of a sensitive nature in that system).

--Matt

[Former Member]

>

> as there is limited harm they can cause outside of the classroom (the accounts are not powerful and there is no 'real' data of a sensitive nature in that system).

I think it depends on the environment and what you are teaching them to do in the training or exam.

If they are sharing passwords (and absolving remote training - for example) for later administration of a nuclear reactor, or operating an artificial life support system in a hospital, or ordering oxygen (not helium) for your submarine, or computing the point at which stock should sell so that your pensions don't go down the drain with the others, etc then it is more serious...

Cheers,

Julius