Problem solve Get help with specific problems with your technologies, process and projects.

Mastering account lockout values in Group Policy

Tweaking account lockout values can save money for your company by eliminating help desk calls for users' account lockouts.

Gary Olsen, contributor
Gary Olsen

Some of the most confusing values of all the Group Policy settings are the account lockout values, whose sole purpose in life is to provide protection for passwords against hackers trying to guess them.

Yes – there really is someone out there trying to guess your passwords.

Microsoft's Account Lockout policy offers protection by making it harder to guess passwords. Hackers rely on a dictionary of common passwords -- names, places, movie characters and so on as well as the brute force attack. Left alone, a hacker could run a password cracker and eventually guess the password. One way to stop that is to only permit a certain number of guesses, called a "lockout threshold," before the hacker locks himself out of the account.

More on Active Directory
and Group Policy
Troubleshooting account lockouts in Group Policy

Unlocking Group Policy account lockout secrets
When locked out, users must wait until a Windows admin unlocks the system or else wait until the "lockout duration" expires. So, with a threshold of three tries and a duration of 30 minutes, our hacker has to wait 30 minutes for only three guesses at a time. Additionally, there is the "reset" counter. When the reset counter expires, users get a fresh threshold count -- another three attempts. These values are set in Group Policy as shown in Figure 1.

Figure 1: Values are set in Group Policy

It is important to know that the threshold counter can be incremented by other than someone making bad password guesses. Service account passwords can easily get out of sync with the application using them, and applications that run under a user's context can lock out that account. Also having mapped network drives or being logged onto multiple clients when the password is changed will quickly lock out the account.

The problem with account lockout is that it is a major pain point for users. The bottom line is the tighter the account lockout restrictions, the better it is for security. But it's worse for users, which means more annoying calls to the help desk. The secret then is to get a threshold value that is high enough to allow for user mistakes and for other non-security reasons to be absorbed without locking out the account.

There are some important things that admins must know to make this all work as expected. The default lockout threshold values shown here are from Table 2.2 of Microsoft's Windows XP Security Guide. EC refers to "specialized client" and SSLF is Specialized Security Limited Functionality. So if you want reasonable security that is accommodating to users, use the EC values. If you want high security, use the SSLF settings.

Table 2.2: Account lockout policy setting recommendations

Setting Domain controller default EC SSLF
Account lockout duration Not defined 15 minutes 15 minutes
Account lockout threshold 0 invalid logon attempts 50 invalid logon attempts 10 invalid logon attempts
Reset account lockout counter after Not defined 15 minutes 15 minutes

In Figure 2, the default lockout threshold is zero. This effectively disables all account lockouts. A default of zero is markedly different from the always popular "not defined." I have talked to admins who assumed "not defined" meant zero. Actually, "not defined" means a threshold of 5.

Figure 2: The default lockout threahold is zero

The interesting thing is that Microsoft recommends a value of 50 as a reasonable number and 10 for a high security condition. It's not uncommon to see a value of 3 for the threshold. Even Microsoft says that a threshold value of 3 will be tripped by normal conditions as noted here.

My recommendation is to do the following:

  1. Turn up auditing on logon failures and inspect security logs for failed logons by hackers or viruses. If the logon failures are from a user who probably just guessed the wrong password, ignore them. Look for repeated attempts to log on as Administrator or Guest – commonly known accounts that a virus would try to use. If you don't see any of those in a sampling of servers and clients, you can probably relax the threshold value. If you have security demands from your company, then you'll have to honor those requirements.
  2. Set the lockout threshold to 10. Monitor the lockouts. You can download the AITools.msc account lockout tools from Microsoft's download site. One of the tools is the Lockout Status tool shown in Figure 3.
  3. Figure 3: The Lockout Status tool

Use it to watch the account lockout status for any user -- one at a time, unfortunately. The calls to the help desk will be a good indicator as well. If you have a large number of lockouts, raise it to 15 or 20. Test again, and check security logs to make sure you aren't being attacked. Or save yourself some time and set it at 20. If you aren't being attacked and the users don't call the help desk, then it's good. Remember, Microsoft considers 50 a reasonable threshold.

There is one other option. Microsoft security expert Jesper Johansson said in his series The Great Debates: Pass Phrases vs. Passwords that an eight-character complex password would take six years to crack, but we usually consider it will be found in half the total time. His recommendation is to turn Account Lockout off. If it will take three years to crack a password, and you force a password change in 90 days, why bother with the account lockout pain?

My employer has adopted a strategy of requiring a 12-character password and a maximum password lifetime of one year. So there are certainly better options than messing with Account Lockout. You could argue, however, that a lockout threshold of 50 will probably never affect a user, and that it gives you reasonable protection. With a password policy of eight or more characters and required complexity, you should be able to sleep well at night.

There may be political reasons to do it differently. If it is just a requirement handed down from management, it may be worth educating management using Johansson's articles. Let them know this could be a cost savings -- through the elimination of help desk calls for account lockouts.

Gary Olsen is a systems software engineer for Hewlett-Packard in Global Solutions Engineering. He wrote Windows 2000: Active Directory Design and Deployment and co-authored Windows Server 2003 on HP ProLiant Servers. Olsen is a Microsoft MVP for Windows Server-File Systems.

This was last published in May 2008

Dig Deeper on Windows systems and network management

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.