Password Parameters

[Former Member]

Hello,

We use SSO based logon into SAP systems.

I have a conundrum with 2 Security parameters: login/password_change_for_SSO and login/password_max_idle_initial

In our system(ECC 6 EHP3), the paramter: login/password_change_for_SSO = 0

0 =  Ignore requirement for password change

Description:

With non-password-based logon variants (SSO: SNC, X.509, PAS, logon

ticket), the system has, up to now, not checked whether the user has

a password that he or she must change.

Now, login/password_max_idle_initial

Since the parameter login/password_change_for_SSO is set to '0', the system does not prompt dialog user to change his initial password.

Let's say we change the parameter login/password_max_idle_initial = 10 (right now it's 0).

Now, if a dialog user logs into the system within 10 days of password (re)set, the system won't ask him for changing password (due to SSO), so ideally the user has not changed his initial password.

Will the system lock out the user after 10 days, because his password is still initial? Even though he has logged into the system.

Thanks in advance.

[Former Member]

No, the user is not locked. the password is destroyed (only).

The configuration you have will have the affect that all users passwords will be destroyed if they login with a PWD 10 days or longer after it being (re)set by an admin. At first login via SSO it will not be destroyed or need to be changed, but after 10 days it will be "idle" and if it is ever used again, then it will be destroyed and the login will be rejected.

Quite a clever combination to delay the destruction but not confuse end users if they are never informed about the password  --> those who are have 10 days to react by using it (will however need a login possibility which will prompt for the password...!)

However it will confuse the hell out of auditors who only download or look at USR02 table...

I will add this to my "box of tricks". Thanks for sharing!  😉

Julius

[Former Member]

Hello Julius,

That was really helpful.

In fact, I had a feeling along similar lines, that the User will not be locked.

The thing is, in EWA reports for Production, login/password_max_idle_initial = 0 has been highlighted in RED as a critical alert and SAP wants us to change it to a non-zero value below 15.

Since it is Production, I would like to have SAP backed up documentation stating what you have clarified above.

But I was unable to find any SAP Note/documentation stating the same.

Is an OSS message the only way, or can you help with some OSS note/SAP link clarifying this?

Thanks again.

[WolfgangJanzen]

Quite a clever combination to delay the destruction but not confuse end users if they are never informed about the password  --> those who are have 10 days to react by using it (will however need a login possibility which will prompt for the password...!)
However it will confuse the hell out of auditors who only download or look at USR02 table... 

Well, exactly this "clever combination" was on our mind.

After the password was "deactivated due to inactivity" the password can no longer be used to logon to the system. Consequently the user will then no longer be asked to change the password when performing a SSO logon.

Regarding table USR02:

Well, data structures and system-internal processes are subject of change - you should use the proper tools and APIs (here: function module SUSR_USER_PASSWORD_STATUS_GET) to determine the status.

Please notice that as of SAP_BASIS 7.03 the new concept of ABAP Security Policies will effectively replace the old concept of policy-defining profile parameters. Our tools and API functions will be updated accordingly (it will no longer be possible to get the right information just by a simple SQL statement).

Cheers, Wolfgang

[Former Member]

Hello Abhishek,

With the parameter settings you mentioned, the user will be able to login through SSO to ECC backend system, but the problem will be when he tries to login directly to Backend system.

When user tries to login to SAP ECC after 10days, he'll get the error message -password expired. This willvery badly hit hundreds of users then?

How to overcome the situation?

Are there any other parameter which can help to over this password expiry situation?

I'd like to understand what is the final solution you applied to overcome the EWA recommendation?

Thanks.

[WolfgangJanzen]

Bhaskar Vh wrote:

How to overcome the situation?
Are there any other parameter which can help to over this password expiry situation?

Sorry to say this - but the system works exactly the way it was asked to behave:

• Do not prompt users to change their (initial/expired) password as long as they logon by SSO
• Inititial passwords which have not been used to logon will become invalid after 10 days

If this is not what you want, you should configure the system differently.

The rationale behind both profile parameters is:

Initial passwords (i.e. passwords which have been set by the administrator, not by the user) should be changed as soon as possible (because they are known to the administrator who has set them). If the user does not require the password (thanks to SSO) the password should actually be disabled - that might be even done immediately (see: login/password_change_for_SSO - it's possible to instruct the system to delete such passwords immediately when the user logs on using SSO). If the user is not making use of his passwords in the first 10 days after the password was set by the administrator, it's justified to disable the password. After that, the user is still able to logon to the system using SSO. If he really feels the requirement to be able to logon by password in addition, he need to request a new password from the administrator - and should use that new password then immediately (at least in the 10-days timeframe).

Maybe it's a good advice to inform the users about the fact that a new password (being obtained from the administrator) needs to be used in the next 10 days, otherwise it will be vanished.