SSPR Account Claiming Gotcha

As part of the provisioning process, it is common that users have to perform an account activation or claiming step. Sometimes this as simple as clicking a link in an email, while others require you to type in some code or value from and email, and even others goes as far as to require you to enter identity data not communicated as proof of one’s identity.

NetIQ has embraced this process in the Self-Service Password Reset (or SSPR) web-based self-service portal.  Account activation is a feature that is offered out-of-the-box and is easily configurable to support various activation requirements that companies may have.  But, while the tool offers this functionality there are some behind-the-scenes processes within SSPR that you may need to be aware of before enabling this feature.

First off, by default, account claiming/activation is a “one-and-done” process.  By this, I mean that once a user starts that process through the SSPR interface that they can never do it again.  If for any reason that user loses connection to the SSPR web server or their activation session times out (standard 20-minute session timeout applies) the user will not be able to make another attempt at claiming their account without administrative assistance.

The default behavior within SSPR limits the activation process to only accounts that have never logged in before and even though the user has not logged-in in normal terms, once they begin the activation process the tool pseudo-logs the user in and their Last Login Time attribute is updated in eDirectory.  With that value set in eDir, the default behavior of SSPR will assume the account has already been claimed and it will block future activation attempts.  eDir admins can always clear that field manually and users can try again but relying on users to escalate the issue to an IDM admin who then has to perform a manual task is an unnecessary delay and end-user frustration.

Instead, in the SSPR configurations, an SSPR admin can define a custom LDAP query filter for the activation process. Through this custom LDAP filter, admins can specify additional attributes that must be populated to denote if an account is or isn’t eligible for activation.  Commonly this is a boolean value that would only get set after activation has completed.  This would allow users to attempt activation multiple times until they were able to complete the process.

The custom attribute update is also accomplished through SSPR. Again, in the SSPR configurations an admin can define a post-activation activity that executes an LDAP command to update one or more attributes in eDirectory.  Since that process only executes at the end of the activation process, users would always be allowed to claim accounts multiple times until this condition was met.

However, the biggest gotcha in the SSPR activation process is a step the system takes that cannot be altered through the product configurations.

During the activation process, SSPR will actually set a random password for the user’s account in IDM. This password logic cannot be disabled or altered through the tool at this time. (SSPR v3.3 is current release at the time of this blog’s writing).  Once the user completes the activation process the tool will prompt the user to set a password of their choosing but initially the tool will assign a random password to the IDM account even if the account already has a password assigned in IDM.

The real issue with this random password enforcement comes into play when the account is distributed in other systems where password sync is enabled.  This means that as the SSPR tool changes or sets a password in IDM as part of the activation process the random password is then pushed out to the other systems. For new users that have never accessed any systems this may not be that big of a deal but when SSPR is added to existing systems where claiming is used for existing accounts it can cause issues by overwriting valid passwords in those systems with the random password set by SSPR.

For the most part, this may not sound like a problem but consider when a user starts the activation process but fails to complete it. In that scenario, a user could have an existing AD account with an existing, valid password. As part of the SSPR roll-out users are encouraged to “claim” their accounts through SSPR to force challenge questions and password synchronization across connected platforms. During that process, SSPR randomly sets a password in IDM that is then synchronized to AD but the user fails to complete the activation process. In that event, the user’s AD account password would now be some random value that the user is unable to change or manage without completing the activation process or with the help of some other entity like an IDM administrator or Help Desk personnel. And since there is no disclaimer or feedback in the SSPR tool that would make users aware that the random password has been assigned during that process the end-user would have no clue that their existing AD password was changed to some random value. This could cause a number of authentication issues for users who found themselves in that situation.

And just as a side note: never require users to enter information as part of the claiming process that is not guaranteed to exist in the directory for all users.  

For example, do not ask users for a date of birth in the claiming process unless all users will have that value in IDM prior to claiming the account. It’s one thing for a user to experience a technical issue that prevents them from completing that process but it’s another thing when bad data or processes encourage users to perform actions that they cannot complete.