• State Not Answered
  • Replies replies
    2
  • Subscribers subscribers
    10
  • Views views
    796
  • Users 0 members are here
  • Locked Locked
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

SSPR 4.4 User self registration in AD fails due to weak password

psundqvist

Hi,

I'm trying to set up User self registration in AD through SSPR, but I don't understand how to properly setup the password complexity.

I've tried both with prompting the user with a password as well as letting SSPR generating one on its own. Setting the password myself, I can successfully register as long as the password is complex enough. But I can also make it fail by setting a password that is strong enough for SSPR, but not for AD. When letting SSPR generate a random password, it sometimes succeeds and sometimes fails.

Shouldn't the password check in the form make sure that the password adheres to AD:s policies? And shouldn't the random passwords generated by SSPR be strong enough?

We're already using SSPR for letting users reset their passwords and that works fine. The password I've tested with is rejected by that form.

The only setting I can find regarding passwords is the "Password Policy Template" which is set to the same user as I used when testing the forgotten password feature. So that user should have the correct password policy.

The error I'm getting is:

ERROR, newuser.NewUserServlet, {3468} error during user creation: 5049 ERROR_NEW_USER_FAILURE (unexpected ldap error setting user password for new user entry: javax.naming.directory.InvalidAttributeValueException: [LDAP: error code 19 - 0000052D: AtrErr: DSID-03190FD6, #1: [83.253.137.90] 0: 0000052D: DSID-03190FD6, problem 1005 (CONSTRAINT_ATT_TYPE), data 0, Att 9005a (unicodePwd)

Best regards,

Philip

 

  • 0  

    So the AD password policy is slightly more complex than just 3 of 5.  (Good thing it is not 7 of 9).

    It also says, tokenize display name, based on spaces, dashes, underscores.

    So a user named "Juan Jose Bob Al Smith Jones" is broken down to:

    • Juan
    • Jose
    • Smith
    • Jones

    But not Al, since it needs three chars min. So Al is too short.

    All those strings cannot be in the password either.  This is very hard to enforce since it changes per user.  Also, displayName in AD might not match the attr in eDir and so on...

     

    I would guess this is a possible cause.

     

  • 0 in reply to   

    I think the problem is that SSPR doesn't even enforce the 3 of 5 rule. It lets me set a password containing only lowercase letters, which would only meet 1 of 5.

    I also tried setting the password policy source to merge SSPR and AD. Then I set the complexity to AD 2008 Level with only 1 violation allowed. But this had no effect, I can still set a password containing only lowercase letters.

    Passwords containing parts of the displayName will probably turn out to be a problem too, but I haven't gotten that far yet.

Resources

Support
Documentation
Learning Services
Partner Programs
Privacy
Compliance
Help
Company
Privacy Policy
Terms of Use
Cookies Preferences
Accessibility
Anti-Slavery Statement
Support
Contact Us
Careers
Code of Business Conduct and Ethics
The opinions expressed above are the personal opinions of the authors, not of OpenText. By using this site, you accept the Terms of Use. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.), Hewlett Packard Enterprise Company, or Micro Focus. As of January 31, 2023, the Material is now offered by OpenText, a separately owned and operated company. Any reference to the HP, Hewlett Packard Enterprise/HPE, and Micro Focus marks is historical in nature and the HP, Hewlett Packard Enterprise/HPE, and Micro Focus marks are the property of their respective owners.