How an incorrectly configured account lockout policy can give more pain than security.

I don't believe this..... we still see environments with Account Lockout policy set with a threshold of 3, with lockout duration of 2 or 5 minutes etc.

Most of them, spend a good amount of money and time addressing these lockouts, and affecting business functions while the addressing them.

I have tried to list down some points that will indicate that the Account lockout policy with a low threshold, like 3 is NOT recommended. In fact an INCORRECTLY configured Account Lockout policy will cause more downtime for the business them help it.

A better security practice it to have a

- Strict password policy + disabled account lockout policy
OR
- Strict password policy + correctly lockout policy with high lockout threshold.

 

1. Microsoft's recommendations:

https://technet.microsoft.com/en-us/library/cc757692(WS.10).aspx  

"Brute force password attacks can be automated to try thousands or even millions of password combinations for any or all user accounts. Limiting the number of failed logons that can be performed nearly eliminates the effectiveness of such attacks.

However, it is important to note that, in contrast, a denial-of-service attack could be performed on a domain that has an account lockout threshold configured. A malicious user could programmatically attempt a series of password attacks against all users in the organization. If the number of attempts is greater than the value of Account lockout threshold, the attacker could potentially lock out every account.

Because vulnerabilities can exist both when this value is configured and when it is not, any organization should weigh their identified threats and the risks that they are trying to mitigate. There are two options to consider for this policy setting:

Set Account lockout threshold to 0. This ensures that accounts will not be locked out. This setting will prevent a denial-of-service attack that intentionally locks out all or some accounts. In addition, this setting helps reduce Help desk calls because users cannot accidentally lock themselves out of their accounts.

Because it will not prevent a brute force attack, a value of 0 should only be chosen if both of the following criteria are explicitly met:

- Password Policy settings force all users to have complex passwords made up of eight or more characters.

- A robust auditing mechanism is in place to alert administrators when a series of failed logons are occurring in the environment.

If these criteria cannot be met, set Account lockout threshold to a high enough value that users can accidentally mistype their password several times before they are locked out of their account, but ensure that a brute-force password attack would still lock out the account. It is advisable to specify a value of 50 invalid logon attempts. Keep in mind, however, that although this setting can reduce the number of Help desk calls by reducing the number of user lockouts, it cannot prevent a denial-of-service attack."

 

2.   Security Configuration Benchmark for Windows environment from ‘Center for Internet Security’

https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v1.1.0.pdf

“Account lockout threshold
Description:
This control defines the number of failed logon attempts before a user is locked out of an account. It is recommended that this setting be configured as described below:
- For the SSLF profile(s), the recommended value is 10 invalid logon attempt(s).
- For the Enterprise profile(s), the recommended value is 50 invalid logon attempt(s).

Rationale:
Enforcing an account lockout threshold will almost eliminated the effectiveness of automated brute force password attacks and improves the security of a system”

 

3. Security Configuration Benchmark for Windows environment from “National Security Agency”

https://www.nsa.gov/ia/_files/os/win2003/oldFiles/MSCG-001R-2003.pdf

“Account lockout threshold
Table 2.10: Settings

Domain Member Default Legacy Client Enterprise Client High Security
0 invalid login attempts 50 invalid login attempts 50 invalid login attempts 10 invalid login attempts

The Account lockout threshold setting determines the number of attempts that a user can make to log on to an account before it is locked. Authorized users can lock themselves out of an account by incorrectly entering their password, or by changing their password on one computer while logged on to another computer. The computer with the incorrect password may continuously try to authenticate the user, and because the password it is using to authenticate is incorrect, the user account is eventually locked out. To avoid locking out authorized users, set the account lockout threshold to a high number.”

4. Other popular blogs talking about the same:

https://www.windowsecurity.com/articles/Implementing-Troubleshooting-Account-Lockout.html

5. Below are some numbers that will help you understand the above recommendations better.

 

* *Assuming that you have an account lockout policy with a threshold set to 3, lockout duration of 0 and a password policy with minimum password lenght of 8.

An analysis of your current lockout and password policy is as follows:-

94 possible characters ^ 8 character per password (minimum password length) = 6,095,689,385,410,816 possible passwords.

You guess a password on average half way through a brute force attack = 6095689385410816 / 2 = 3047844692705408 average guesses required.

Because the lockout duration is not defined and accounts are only unlocked by Administrators, we have to pick an average amount of time it might take an account to be unlocked. Let's assume 30 minutes (it's probably longer which will reduce the odds further). Another reason why I'm taking 30 minutes is because if the lockout duration is defined, it would mostly be 30 minutes.

Only 3 guesses i.e. bad passwords (current threshold) can be accepted by AD every 30 minutes (approx. lockout duration) = 1 guess every 10 minutes.

Each password remains the same for 42 days (assuming you have a max password age is 42 days, which is the default), so you have

42 days * 24 hours per day * 60 minutes per hour * 1/10 guesses per minute = 6048 guesses per password lifetime.

The average chance of guessing the password = 6048 guesses per password lifetime / 3047844692705408 average guesses required = 1 in 503942574852 chance of guessing the password in 42 days.

If the lockout threshold were increased from 3 to 10, the chance of guessing the password over the 42 day password lifetime would be 1 in 151182772455. Still quite small!!

Increasing the required password length to 9 with an account lockout threshold of 10 results in the chance of guessing the password over the 42 day password lifetime of 1 in 14211180610828 - a chance 28 times stronger than the earlier policy with threshold of 3.

 

The above information was about the lockout threshold, now taking of the Account lockout duration,

It is advisable to set Account lockout duration to approximately 30 minutes. A value of 0 specifies that the account will be locked out until an administrator explicitly unlocks it.

To configure the value for this policy setting so that it never automatically unlocks the account might seem like a good idea, because then the admins/helpdesk gets a chance to investigate the cause of lockout, but doing so can increase the number of requests that your organization’s Help desk receives to unlock accounts that were locked by mistake.

To unlock the account automatically after a nn number of minutes, it needs to be set along side auditing so that the administrator gets to know if there are unusual amount of lockouts which need investigation. We recommend that you atleast set the lockout duration to 30 mins. If you reduce the lockout duration further down (like 2 or 5 minutes) to reduce the impact to the end user, you are undoing the purpose of having a account lockout policy and also adding up to the AD replication traffic.

 

Hope the above information helps you configure the account lockout policy correctly.

 

regards

Abizer

Comments

• Anonymous
  November 26, 2014
  So in a dos attack, how does one prevent the admin account from being locked out, thus allowing access to unlock other locked accounts?
• Anonymous
  May 11, 2015
  @Nick: You should have at least one, but in practice multiple, admin (and helpdesk) accounts exempt from the lockout policy. These should have much stronger passwords, especially passwords that are not predictable and guessable. You can please almost any password policy with a password like "Company2015/05", which is easily updated every 42 days when the policy demands it. Users exempt from the lockout policy should be trained to avoid such password complexity pitfalls. You should configure an alert when you start logging excessive failed password attempts for any such account. Note that often non-managed service accounts also fall into this category.
• Anonymous
  October 01, 2015
  If an Admin account's lockout duration is set to Never, but the lockout observation is set to 1 hour the account is never locked out right?