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-lockedoraccount-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-lockedoraccount-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.