Password Rule for System Users

[former_member759680]

Hello,

We are planning to implement new password rule to incorporate minimum 1 digit in the password using RZ10 parameter.

The question is - what would happen to the system users that are already created in the system?

Would the system users continue to function with their original passwords?

Thanks.

[Former Member]

They can continue till next password changes (From the server restart)

If u r changing password duration it will calculate from last changes

[former_member759680]

Ravi,

Password for System Users do not expire, password duration is not applicable to them.

[Former Member]

I think the rules are only checked on new passwords not existing ones - I recall implementing such complex password rules once and having the same concerns you have.

When we made the change in development we noticed no issues with existing users and their passwords, but when we changed passwords going forward after the change, we had to have the specified number of digits.

[Former Member]

You can instruct the system to force a password change (and therefore enforce the new rules) even before it's validity has expired by changing the default of the system profile parameter login/password_compliance_to_current_policy from 0 to 1.

But this is only available in higher releases and SYSTEM and SERVICE type users are exempted from password rules for existing passwords and cannot change their own either (unless authorized to administrate their own user group) so this will not work for you - except being usefull as a "big hammer" to find incorrect user types...

The best solution in my opinion is to first correct the cardinality of your users with saved logon data (ensure 1:1 connections) so that the calling system can always be identified by the name of the user ID in the target. When you have isolated them, then you can generate a new password for the user in the target and maintain it in the source in virtually one go. This is also an important prerequisite for restricting their authority in a meaningfull way.

If you don't have the cardinality of the user ID's sorted out first, rather don't change anything yet.

Some tips:

- Download RFCDES to Excel per SID to document your progress and changes.

- Create the new users first in the target client (SU01) with the old access...

- Use 8 character upper-case passwords, so that these users do not force the whole system to remain downwardly compatible.

- Use a naming convention for them so that you can range SM19 user filters.

- Then switch the RFC logon data in the sources (SM59).

- Monitor the RFC calls on the new users with SM19 dynamic filters (to be able to build their role).

- Download the Server RFC profiles for the old users from ST03N to start with.

- Monitor the RFC logons of the old users with RSUSR200 until they stop.

- Remove the roles of the old users (but not delete or lock) and monitor ST22 for dumps.

- Insert the Function Module into the menu of the role and maintain SU24 for them.

This way you don't have to write the passwords down, and if you need to change it you can for 1 connection without bombing out the others.

Having said that, there are some "tricks" to synchronize the passwords of SYSTEM and SERVICE users (because the initial password is the productive one already). But generally they will mostly weaken your security at the same time and force you into using very granular security in authorizations and config, even if the trick is designed as a needle in a haystack...

Or alternately use trusted RFC to eliminate the password completely, but you need to be very carefull with that as well.

Cheers and good luck,

Julius

[Former Member]

Yes, it will continue with same password, but when you change the new it will take new method

[Former Member]

>

> Yes, it will continue with same password, but when you change the new it will take new method

Exactly. And that is exactly where it can cause a big problem or force you to use less secure methods with less usability features.

If you do not change the password, then it will remain protected from changed rules if the user type is correct... in which case it is your responsibility to protect the password over time...

If you take a look in USR02 in old clients, you might even find Type D users with code version A hashes...

That is why cardinality of connections is important...

Cheers,

Julius