topic Re: FORCE PASSWORD CHANGE in Application Development and Automation Discussions

FORCE PASSWORD CHANGE

Former Member — Wed, 13 Feb 2008 09:20:19 GMT

Hi,

we have been requested to force all users (in an R/3 basis 6.20 on Solaris and Oracle) to change their passwords in connection with implementing new password rules - tomorrow.

How can this be accomplished without risking the functioning of the system?

Best regards

Roland Hjelm

Re: FORCE PASSWORD CHANGE

jurjen_heeck — Wed, 13 Feb 2008 09:29:20 GMT

Have you considered temporarily decreasing the length of time passwords are valid?

parameter login/password_expiration_time

If you search the forum for password and parameter you'l find some interesting discussions on similar topics.

Re: FORCE PASSWORD CHANGE

Former Member — Wed, 13 Feb 2008 09:37:17 GMT

That is very creative Jurjen! It would have spared SAP the hassle of introducing parameter profile login/password_compliance_to_current_policy... )

Though there is still an advantage, because login/password_expiration_time is static, so you would need to restart your instances twice within the next 24 hours (to get the "temporary" piece right).

Cheers,

Julius

Re: FORCE PASSWORD CHANGE

Former Member — Wed, 13 Feb 2008 09:38:35 GMT

If users don't log in during the period of short expiration_time and we reset the parameter after a few days to the intended long period I guess they would not be affected.

Re: FORCE PASSWORD CHANGE

Former Member — Wed, 13 Feb 2008 09:41:53 GMT

Hi Roland,

See Wolfgang Janzen's comments in this thread:

Cheers,

Julius

PS: And welcome to SDN.

PPS: Your email address is visible in your profile, but not to logged on members in your business card, so I assume that this is not intentional and you might want to switch the email visibiliy to "hide".

Edited by: Julius Bussche on Feb 13, 2008 9:44 AM

Re: FORCE PASSWORD CHANGE

Former Member — Wed, 13 Feb 2008 10:20:25 GMT

Sadly enough the compliance parameter was introduced in 6.40 and we have 6.20.

I have been thinking about the possibility to do an SQL update of user records, but it seems risky - and I don't know what to set.

When doing upgrades we sometimes lock users (set uflag = 64) but in this case something similar (whatever it is) seems risky.

Re: FORCE PASSWORD CHANGE

Former Member — Wed, 13 Feb 2008 10:23:22 GMT

> (in an R/3 basis 6.20

Sorry, a correction: the parameter profile mentioned is only available from release 7.00 onwards

I can think of some "hacks" to do it, but you also said:

> How can this be accomplished without risking the functioning of the system?

I would recommend opening a support call with SAP and ask them for assistance. You could for example increase the parameter mentioned by Jurjen by +1 each day for the next week or so, and then monitor to see when the users have all (or mostly) logged on. There is a way of doing this.

Note that you should check the correct user types to avoid surprises, and there are two parameters which should not be used (login/password_max_new_valid and login/password_max_reset_valid).

Cheers,

Julius

Re: FORCE PASSWORD CHANGE

Former Member — Wed, 13 Feb 2008 10:30:07 GMT

> I have been thinking about the possibility to do an SQL update of user records, but it seems risky - and I don't know what to set.

There are some threads which mention this... but I have not seen any which correctly identify the fields you need (and that is also limited to the correctness of my understanding of what the fields are and how to select them based on, for example, the user type).

I would recommend contacting SAP and ask them for a way to dynamically increment the login/password_expiration_time each day by 1 until you reach your policy setting again, for example 60...

(copyright Jurjen Heeck).

Cheers,

Julius

Re: FORCE PASSWORD CHANGE

jurjen_heeck — Wed, 13 Feb 2008 10:47:31 GMT

> There are some threads which mention this... but I have not seen any which correctly identify the fields you need (and that is also limited to the correctness of my understanding of what the fields are and how to select them based on, for example, the user type).

I've been looking for those as well as they're close to the programmers' trick to reset their own password history by editing table USR02 directly. On my WAS 610 testsystem I've tried to force a user's password to be flagged as initial by fiddling with this table's entries but I was not successfull (yet). Somewhere I think I once succeeded but that of course was never written down.....

Got it

You'll need a programmer to get it done for multiple users, but here's wat to do if you're not afraid of editing table contents. (tested on WAS 610 but completely at your own risk )

For each user you want to force a password change for:

in USR02 set field LTIME to 00:00:00

Edited by: Jurjen Heeck on Feb 13, 2008 11:56 AM

Now tested and working on NW2004 as well

Edited by: Jurjen Heeck on Feb 13, 2008 12:02 PM

Re: FORCE PASSWORD CHANGE

Former Member — Wed, 13 Feb 2008 14:10:22 GMT

Hi Jurjen,

If I remember correctly, there are 4 possible fields and not only restricted to USR02 to do it without creating an inconsistency. But I cannot remember which of them are the correct ones for release 6.20, which is what we are dealing with here.

Another "out of the box" suggestion: Users typically can change their own passwords via transaction SU3, and it might make sense to inform them what the new password rules are so that they need not use trial and error to find the new rules => add a new Z-transaction to a "universal role for all dialog users" and also add it to the "start transaction" settings for all dialog users, which first presents the new rules to them, and if accepted, then calls transaction SU3 to prompt the voluntary(!) password change, and if changed, then removes the Z-transaction from the users "start transaction" so that they are not reminded again. It would not force them, but would constantly remind them until they change it. The down side is that if users already have a personal start transaction set, then you would be gone or the Z-transaction should be able to know that, and put it back again. An ABAPer should be able to knock that together in a few hours and have it ready and tested by tomorrow morning

Cheers,

Julius

Re: FORCE PASSWORD CHANGE

jurjen_heeck — Wed, 13 Feb 2008 14:23:03 GMT

> If I remember correctly, there are 4 possible fields and not only restricted to USR02 to do it without creating an inconsistency.

Oh well, glad I tried it on my sandbox then Just changing the time did the trick (both ways).... Keep me posted if you dig up the other three fields.

Re: FORCE PASSWORD CHANGE

Wolfgang_Janzen — Wed, 13 Feb 2008 20:47:40 GMT

> Sadly enough the compliance parameter was introduced in 6.40 and we have 6.20.

Sorry, it was even one release later ... (NW 7.0 / 2004s) - see below.

> I have been thinking about the possibility to do an SQL update of user records, but it seems risky - and I don't know what to set.

The safest of all dirty tricks is to set only the "initial password" flag (USR02-LTIME = 000000). Users of type SERVICE or SYSTEM will not be impacted by that (see <a href="https://service.sap.com/sap/support/notes/622464">SAP Note 622464</a>).

Please refrain from manipulating other fields (e.g. USR02-BCDA1) since that will cause inconsistencies with the change records (USH02).

In contrast to the solution we've introduced with NW 7.0 (see <a href="https://service.sap.com/sap/support/notes/862989">SAP Note 862989</a> : login/password_compliance_to_current_policy = 1) you cannot determine which users actually need to change their password. That can actually only be determined in the cause of validating a user's password (since only then the user gets hold of the plaintext password and is able to check it against the current password rules for compliance).

Nightly greetings,

Wolfgang

Re: FORCE PASSWORD CHANGE

Former Member — Wed, 13 Feb 2008 22:48:15 GMT

Et tu Wolfgang... and I was trying so hard to behave myself... ))

But at release 7.00 it would not work, right?

Re: FORCE PASSWORD CHANGE

Former Member — Wed, 13 Feb 2008 23:27:11 GMT

Would it be possible to use eCATT to make these changes? Wasn't sure if anyone thought about that.

Thanks,

J. Haynes

Denver CO, US

Re: FORCE PASSWORD CHANGE

Wolfgang_Janzen — Thu, 14 Feb 2008 08:47:03 GMT

> Et tu Wolfgang... and I was trying so hard to behave myself... ))

Well - as you see: I've waited until one already has posted it ...

I just want to avoid that even more critical hacks are done.

And since there's nothing we can offer as standard solution, that's actually the only possible solution.

For an auditor the result will look like: suddenly, many users have decided to change their password - without any obvious reason. Well, to assuage the auditor, one should document that this action was performed (and when).

> But at release 7.00 it would not work, right?

I strongly recommend to use the existing / provided feature (available as of NW 7.0).

As I've explained: that is the better instrument - it prompts only those users to change their password which are not using a password that complies with the current password policy (typically: after the password policy was "hardened").

Well, in future the data structures might change. There is no warranty that any hacks will continue to work. Looking back: the structure of table USR02 has changed many times in the last few releases ... - for the sake of new / better functionality.

Cheers, Wolfgang

Re: FORCE PASSWORD CHANGE

Former Member — Thu, 14 Feb 2008 09:25:07 GMT

> For an auditor the result will look like: suddenly, many users have decided to change their password - without any obvious reason. Well, to assuage the auditor, one should document that this action was performed (and when).

Hi Wolfgang,

Good point about recording the action for the auditors.

I would be surprised if the majority of auditors would pick it up to be honest.

They tend to place reliance on the params that they are familiar with. One thing which often amuses me is when special chars and/or symbols in pwd are set and there is an audit comment saying that USR40 isn't populated.......

Re: FORCE PASSWORD CHANGE

Former Member — Thu, 14 Feb 2008 10:36:18 GMT

The decision has now thank goodness been taken to avoid tampering with the system and initially use exhortion.

Those who do not react favourably will get special treatment later, possibly with the "initial" flag.

I have forwarded the replies to the authorization people and got the reaction "there are some good ideas out there".

Thanks a lot.

Re: FORCE PASSWORD CHANGE

Former Member — Thu, 14 Feb 2008 14:50:14 GMT

Thanks for updating us on the outcome.

I think we should have asked this earlier... but how many users are there?

@ Alex, who wrote:

> an audit comment saying that USR40 isn't populated.......

Is that the table which consultants originally misinterpreted the purpose of? )

Re: FORCE PASSWORD CHANGE

Former Member — Thu, 14 Feb 2008 17:04:01 GMT

> > For an auditor the result will look like: suddenly, many users have decided to change their password - without any obvious reason. Well, to assuage the auditor, one should document that this action was performed (and when).

> Hi Wolfgang,

> Good point about recording the action for the auditors.

> I would be surprised if the majority of auditors would pick it up to be honest.

I think an auditor would have a reasonable chance of spotting it, but less so because of many users suddenly changing their passwords on the same day.

What they might spot is, when checking that inactive users are locked, the question might be asked why a number of inactive users locked by the administrator, all have an initial password....?

They might also see that an administrator lock was set on many users within the 5 days which followed valentines day (users with inactive initial passwords), and not the usual 60 days as per the company policy for inactive users with their own passwords.

Latest, when looking at the KPI's of the registration desk, they might notice a disproportionately high number of users which required an administrator lock to be removed in the last week of February...

Click!

Their finance auditor colleagues had also mentioned in their co-ordination meeting that the company controllers had complained about IT being the reason for delays in their Fast Close month end processing in February and in March the cost center owners could not access the system either because their access to systems at month end (only) were locked, which caused them all to miss their bonus goals for 2008, but nobody knows why it happened...

Just a thought of a possible, and not unreasonably unlikely, scenario.

)

Cheers,

Julius

Re: FORCE PASSWORD CHANGE

Former Member — Thu, 14 Feb 2008 20:42:46 GMT

And a worst case scenario... (one which does not only go "bang", but goes "bang; bang; bang; bang; bang;... (also for the auditors).

=> Company password policy is that users with initial passwords known to admins etc should all be locked at midnight, and re-apply the next day or whenever for an unlock. This is implemented, and scheduled as it has been for some time already.

=> Enforcment of the new policy, resets LTIME for all users in all clients using SQL to 00000000 once all users have logged off and gone home, so that during the course of the next day(s) the users will gracefully reset their passwords according to the new password policy.

But only until midnight!