SSPR Error 5026 Unable To Establish Session Password

Recently we ran into this error after installing SSPR in a new environment.  After completing the install of IDM and SSPR we were doing some User Activation testing through SSPR and this error reared its ugly head.

The SSPR login page loaded fine and we were able to click the User Activation link with no issue.  SSPR prompted us for the configured user identity data and we provided the correct user details.  After clicking the Continue button to start the account activation SSPR would fail with the error “Error 5026 Unable to establish session password”.  We were unable to continue beyond that point and all activation attempts for any user failed at this point with the same error.

A quick search on Google didn’t reveal much about this particular error and a review of the NetIQ published SSPR Error Codes only told us what we already knew:

“5026 – ERROR_BAD_SESSION_PASSWORD – Error_BadSessionPassword – Unable to establish session password.”

At this point, we suspected that there was some issue with the proxy account in SSPR not able to read/write data correctly so we reviewed the permissions and everything looked good.  Just to eliminate any concerns we reconfigured SSPR to use the IDM admin account for the SSPR proxy account.  With SSPR using the admin account for proxy processes we were ensured to have proper permissions within IDM for any and all tasks performed.

Still the process failed with the same error: “Unable to establish session password.”

Stumped we turned to the SSPR troubleshooting logs.  By default, the logs were not enabled so we turned up the logging in SSPR to debug and recreated the issue by performing the same steps.  Once the error was received we downloaded the SSPR troubleshooting bundle through the SSPR admin console and reviewed the debug log.

It was in the debug log that we were finally given a clue to the issue.

“2016-04-21T15:19:56Z, ERROR, http.PwmRequest, {2v} 5026 ERROR_BAD_SESSION_PASSWORD (error setting random password for user UserIdentity{“userDN”:”cn=t-test,ou=Users,o=dev”,”ldapProfile”:”default”} nmas error -1697)
2016-04-21T15:19:56Z, FATAL, servlet.PwmServlet, 5026 ERROR_BAD_SESSION_PASSWORD (error setting random password for user UserIdentity{“userDN”:”cn=t-test,ou=Users,o=dev”,”ldapProfile”:”default”} nmas error -1697)
2016-04-21T15:19:56Z, ERROR, auth.LDAPAuthenticationRequest, {2v} authID=9, error setting random password for user UserIdentity{“userDN”:”cn=t-test,ou=Users,o=dev”,”ldapProfile”:”default”} nmas error -1697 “

It seems the error was being thrown by SSPR after trying to set a random password as part of the activation process (see my other blog about the SSPR Activation Gotcha for more information on this.)

With this information at hand, we looked a little further down in the logs to see what password policy was being picked up by SSPR for the random password generation.  And that is when we found this:

2016-04-21T15:19:56Z, DEBUG, operations.PasswordUtility, {2v} discovered assigned password policy for cn=t-test,ou=Users,o=ndus-dev PwmPasswordPolicy: {AllowAdminChange=true, MinimumLowerCase=0, MinimumSpecial=0, chai.pwrule.ADComplexity2008=false, MaximumNumeric=0, MaximumUpperCase=0, MinimumLifetime=0, MinimumUnique=0, chai.pwrule.novellComplexity=, DisallowedAttributes=[], UniqueRequired=false, AllowNumeric=true, EnforceAtLogin=false, CaseSensitive=false, ChangeMessage=, ExpirationInterval=0, ChallengeResponseEnabled=false, MaximumLowerCase=0, AllowSpecial=true, chai.pwrule.ADComplexity=false, MaximumLength=16, MaximumRepeat=0, AllowFirstCharNumeric=true, AllowUserChange=true, MinimumLength=0, MaximumUnique=0, MaximumSequentialRepeat=0, MinimumNumeric=0, AllowLastCharSpecial=true, PolicyEnabled=true, MaximumSpecial=0, ADComplexityMaxViolations=false, MinimumUpperCase=0, AllowFirstCharSpecial=true, DisallowedValues=[], AllowLastCharNumeric=true}

That didn’t look right so we decided to attempt to set a password through iManager by doing a Set Universal Password on the user object.  Doing this revealed the truth of the problem.  iManager threw an error that no password policy was assigned to our user.  From there we viewed the password policies in iManager and sure enough, no password policies were assigned to our users or our ou=users container in IDM.  You can’t assign an NMAS password without a password policy.

We assigned the proper password policy to the ou=users container in IDM and tried SSPR again with success.

There may be other circumstances that could cause this error but in this case, the error was a response to SSPR’s inability to set a temporary password in IDM due to a missing password policy assignment to the user or user container.

And upon additional review, we talked about the initial SSPR configuration and discovered that the LDAP Test User setting had been left blank during setup because the test account specified encountered NMAS errors.  This made sense knowing the impact the lack of a password policy assignment had with the user activation.  Having solved the activation error, we added the LDAP Test User data back to the SSPR configuration with no issues.

Morale of the story:  If you want to SSPR with eDir, make sure you have your password policy assignments in place in eDirectory first!