Self Service Password Reset
Universal passwords are used
NetIQ Access Manager
NAM 3.2 SP2
Users are *sometimes* not able to change passwords through SSPR
User is looped back to the SSPR Change Password page after attempting to change password
SSPR fails to change password, user sees no error message
SSPR log shows errors:
NMAS error 669 (failed authentication)
PWM error 4037 PASSWORD_UNKNOWN_VALIDATION
Problem occurs if users login with password typed in mixed-case (e.g. PassWord1)
Problem does not occur if users login with password typed in all lower case or all uppercase password (e.g. password1 or PASSWORD1)
Set NDSD_TRY_NMASLOGIN_FIRST on all LDAP servers used by SSPR
For more information see âEnforcing Case-Sensitive Universal Passwordsâ
One or more LDAP severs used by SSPR was not properly configured for case-sensitive Universal Passwords.
In this environment, users log into NAM, and if their edirectory password has expired are forwarded to the SSPR Change Password page. This occurs invisibly to the users; NAM provides the authentication to SSPR through identity injection.
Note that the password is used as entered by the user throughout the process. The format of the password is not changed by NAM or by SSPR; it is used in the same format it was entered by the user (upper, lower, or mixed case) to login to NAM, SSPR, and to LDAP. All three authentications will use the password exactly as it was typed by the user on the NAM login page.
Also note that if the user does not authenticate to SSPR with a password - such as with forgotten password or activate user, then SSPR will attempt to read the password of the user from the directory if:
1) The ldap directory is detected as eDirectory
2) The option to read passwords is enabled (Settings -> eDirectory -> Advanced -> Read Passwords)
3) The proxy user has rights to read the password (UP Policy -> Universal Password -> Configuration Options -> Universal Password Retrieval -> Allow the following to retrieve passwords -> Proxy User
If the above succeeds, SSPR will read the password of the user and then bind as the user with the retrieved password.
If any of the above fail, then SSPR will generate a random password for the user and bind as the user with that random password.
Regardless of how SSPR binds to LDAP, once SSPR successfully binds as the user the password will be changed using an NMAS modification operation that uses both the old and new password so eDir will see this as a user initiated modification (as opposed to an administrator initiated modification).