Failure lockout

PingDirectory server provides the ability to lock a user’s account after too many consecutive failed authentication attempts.

The lockout can be temporary, automatically expiring after a specified length of time, or permanent. In either case, an administrative password reset can be used to immediately restore access to the account.

However, actually locking a user’s account after too many failed authentication attempts can be problematic because it has the potential to block legitimate access to the server. If the password policy is configured with a lockout failure count value that is too low, then it is possible for a user to legitimately mistype their password enough times in a row to trigger the lockout. However, the bigger risk is that an attacker could purposefully lock a user’s account by intentionally making repeated failed bind attempts, denying the legitimate user access to their own account. To help protect against this, PingDirectory server offers support for alternative failure lockout actions. Rather than locking the account, the server can be configured to delay bind responses as a rate-limiting mechanism, or it can be configured to generate an account status notification to alert administrators to the problem or invoke custom processing.

The password policy configuration offers the following properties related to failure lockout:

lockout-failure-count: The number of consecutive authentication failures required to trigger the failure lockout action. This is zero by default to indicate that failure lockout is disabled, but if it is set to a nonzero value, then the appropriate failure lockout action is taken after that number of consecutive failed attempts. If the user binds successfully before the failure count is reached, then the record of failed attempts is cleared. The set of failed attempts is also cleared by an administrative password reset.
lockout-duration: The length of time that the failure lockout should be in effect. A value of zero seconds (which is the default) indicates that the lockout should be permanent, and that an administrative password reset is required to restore access to the user’s account. A value that is greater than zero indicates that the account is automatically unlocked after that length of time, although an administrative password reset can be used to restore access before that lockout period has expired.
lockout-failure-expiration-interval: The maximum length of time that the server should preserve information about a failed authentication attempt even if there is no intervening successful attempt or password reset. The default value of zero seconds indicates that failed attempts never expire, and they are preserved until enough failed attempts are accumulated to lock an account, or until a successful bind or an administrative reset clears the record of failed attempts.
ignore-duplicate-password-failures: Indicates that repeated failed authentication attempts that try the same wrong password should just be considered a single wrong attempt. If this is true (which is the default), then a client that repeatedly tries to bind with the same wrong password only accumulates a single failed attempt toward account lockout, regardless of the number of bind failures that actually occur. This is a safeguard to prevent issues that might arise if an account’s password is changed but there are applications still configured to use the old password. Using this option does not constitute an additional security risk because someone attempting an online guessing attack will try different passwords rather than repeatedly trying the same wrong password.
failure-lockout-action: Specifies the action that the server should take if the necessary number of failed attempts is reached.

See the config/sample-dsconfig-batch-files/enable-failure-lockout.dsconfig batch file for more information about enabling failure lockout.

Alternative failure lockout actions

As stated earlier, you can configure the server to take a variety of actions if the failure lockout count is reached.

Lock account

As its name implies, the lock account failure lockout action can be used to lock a user’s account. Any attempts to authenticate are rejected while the lockout is active, regardless of whether the correct credentials were provided. If a lockout-duration is configured in the password policy, then the lockout automatically expires after that length of time. Otherwise, it persists until an administrative password reset.

This lockout failure action does not offer any configurable properties.

Delay bind response

The delay bind response lockout failure action can be used to delay the response to bind attempts after the lockout failure count has been reached. Once the threshold has been reached, then subsequent bind attempts are delayed until the user successfully authenticates or until the password is reset.

If the server has delayed the response to any failed attempts, then the response to the next successful attempt will also be delayed. This helps prevent clients from using the presence of a delay as an indication of whether the password was correct.

Without this additional delay, an attacker could terminate the connection and establish a new one to make another attempt as soon as they detect the delay, rather than having to wait for the full duration of the delay.

The delay bind response failure lockout action offers the following configuration properties:

delay: The duration to use when delaying the response to the failed bind attempt. By default, a delay of one second is used.
allow-blocking-delay: Indicates whether the server should delay the bind response even doing so could block the thread being used to process the operation. This option applies to operations requested by non-LDAP clients. When delaying the response to an LDAP bind, the server is able to do so in a way that does not tie up any threads that could be used for processing operations. For other clients, like those using HTTP to communicate, the only option that the server has for performing the delay is to sleep on the thread that is processing the operation, which makes that thread unavailable for processing other requests until it’s done sleeping. This property is set to false by default, and if you want to delay the response to HTTP clients, then you should make sure to adjust the number of HTTP request handler threads to reduce the potential that all of them could be tied up sleeping on failed bind attempts.
generate-account-status-notification: Indicates whether the server should generate an account status notification if it delays a bind response. The account status notification uses a notification type of either account-temporarily-locked or account-permanently-locked, depending on whether the password policy is configured with a lockout duration. By default, no notification is generated.

No operation

The no operation failure lockout action does not take any client-visible action in response to reaching the lockout failure count. It offers a single configuration property:

generate-account-status-notification: Indicates whether the server should generate an account status notification, of type account-temporarily-locked or account-permanently-locked, if the failure lockout count is reached. This can potentially be used to notify administrators or optionally take some custom action using an account status notification handler created with the UnboundID Server SDK in the event of a failure lockout.