Change Password to initial

[erosvomgolzheimerland]

Aloha

What is the best way to mark a user Password administratively as Initial?

I dont want to have a new Password, only the aktually Password should be Initial.

I have a Group of users (not all but sure more than 500) i want to force to alter their Password.

I try to set the "Initial" flag in the USR02 on 0,1 or 2 but that make no reason at the next log in.

Thank you and sorry for my english

Maik

[Former Member]

You should not update USR02...

Do you want to reset their passwords because you suspect they are not compliant with the current policy? Depending on the reason and your system release, their might be a solution.

Cheers,

Julius

[Matt_Fraser]

If, as Julius suggests, the reason you want to do this is because you have changed your password policy to be more stringent (i.e., requiring numbers, mixed case, etc), and you want to ensure everyone's password is compliant immediately even if it's not yet expired, you can set the profile parameter login/password_compliance_to_current_policy to 1, and this will force a check at their next logon. If their current password is compliant, nothing will happen, but if it's not, then they'll need to change it right away. The default for this parameter is 0, which means the password will only be checked for compliance at the next change (whether manual or forced by expiration).

Or are you trying to simply force everyone to change their password once, immediately, regardless of compliance? Why not just set an expiration time and let them expire normally?

Regards,

Matt

[erosvomgolzheimerland]

We want all users to Change their Password.

First step is a eMail in the next 2 weeks, we Appeal all the Chance their Password to 31.12.2014

At 01.01.2015 we check all Users, if they Change their Password.

After 14 days, we want to force the Change of the Passwords and set all not voluntary as Initial.

[Former Member]

Helo Maik!

I think in there is no direct way to change their passwords not voluntary as Initial for this type of user (dialog), only edit the table usr* manually. It is security feature. Why after 14.01.2015 you want to know all users passwords ? Don't you think that is too much knowledge for basis? What if someone says that it's you did something in SAP under his login because you know his password ? Maybe you should generate initial password (in excel for example) and paste it into SU10 transaction for all users ? All initial password will be unique but for one time.

[erosvomgolzheimerland]

LOL - No, i dont want to know all Passwords. 

The date is just an wish from president.

"We" want that all users have to Change their Passwords.

First step is by choise to 31.12.2014

After that date we give a Deadline (maybe some are in Holidays) of 2 weeks.

Than, at 14.01.2015 i want to set all not changed Passwords as Initial.

So, if user want to log in and dont have changed Password, is now forced to do it.

I wish i could do it with params but i dont find a good way.

[Former Member]

But if you change the passwords to random initial users have to change it after login. SAP will be asking for change the password to permanent and don't pass them to work with initial password.

In help:

You can use the profile parameter login/password_expiration_time to define the point at which the user is prompted to change his or her productive password. The time is calculated from the date of the last password change plus the number of days specified in the profile parameter.

[mvoros]

I just want to add to this. If you are on sufficient release you could use secuirty policy to force this value to be low for subset of users. So you could kindly ask users to change their passwords.Then select users who did not change their passwords in given period and assign them policy with low expiration time. So when they log on they will be forced to change password. After this exercise you would remove this special policy from these users to get back to standard defaults.

If this is about new password policy then follow Julius' advice and use standard parameter for this.

Cheers

[erosvomgolzheimerland]

For example (Password_expiration_time)

If i Change the Parameter at 01.12.2014 on 44

So all users must Change their Password by choise to the date of 14.01.2015

After 14.01.2015 they get must Change it at next login

did it understand it right?  That could be a solution.

[Former Member]

Hi Mark,

  As far I understood, you can do one thing. First let users change their password till 13th jan. After that you can find out in table usr02 the last changed password date for users. If that date is before 25th nov(or take any cutoff time) then filter out those user ids. after that reset the password for thos id. that will make tha password as initial. so at 14 jan they will have to change the password.

Regards,

Deepak

[erosvomgolzheimerland]

Hi Deepak

That was my first idea (not liked by SAP) - to Change it direct in the USR02.

But the field dont make an difference between 0,1 und 2 

Maybe i use the wrong field...

Thx Maik

[Matt_Fraser]

Ok, I guess I'm still not understanding the problem and why you can't do this with parameters.

First off, you don't need to look in USR02 to see what the date of last password change was. You can use the report RSUSR200 to do this (you can run it directly as a transaction, or from SA38, or you can call it from SUIM).

If I understand the requirement correctly, you want all of your users to change their password on or about the start of the new year, and you're giving a grace period of two weeks into January for them to get it done voluntarily, after which you want to force the change for those who haven't done it.

What is the current policy? No changes required at all? For the sake of argument, I'm going to assume this is where you are today, and what you're trying to change away from. Perhaps you're also trying to enforce more complexity in the passwords, i.e. require a mix of upper- and lower-case letters, numbers, minimum length, etc, than is currently required.

You might have a look in RSUSR200 to get an idea of how many users have already changed their password recently, and so therefore perhaps you don't actually want to force them to change again right away.

My suggestion is to decide on the standard length of time between mandatory password changes (for instance, every 90 days or 180 days, etc), plus your complexity rules, and call that good. Chances are that if you haven't been forcing changes previously, then most of your users will be forced to change as soon as you implement the policy via parameters. Only those who have already voluntarily changed more recently than the expiration period, or whose user accounts are new, will not be forced to change, and this is a good thing, not a bad thing. It's probably what you really want.

So, set the following parameters in your default or instance profile:

• login/password_expiration_time
  • Length in days before password must be changed. If you set this to 90, for instance, then everyone whose password is older than 90 days will be forced to change at their next logon.
• login/password_compliance_to_current_policy
  • If set to 1, will force users to change their password at the next logon, even if it hasn't expired yet, if the current password doesn't meet the complexity rules.
• login/password_max_idle_productive
  • This is to catch those users who don't logon very often, but do once in a long while. If a person has changed their password, but then doesn't logon for another year (as an example), then this will cause their password to become inactive, thus requiring an administrative reset to let them logon again. Set this number fairly high, definitely much longer than login/password_expiration_time, perhaps about twice as long.
• login/password_max_idle_initial
  • Similar to login/password_max_idle_productive, but this one catches people who have a new user account, or get their password administratively reset, but then don't login and change it even the first time. This is especially important if you tend to use the same (easily guessed) initial password for users, as you don't want user accounts sitting out there with an initial password that everyone knows. Set this number lower than login/password_expiration_time, perhaps about half the length.
• login/password_downwards_compatibility
  • As long as all of your systems are on NetWeaver 7.00 or higher (I think), then you should consider changing this parameter to 0 (it defaults to 1). However, it's not really the focus of this discussion.

This is enough to force the change you're seeking. What level of complexity you then require, and how long the password history is maintained, etc, is up to you. If you set these parameters on New Year's Eve, then people will encounter the requirement to change on their next logon, unless they have already changed recently. If they don't logon for a long time, their accounts will become unusable until they seek an administrative reset. If they already haven't logged in for a long time (or ever), beyond the "max_idle" parameters, then their accounts will become unusable until they get an administrative reset.

Regards,

Matt

[erosvomgolzheimerland]

Thank you Matt (and all others)

I guess i try it with that Parameter "Login/Password_expiration_time" in 3 steps.

45 days... 90 days... 120 days...

After the third i look in the RSUSER200 and force the rest manually.

So i must catch all

Regards,

Maik