• 7013403
  • 02-Oct-2013
  • 31-Oct-2013


Self Service Password Reset 
SSPR 2.1
eDirectory environment
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) 
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. 

Additional Information

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).