FORCE PASSWORD CHANGE

[Former Member]

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

[jurjen_heeck]

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.

[Former Member]

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

[Former Member]

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.

[Former Member]

>

> 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

[jurjen_heeck]

>

> 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

[Former Member]

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

[jurjen_heeck]

>

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

[WolfgangJanzen]

> 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

[Former Member]

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

But at release 7.00 it would not work, right?

[WolfgangJanzen]

>

> 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

[Former Member]

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

[Former Member]

>

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

[Former Member]

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!

[WolfgangJanzen]

>

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

Well, how do you know whether this check is implemented in his system?

Yes, there is a feature to restrict the lifetime of initial passwords (available as of 6.20). But it might not be active (by default it's not active).

Nightly greetings,

Wolfgang

[Former Member]

Of course I cannot know it.

But he did say that he changed the password policy and wants to enforce it... so parheps his "security authorization team" know it and have requested an enforcement of it?

How can any of us know that he is not enforcing that feature of the policy, and then not warn against changing LTIME?

Well, he has taken the wiser option and not tried to simulate something which might have consequences.

After all, we still do not know what the new password policy is, and we do not know how many users there are, and we do not know the user types, and there are only 22 minutes left to valentines day

Cheers,

Julius

[WolfgangJanzen]

>

> How can any of us know that he is not enforcing that feature of the policy, and then not warn against changing LTIME?

Yes, that's true. If he would have set login/password_max_new_reset (respectively: login/password_max_idle_initial, as of NW 7.0) it would be critical to set USR02-LTIME to an initial value. This could result in the inability to logon by password ...

>

> ... there are only 22 minutes left to valentines day

Well, at the fuel station you might be able to get some flowers ... - just kidding.

[Former Member]

>

> Well, at the fuel station you might be able to get some flowers ... - just kidding.

... <sensored>... - also just kidding

Best regards,

Julius

Edited by: Julius Bussche on Feb 15, 2008 3:06 PM

[Former Member]

> 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

Hi Julius, I edited my previous reply because I did not appreciate the depth of your thinking around this scenario....

My answer remains the same that I would be very surprised if the majority of auditors would notice such an event unless they had managed to sell more time for a system audit rather than begrudgingly reducing the scope and placing more reliance on company operated controls

Internal audit or controls is a different matter though.....

Edited by: Alex Ayers on Feb 15, 2008 2:57 PM

[Former Member]

Yes, I cannot imagine any auditor of any sort spotting the LTIME update itself, but I think most would find it because of the potential consequences.

If the worse case scenario had materialized after reseting LTIME, then even the doorman would have noticed.... particularly so if the door opening mechanism was dependent on a successfull time stamping mechanism which was using a COMMUNICATION user to "clock in" the DBA this morning...

Cheers to all and enjoy the weekend!

Julius

[WolfgangJanzen]

>

> ... particularly so if the door opening mechanism was dependent on a successfull time stamping mechanism which was using a COMMUNICATION user to "clock in" the DBA this morning...

Well, but in that case the problem would have occured even earlier (since COMMUNICATION users are also subject of password change requirements - not only those caused by initial passwords but also by those regular password changes).

However, SYSTEM and SERVICE users are not effected by that (both, initial password and regular password changes).

As you can see in [SAP Note 622464|https://service.sap.com/sap/support/notes/622464] COMMUNICATION users are actually DIALOG users without the ability to use SAPGUI.

Cheers - have a nice weekend,

Wolfgang

PS: I heard of some ATM terminals communicating via RFC with some backend systems ... - but they use SYSTEM users ... (for exactly that reason)

[Former Member]

Hello Wolfgang,

Out here in the wild, it happens quite often that such users are set as dialog users in the beginning and no password validity period is set at all. Then the security hardening happens later (like now), when LTIME no longer is 000000.... so it goes unnoticed, until the door locks everyone out, the morning after LTIME is set to 000000.

The good news is, they could still go to an ATM and then take the day off

Cheers,

Julius

[WolfgangJanzen]

>

> The good news is, they could still go to an ATM and then take the day off

Worse comes worse they use their credit card ...

[Former Member]

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.

[Former Member]

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

[Former Member]

>

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

[Former Member]

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

[Former Member]

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.

[Former Member]

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

[Former Member]

>

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

It is commonly accepted fact within security consulting that USR40 is a good opportunity to document every single swear word that the project team can think of. It doesn't matter if that word is > 8 chars (old systems only of course)

[Former Member]

>

> It is commonly accepted fact within security consulting that USR40 is a good opportunity to document every single swear word that the project team can think of. It doesn't matter if that word is > 8 chars (old systems only of course)

OMG!!! I just took a look in there!!!

[WolfgangJanzen]

> OMG!!! I just took a look in there!!!

Oh boyz - sometimes I'm glad to live in the ivory tower (where I'm not confronted with the bitter facts - i.e. to see how things are actually used, in contrast to what they have been designed for). As you know: the ivory tower is tall - so jumping out of the window is harmful ...

Cheers, Wolfgang

[Former Member]

Hi Wolfgang,

I liked your ivory tower comment During my audits I sometimes took the time and effort to check consistency between USH02 and USR02 in real live production systems.

Never do this when you want to continue to believe that things are done the way they should be done !

Regards,

Ralf

[WolfgangJanzen]

Well, (system) auditors are most likely not welcome by everybody ... - since it's their job to identify and disclose "irregularities". Same destiny as tax officers ...

[Former Member]

Hello Ralf,

>

> During my audits I sometimes took the time and effort to check consistency between USH02 and USR02 in real live production systems.

If you compare consistency of USR02 with USR02 over a period of LTIME by setting your own UFLAG to the only value which an auditor with the correct authorizations can set it to, then you might even be able to tempt someone into jumping out the window of the basement.

Works like a charm to find the "regularities"...

Cheers,

Julius

[Former Member]

Assumed answered, or locked out...