Set the account lockout threshold to recommended value

  • Article

Why Consider this

The account lockout policy does not currently set the account lockout threshold to the recommended value. The account lockout threshold should either be set to 0, so that accounts will not be locked out (and Denial of Service (DoS) attacks are prevented), or to a sufficiently high value so that users can accidentally mistype their password several times before their account is locked, but which still ensures that a brute force password attack will lock the account.

Watch a Customer Engineer explaining the issue

Context & Best Practices

Password attacks can use automated methods to try millions of password combinations for any user account. The effectiveness of such attacks can be almost eliminated if you limit the number of failed logons that can be performed. However, a Denial of Service (DoS) attack could be performed on a domain that has an account lockout threshold configured. An attacker could programmatically attempt a series of password attacks against all users in the organization. If the number of attempts is greater than the account lockout threshold, the attacker might be able to lock out every account.

Because vulnerabilities can exist when the account lockout threshold value is configured as well as when it is not configured, two distinct countermeasures are defined. Any organization should weigh the choice between the two based on their identified threats and the risks that they want to mitigate. The two countermeasure options are:

  • Configure the Account lockout threshold setting to 0. This configuration ensures that accounts will not be locked out, and will prevent a DoS attack that intentionally attempts to lock out accounts. This configuration also helps reduce help desk calls because users cannot accidentally lock themselves out of their accounts. Because it will not prevent a brute force attack, this configuration should only be chosen if both of the following criteria are explicitly met:
    • The password policy requires all users to have complex passwords of 8 or more characters.
      • A robust audit mechanism is in place to alert administrators when a series of failed logons occur in the environment. For example, the auditing solution should monitor for security event 539, which is a logon failure; this event identifies that there was a lock on the account at the time of the logon attempt.
  • Configure the Account lockout threshold setting to a sufficiently high value to provide users with the ability to accidentally mistype their password several times before the account is locked, but ensure that a brute force password attack will still lock the account. This configuration will, therefore, prevent accidental account lockouts and reduce help desk calls, but will not prevent a DoS attack.

If this policy setting is enabled, a locked-out account will not be usable until it is reset by an administrator or until the account lockout duration expires. This setting will probably generate a number of additional help desk calls. In fact, locked accounts cause the greatest number of calls to the help desk in many organizations. If you enforce this setting an attacker could cause a denial of service condition by deliberately generating failed logons for multiple user, therefore you should also configure the Account lockout duration to a relatively low value such as 15 minutes.

Suggested Actions

Use Group Policy Management Editor (GPME) to open the Group Policy Object (GPO) that contains the effective password policy for the domain; this GPO could be the Default Domain Policy or a custom GPO linked above (that is, with higher precedence than) the Default Domain Policy.

In GPME, navigate to Computer Configuration\Windows Settings\Security Settings\Account Policies\Account Lockout Policy.

Configure the Account lockout threshold setting to either 0, so that accounts are never locked out, or n, where n is a sufficiently high value to provide users with the ability to accidentally mistype their password several times before the account is locked, but ensure that a brute force password attack will still lock the account. The current Microsoft Security Compliance Toolkit (SCT) baseline recommended value for n is 10.

Note that if fine-grained password policies are being used, the default domain policy may not affect all accounts; in such cases, you should also therefore check the reversible encryption setting in these fine-grained password policies.

Learn More

For more information on account lockout settings, see Configuring Account Lockout.