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.
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:
- 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.
- 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.
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 first published in May 2008
Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.