Enable Disabled Users in Directory with SSPR User Activation Module - Error 5026

  • 7018406
  • 20-Dec-2016
  • 13-Oct-2017

Environment

Self Service Password Reset 3.x, 4.x
Active Directory
eDirectory

Situation

When trying to activate a new user in SSPR with the User Activation Module enabled, the process fails. The following error occurs:
SSPR 5026 Unable to establish session password.

Logs also indicate the following error:

2016-12-20T20:41:00Z, FATAL, servlet.AbstractPwmServlet, 5026 ERROR_BAD_SESSION_PASSWORD (unable to authenticate with password read from directory, check proxy rights, ldap logs; error: 5066 ERROR_ACCOUNT_EXPIRED (unable to create connection: unable to bind to ldaps://chansen2.lab.novell.com:636 as cn=gilgamesh,ou=users,o=data reason: [LDAP: error code 53 - NDS error: log account expired (-220)]))

Resolution

There are a few important areas to verify in your SSPR configuration.
  1. Make sure that Unlock User During Activation is set to Enabled.
  2. Verify that when you click "View Matches" under the Activation Permission that valid users come up.
    A useful parameter is to have loginDisabled=TRUE. Use the following as an example filter: (&(objectclass=person)((loginDisabled=TRUE)))
  3. *Most important setting* Create a new Action under Activation Actions (Before Password Change) to have SSPR change the loginDisabled=TRUE to FALSE on the user attempting activation. Use the following steps to do that:
    • Click Add Action.
    • Give your Action a name.
    • Change "webservice" to "ldap".
    • Click the Options button.
    • Set Attribute Name to loginDisabled
    • Set Attribute Value to FALSE
    • Leave Operation Type as Replace.
    • Save these changes.

Cause

Without the proper settings, SSPR will attempt to make a password change on the user prior to the user being enabled from a disabled state. Because of this, LDAP errors will come up since a disabled user is not allowed to authenticate. The above steps will use the rights for the SSPR Proxy User in your SSPR settings to process any "Before Password Change" actions, in this case changing loginDisabled to False. Then after that is processed, it will use the User's rights to continue with the rest of the activation process.

Additional Information

Do note that this process can be applied for any other LDAP changes in your environment that you'd wish to do at activation. This process is not limited to loginDisabled.