SSPR does not display error when  password policy is violated

  • 7012130
  • 11-Apr-2013
  • 28-Jun-2013

Environment

NetIQ Self Service Password Reset
SSPR 2.0 HF1a
Win 2008 2 server
Active Directory
"Enforce Microsoft-AD password complexity" set to "true"
 
SSPR Change Password screen
 

Situation

“New Password accepted” is displayed even though a password viloates the AD password policy. SSPR does not change the password (as expected), and  LDAP error 19 (constraint violation) shows in the SSPR error log.
 
This is shown the first time a user attempts to change the password from the “Change Password” screen, entering a new password that violates the AD password policy. 
 
If the user immediately tries again to change the password and enters something that violates the policy, a message is displayed saying
 
New password does not meet rule requirements.” 
 
Thus, no error is not shown the first time the user attempts to change the password to something that violates the AD password policy.  But the error is shown on the second and subsequent attempts in the same session to change the password to something that violates the AD password policy.  

Resolution

Resolved in SSPR 3.0.

Workaround: try again and the error will be shown. 

Bug Number

814852

Additional Information

The violations tested were:
1. trying to reuse a password in the password history list, and
2. trying to change the password more than once in the same day with “Minimum password age" set to 1.
 
Steps to duplicate:
1. Login to SSPR, go to the Change password screen.
2. Attempt to change the password to a previously used password, or to change it more than once in the same day. 
3. “New Password accepted” is displayed. 
4. Click "change password"
5. User is returned to the  Change password screen. No error message is shown to the user, but the SSPR error log shows LDAP error 19 (constraint violation).
6. Try again to change to the same previously used password.
7. Message is presented saying “New password does not meet rule requirements”  as expected.
 
NOTE: 
This problem occurs because AD does not have a password-policy pre-check API.  SSPR checks for the rules it can enforce itself, but things like history or time constraints need to be checked by AD, and the first opportunity to do so is when the password is actually sent to AD for a change.  This contrasts with eDirectory which has a pre-check API which is actually called during the typing process to dis-allow non-compliant  passwords.