Profile parameter for passwords - conflicting documentations.

[Private_Member_119218]

Greetings!

I've encountered an issue with profile parameter login/password_max_idle_productive

Integrated help in SU01 says:

You can use the profile parameter login/password_max_idle_productive to define the point as of which the validity of the productive password ends. The time is calculated from the date of the last password change plus the number of days specified in the profile parameter. Password-based logon is then not possible from this point.

This makes this parameter redundant (we have login/password_expiration_time ).

SAP Library says (see link below):

Specifies the maximum period for which a productive password (a password chosen by the user) remains valid if it is not used.

Which suggests that the time after which passwords are considered expired is calculated from last logon date plus whatever is the parameter value.

SU01 help specifies explicitly how this parameter works but it conflicts with a more ambiguous description found in the SAP Library. The observed system behavior on logon is in line with SU01 help, but report RSUSR200 does not list the user as having an expired productive password.

We're on ECC 6.0, release 701 with support package 3. I could not find any SAP notes relating to this issue.

Has anyone encountered this issue before or have I just run into an odd glitch?

[SAP Library|http://help.sap.com/saphelp_nw70ehp1/helpdata/en/22/41c43ac23cef2fe10000000a114084/frameset.htm]

[Former Member]

>

> This makes this parameter redundant (we have login/password_expiration_time ).
> 

Here your assumption is wrong.

An expired password forces you to change the password.

An idle password set by the user (i.e. productive status) is disabled, or the user is given an option if the authentication is single-sign-on. This can be configured.

You can conclude from this that setting the expiration time to a value longer than the permitted idle time is illogical.

What the idle time setting does automatically, is that which you have been doing manually in RSUSR200 - after the password has expired and the user is still not changing the password.

As the system reacts differently to them, you can only have potentially conflicting settings.

Cheers,

Julius

Edited by: Julius Bussche on Oct 8, 2009 9:27 PM

Changed "shorter" to "longer". Important difference.

[Private_Member_119218]

Thanks for the answer, Julius. I hadn't considered SSO since we do not currently use it.

Based on documentation in SAP Lib, I had decided to set this parameter to a value somewhat less then that of login/password_expiration_time thus effectively invalidating users who have been absent for a long(ish) time and force them to request a new password when they returned. I see such valid but idle users as a security risk.

Is there some way I could achieve the same result? (Asides from setting login/password_max_idle_productive to login/password_expiration_time plus something.)

[Former Member]

It sounds like you have a requirement to set the expiration time (when the user has to change the password) which is for a different user group than those for which you want to disable an idle password. Currently, both are global settings and affect both user groups (actually, all users of type DIALOG and COMMUNICATION - only SERVICE and SYSTEM type users are not affected).

In that there is an option for you... but be aware of license implications... or you can upgrade to 7.02 early next year (I think this is the correct release, time and release "alias" for it..) and then the config your security policies client dependently!

Currently, your best option is to not set these two global parameters illogically and monitor the user group manually from RSUSR200.

In the wild, many folks use the user type difference to workaround this, but that is also global to the user type so they are excepted from the expiration time as well. Additionally, not all functionality is available to them on the client side (e.g. SAP Logon Tickets won't work) and the authority-checks are even slightly different on some special cases.

Personally, I don't understand why users with authorizations to make purchase requests only should change their passwords more often (expiration time) or be more active (idle time) than those with SAP_ALL etc.

> I hadn't considered SSO since we do not currently use it.

SSO solves several of these problems by deleting the password completely...

Cheers,

Julius

Edited by: Julius Bussche on Oct 8, 2009 9:59 PM

[Private_Member_119218]

No, that's not a requirement at all.

The goal was to eliminate valid but idle users that we see as a potential security threat, regardless of their authorization level. This was a nice-to-have, as we manually block anyone who hasn't logged on for a prolonged time anyways.

While the fact that we won't be able to achieve this is somewhat disappointing, I'm personally more concerned about the conflicting documentation. [SAP Lib|http://help.sap.com/saphelp_nw70ehp1/helpdata/en/22/41c43ac23cef2fe10000000a114084/frameset.htm] and [SAPnote 862989|https://service.sap.com/sap/support/notes/862989] appear to be in agreement on how this should work, albeit without telling us exactly how. Integrated help says something else altogether and the actual system behavior is in line with that.

To reiterate, I'm no not so much worried about the actual functionality as I am about the conflicting documentation. If I can't trust what I RFTM, what can I, then?

Regardless, we have created an OSS message and I'm eagerly awaiting their response. I will probably follow-up here if there are any interesting developments.