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.