Environment
Self Service Password Reset
SSPR 3.x
SSPR 4.x
eDirectory grace logins configured
Situation
SSPR consumes eDir grace logins
Users can’t log in to SSPR
eDirectory account is locked; no grace logins remain
Resolution
At least two options are available to avoid this situation:
1) If possible, disable grace logins on the eDirectory password policy. When configured this way, eDirectory itself won’t force users to change an expired password during authentication, but applications such as SSPR can still do so.
2) Increment the allowed grace login value to account for a typical user authentication operation happening multiple times. This won't resolve the problem exactly but it can decrease the amount of users that will hit the limit.
In either case, consider the following settings in SSPR config manager, under Modules, Change Password:
Password Pre-Expire Time
Password Expire Warn Time
Check Expire During Authentication
With these settings in place users will:
1. If they are within the “Password Expire Warn Time,” see a warning when logging in to SSPR telling them their password will expire in x number of days.
2. Be forced to change their password if they are within the “Password Pre-Expire Time.” This helps prevent users from experiencing password expiration during the middle of a session.
3. Be forced to change their password if it has expired.
NOTE: The above settings are enforced when the user attaches to SSPR, not when a user logs in to eDirectory or other applications and systems that use eDirectory. However, it is possible to direct users to pass through SSPR during their login process, thus allowing SSPR to enforce the above password expiration settings. This can be accomplished as follows:
1. Use the Client Login Extension (CLE) to force users to change expired passwords when logging into windows desktop. CLE can also be used to force Challenge/Response enrollment and other SSPR operations.
2. Integrate SSPR with Access Manager or other web SSO technologies to force users to pass through SSPR during authentication. This approach can force web users to reset expired password during authentication
Cause
SSPR makes LDAP binds, and each LDAP bind operation decrements the grace login count.
Additional Information
Attempting to integrate SSPR with an SSO provider like Access Manager or other login provider can lead to confusing results in regards to eDirectory grace logins. While you may expect that grace logins will decrement in a predictable way when a user logs into your system, you will find that grace logins are consumed unexpectedly and sometimes unpredictably. This is because when multiple components of your authentication system are configured to use LDAP, grace logins can be consumed by each component.
The core issue is that when using LDAP, each LDAP bind operation which happens at the beginning of a connection will decrement the grace login count. Applications can use connection management techniques that disable idle connections and reconnect when needed, or use connection pools to limit the total connection count. Both of these techniques can lead to additional unexpected LDAP binds. Further, load balancing and high-availability architectures can result in additional connections. The end result is that a single user's login process can execute multiple LDAP binds that cause multiple grace login decrements.
When these systems exhaust the grace logins remaining, failure can happen in odd ways such as the authentication gateway allowing login but an application failure happening during the session, or an application may return an error trying to read data from the directory.
SSPR itself will perform at least one, and sometimes more LDAP binds when a user attaches. SSPR tries to limit bind operations when a grace limit state is detected, but it is not always possible to limit the connections.