dn: CN=Test User 1,OU=staff,DC=top,DC=contoso,DC=com
cn: Test User 1
distinguishedName: CN=Test User 1,OU=staff,DC=top,DC=contoso,DC=com
name: Test User 1
Based on this LDIFDE dump the only “token” that was being monitored for complexity was
attribute. The admin was able to pass
in the password. When password complexity is enforced,
attributes are checked. The new password is checked for “tokens”. It is important to note that a “token” must be three or more characters in length. Even then, only the whole “token” is used in the complexity check, not portions of the tokens. This comes into play when trying to evaluate tokens against
At this point, password complexity is being enforced as designed, but not what we would expect to see based on the user’s account information. The action plan that was provided to the customer was to populate the displayName attribute and test. This worked in testing, but ultimately the customer had to work with their vendor to resolve the issue with the sync process, allowing the displayName attribute to be populated from the SUN Identity Manager to Active Directory.
For more info on Password Complexity rules, see the recent blog post Understanding Password Policies .
- David Everett and Scott Goad, the Wonder Twins
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.