login/password_downwards_compatibility

[Former Member]

I was searching for a way to limit password length to 8 characters and found a way to limit the password generated via the wizard and thought the login/password_downwards_compatibility paramater set a '5' meant it would change to older standards. Apparently I'm not understanding how this parameter works because I created a test user after I set this parameter, but they were still able to create a long password. Is there a way to limit how long a password can be?

[Former Member]

Hi Chanda,

I dont think there is one to set the Max length of Password. I dont know how value it adds when you limit the Max length of the passwords. Some users would like to have their passwords of more length.

I know the following Profile Parameter to restrict the minimum length of the Passwords:

login/min_password_lng.

Regarding the other parameter login/password_downwards_compatibility

Pls use a search on http://help.sap.com/saphelp_nw2004s/helpdata/en/22/41c43ac23cef2fe10000000a114084/content.htm

Regards,

Kiran Kandepalli.

[Former Member]

Thanks, that is where I found the parameter mentioned above and why I set the parameter value to 5. I was under the impression that it would revert password parameters to a setting like 4.6 where the max password length by default was 8. That's why I was saying I guess I don't understand the meaning of "Full backward compatibility: the system only creates backward compatible password hash values."

Hope this makes sense.

[Former Member]

See [SAP Note 1145106|https://service.sap.com/sap/support/notes/1145106]

It is not an error.

Cheers,

Julius

[Former Member]

Forgive my ignorance, but the way I interpret that note is that if the password was greater than 8 characters before setting the parameter the user can still use the long password, but I was under the impression that the next time they changed their password it would have to be the 8 character (or less) password. But when I attempted to change the password to a 26 character password on my test account, I was able to successfully change it. So is this expected behavior and the '5' setting doesn't have the affect I originally expected?

[Former Member]

I think the note is clear (at least to me).

If you set the compatability profile to '5', then only the downward compatible password is used.

The first 8 characters entered are converted to upper-case and hashed using code version B and compared to the BCODE of the user master record.

What you have entered in the 9th to 26th character does not matter, neither when setting the password nor when logging on.

However you must have reset the password once already (for the code version to become known), and if I remember correctly setting the parameter to '5' will require a restart of the system (so you must change the instance profile in rz10).

If I am correct, then changing the dynamic profile in rz11 (for the other values) alone does not work.

Perhaps you can check the documentation in rz11 to see whether that is mentioned. I am fairly sure that I read it somewhere.

Cheers,

Julius

[WolfgangJanzen]

>

> Forgive my ignorance, but the way I interpret that note is that if the password was greater than 8 characters before setting the parameter the user can still use the long password, but I was under the impression that the next time they changed their password it would have to be the 8 character (or less) password.  But when I attempted to change the password to a 26 character password on my test account, I was able to successfully change it.  So is this expected behavior and the '5' setting doesn't have the affect I originally expected?

Well, actually the password change UI should look different when setting profile parameter login/password_downwards_compatibility = 5 : it should then allow only to enter up to 8 characters for the new password.

Notice: setting login/password_downwards_compatibility = 5 has intentionally no influence on the logon screen (in general: on the length of the input field for the "current" / "old" password).

Which UI technology (SAPGUI: Dynpro, Browser: BSP, Web Dynpro, WebGUI, ...) did you use to perform the password change? Or did you simply call some APIs?

Best regards, Wolfgang

[Former Member]

Hi Wolfgang,

My understanding is that to test it, Chanda was voluntarily hitting F5 and expecting the same screen as the user who's password had expired (or was not compliant with the current policy).

By setting the compliancy parameter, the non-voluntary screen was set first, even although F5 was used.

Perhaps I am wrong, but that is how I interpreted what was going on.

Cheers,

Julius

[WolfgangJanzen]

>

> Hi Wolfgang,
> 
> My understanding is that to test it, Chanda was voluntarily hitting F5 and expecting the same screen as the user who's password had expired (or was not compliant with the current policy).
> 
> By setting the compliancy parameter, the non-voluntary screen was set first, even although F5 was used.
> 
> Perhaps I am wrong, but that is how I interpreted what was going on.
> 
> Cheers,
> Julius

Sorry, but I cannot follow: what "F5" key are you referring to?

[Former Member]

Sorry, the "New Password" button on the logon screen = F5 on the keyboard = voluntary.

Cheers,

Julius

[WolfgangJanzen]

Ah, I see. Well, this password change dialog should indeed evaluate the value of the profile parameter login/password_downwards_compatibility (as described previously).

Maybe the profile parameter value change was not effective at that point of time?

Notice: you can either change the value dynamically (using RZ11) or statically (RZ10); in the latter case you need to restart the NWAS ABAP in order to make the change effective. If the value hase been dynamically, a system restart will set the value to the static value (the dynamically changed value will get lost - see warning displayed after changing profile parameters dynamically).

[Former Member]

I did restart the system after adding this value. It sounds like Julius' recommendation regarding the login/password_compliance_with_current_policy parameter will accomplish what I was looking for. I was simply trying to limit the number of characters one could enter when changing their password to eight. Meaning if they hit the "F5" or password change button they would only be able to create a new password with a limit of 8 characters. I haven't actually had a chance to try this out yet, but it sounds like that's the solution I was looking for.

Thanks to you all for input.

[Former Member]

> I did restart the system after adding this value.

What Wolfgang seems to be suggesting is that you changed the parameter dynamically (only) and then restarted the system, which set it back again. This is expected behaviour.

Cheers,

Julius

[Former Member]

I just tested this and Wolfgang is correct => The voluntary password change screen is changed to a length of 8 as well.

So it wasn't that, nor the compliance with current policy which might have influenced the screen (to change it).

Please remove the points from my answer.

Cheers,

Julius

[WolfgangJanzen]

>

> It sounds like Julius' recommendation regarding the login/password_compliance_with_current_policy parameter will accomplish what I was looking for.

I'm not convinced - setting login/password_compliance_with_current_policy = 1 has the following effect: when the user is performing a password-based authentication, the system will not only validate his password but in addition also check if the password complies with the current password policy. This allows to selectively prompt only those users to change their password (even though their next regular password change would be requested in the future), immediately.

If you "slacken" your password policy, then this mechanism will not result in password change enforcements (since the password policy only defines the minimum requirements; exceeding them is always possible - not harming the compliance).

[Former Member]

Thanks. I'm new to this and systems admin in general which is why this didn't make total sense. Your explanation helped clear it up. Long story short, you can't force a maximum length in the way in which we'd hoped we could.

[Former Member]

> Long story short, you can't force a maximum length in the way in which we'd hoped we could.

Ahhh... but this is different to your original question. This is possible.

Initially you said that you want to change the logon screen (which at most will prevent logons and not force an 8 character password only) but forcing them to change their passwords to the new 8 characters is possible.

By default it is not active, but you can activate the parameter login/password_compliance_with_current_policy in RZ11. For those users who logon with a password which is not compliant with the compatibility rule, they will be forced to change their passwords even although these have not expired yet.

Of course it does require that the user logs on (at least once with a password) as only they should know their (new) password. They will be blocked from logging onto the system until they change it.

Hope that helps a bit more,

Julius

[WolfgangJanzen]

>

> I was searching for a way to limit password length to 8 characters . Is there a way to limit how long a password can be?

May I ask for the reason? The longer and more complex your password is, the harder it is for an attacker to guess your password. So why you want to prevent your users from using better passwords?

[Former Member]

We are still in planning stages...We are just looking into things that could be affected if we implement single signon in the future or have to interact with legacy systems, etc.

[Former Member]

But legacy systems can still communicate with your higher release system if you set it as compatible with the old and the new mechanism.

Additionally, you could set the rules such that you can (and must) enter the passwords for users connecting from older systems as all upper-case and only 8 characters long. It shouldn't notice the difference...

You only need to train them a little bit.... Perhaps SSO is indeed an easier approach.

Good luck,

Julius

[WolfgangJanzen]

To me this sounds like you want to implement a Single Sign-On (SSO) solution based on (synchronized) passwords. Kindly notice that this is an error-prone approach (see [SAP note 376856|https://service.sap.com/sap/support/notes/376856]).

"Real" SSO solutions are not based on passwords but use other mechanisms (e.g. Kerberos tokens, X.509 certificates, SAML tokens, etc.).

Sometimes passwords are required for technical communications between system components. In this case it is highly recommended to use the ABAP usertype "SYSTEM" (see [SAP note 622464|https://service.sap.com/sap/support/notes/622464] and [SAP note 1023437|https://service.sap.com/sap/support/notes/1023437] for background information).

Best regards,

Wolfgang