Active Directory: Clarifying Domain Account Password and Lockout Policy - Operational Monitoring
There have been quite a lot of discussions and articles regarding what should be the recommended setting for domain account lockout policy. And the worst is that there could be two different approaches: one pure AD, and the other one AD security (hardening).
Actually, even when considering security hardening, the recommended default policy for domain account lockout is to configure the account lockout threshold to 0 (no lockout), as explained here:
http://technet.microsoft.com/en-us/library/hh125920(v=ws.10).aspx#BKMK_AccountLockoutSettings
Countermeasure
Because vulnerabilities can exist when this 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 policy setting to 0. This configuration ensures that accounts will not be locked out, and it prevents 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 does not prevent a brute force attack, this configuration should be chosen only if both of the following criteria are explicitly met:
- The password policy requires all users to have complex passwords of 8 or more characters. AND
- A robust audit mechanism is in place to alert administrators when a series of failed logons occur in the environment.
Setting an account lockout policy too low will cause help-desk calls to unblock account improperly locked, due to invalid logon attempts, or a scenario where a user changes his password while being logged on multiple computers.
There could be a worse scenario, in which a malware is running on the network, attempting a brute force attack against all user accounts. This will result in all accounts being locked, maybe even the ones for helpdesk, in charge of unlocking accounts. As a result, only the domain administrator account, that can't be locked, will be available. And very likely the account lockout policy will be then disabled.
Complex and long password provides a first level of security against brute force attacks, as described in the chapter "Minimum password length" of http://technet.microsoft.com/en-us/library/hh125920(v=ws.10).aspx#BKMK_PasswordPolicySettings
[quotation]
The longer a password is, the better security it provides, especially if it includes a character combination of uppercase and lowercase letters, digits, symbols, and punctuation. The following table shows the amount of time that it would take a computer that is performing a brute force attack (at 10 million character combinations per second) to discover a password for a user account.
| Password length | Alphanumeric case-sensitive (62 characters) | Alphanumeric case-sensitive including symbols (96 characters) |
| 2 | Instant | Instant |
| 3 | Instant | Instant |
| 4 | Less than 2 seconds | 8.5 seconds |
| 5 | 1.5 minutes | 13.5 minutes |
| 6 | 1.5 hours | 22 hours |
| 7 | 4 days | 87 days |
| 8 | 253 days | 23 years |
| Note |
| A computer that could perform a brute force attack at a rate of 1 billion character combinations per second would take 83.5 days to discover an eight-symbol password that includes a combination of uppercase and lowercase letters, digits, symbols, and punctuation. |
As a result, we may consider, for employees ease of use, disabling complexity and requires a long password.
In all cases, password lifetime value should be set accordingly to the complexity / length required. As a side note, Microsoft CSS Security recommends the password length to be 15 characters at least (based on passphrases).
Please note that those above are the two sines qua none conditions for not enabling the automatic domain account lockout policy. But the main point may then be monitoring the events the audit mechanism reports.
In real life, obviously, administrators do need a tool to do it in an industrial and centralized way. A solution could be to implement Audit Collection Services, from SCOM (now part of the System Center suite). Here is an article explaining how to deploy it: http://technet.microsoft.com/en-us/library/bb309607.aspx
Now, if the 2 forementioned criteria are not met, the recommendation is then to enable a domain account lockout policy, but be aware of the risk of a denial of service conditions that may affect applications and user authentication (if the lockout is being triggered while there is no security incident).
The following article tells the current threshold recommendation (again from the article http://technet.microsoft.com/en-us/library/hh125920(v=ws.10).aspx#BKMK_AccountLockoutSettings)
Configure the Account Lockout Threshold policy 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 still locks the account. A good recommendation for such a configuration is 50 invalid logon attempts, which prevents accidental account lockouts and reduces the number of Help Desk calls, but does not prevent a DoS attack.
We recommend this option if your organization cannot implement complex password requirements and an audit policy that alerts administrators to a series of failed logon attempts. Using this type of policy must be accompanied by a good, fast process that can be implemented to unlock locked accounts when needed on weekends, at night, or during holidays to help mitigate massive lockouts caused by an attack on your systems.
And you may read the same from here (50 invalid logon attempts): http://www.microsoft.com/en-us/download/details.aspx?id=26137
Configure the **Account Lockout Threshold **policy 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 still locks the account. A good recommendation for such a configuration is 50 invalid logon attempts, which prevents accidental account lockouts and reduces the number of Help Desk calls, but does not prevent a DoS attack.
We recommend this option if your organization cannot implement complex password requirements and an audit policy that alerts administrators to a series of failed logon attempts. Using this type of policy must be accompanied by a good, fast process that can be implemented to unlock locked accounts when needed on weekends, at night, or during holidays to help mitigate massive lockouts caused by an attack on your systems.
Last, but not least, if you want to harden that policy, from a pure security point of view, the Best Practices Guide for securing Active Directory (see: /en-us/previous-versions/windows/it-pro/windows-server-2003/cc772803(v=ws.10)) recommends to lower the threshold to 20.
| Default | Recommended | Reason |
| Not defined | 0 minutes | The value 0 means that after account lockout an Administrator is required to reenable the account before account lockout reset has expired. |
| 0 invalid logon attempts | 20 invalid logon attempts | The value 0 means that failed password tries never cause account lockout. Because an account lockout duration of 0 minutes (administrator reset) is recommended, a small number for this setting can result in frequent administrator interventions. |
To finish with, please keep in mind the account lockout duration value is also quite important. From a security perspective, the value should be set to 0, this implying an administrator is required to reenable the account (before account lockout reset has expired). Once again, you may prefer:
- to enable and raise the "Reset account lockout counter after" value (most likely to mitigate a brute forcing attack)
and/or
- enable and raise the "Account lockout duration" value
Those values are complementary to the Account lockout threshold itself.