ALERT! The community will be read-only starting on April 19, 8am Pacific as the migration begins. Read more for important details.
ALERT! The community will be read-only starting on April 19, 8am Pacific as the migration begins.Read more for important details.
Commander
Commander
544 views

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

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

 

2 Replies
Knowledge Partner Knowledge Partner
Knowledge Partner

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.

 

Commander
Commander

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.

The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.