Home > Windows Server Tips > Active Directory Administration > Mastering account lockout values in Group Policy
Windows Server Tips:
EMAIL THIS
 TIPS & NEWSLETTERS TOPICS 

ACTIVE DIRECTORY ADMINISTRATION

Mastering account lockout values in Group Policy


By Gary Olsen, Contributor
05.13.2008
Rating: -4.29- (out of 5)


Expert advice on Active Directory and Group Policy
Digg This!    StumbleUpon Toolbar StumbleUpon    Bookmark with Delicious Del.icio.us    Add to Google


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.

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.

[IMAGE]

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 secre


Digg This!    StumbleUpon Toolbar StumbleUpon    Bookmark with Delicious Del.icio.us    Add to Google


RELATED CONTENT
Microsoft Group Policy Management
Using Active Directory to manage Macs in a Windows environment
Group Policy Object modeling simplifies network security
Microsoft Group Policy Tutorial
Is a Group Policy setting changing my user rights?
Group Policy Object security in Windows
Deny access to Windows system properties with GPOs
Advanced Group Policy for Windows Vista
Windows Server 2008's Group Policy has faster searching and filtering
Why don't I have proper Windows Server 2003 rights to open a GPO?
Understanding Group Policy basics for Windows Vista

Microsoft Active Directory Security
Cutting the cost of Windows identity and access management
Common Active Directory security oversights
Taming the LSASS.exe process for Active Directory performance and security
Branch office security: Pros and cons of read-only domain controllers
Breaking down the RODC with Windows 2008
How to use a GPO to improve Windows folder security
Rights management in Windows: Security expert roundup
Windows network rights, password policy and network security testing
How to manage network access for single users in AD
LocalSystem account in the AD forest is risky business

Active Directory Administration
Using Active Directory to manage Macs in a Windows environment
Troubleshooting poor Windows logon performance in Active Directory environments
Common Active Directory security oversights
Scripting domain controller installations: A must for Server Core
Taming the LSASS.exe process for Active Directory performance and security
Troubleshooting Active Directory database errors
Active Directory database basics: Performing an offline defrag
Branch office security: Pros and cons of read-only domain controllers
Tips for Windows domain controller optimization
How to rebuild the SYSVOL tree when none exists in Active Directory

RELATED GLOSSARY TERMS
Terms from Whatis.com − the technology online dictionary
Group Policy Object  (SearchWindowsServer.com)

RELATED RESOURCES
2020software.com, trial software downloads for accounting software, ERP software, CRM software and business software systems
Search Bitpipe.com for the latest white papers and business webcasts
Whatis.com, the online computer dictionary


t 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

[TABLE]

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.

[IMAGE]

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:

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.


Rate this Tip
To rate tips, you must be a member of SearchWindowsServer.com.
Register now to start rating these tips. Log in if you are already a member.




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.



Server Room Design - Planning, Cooling, Maintenance
HomeTopicsBlogsITKnowledge ExchangeTipsAsk the ExpertsMultimediaWhite PapersIT Downloads
About Us  |  Contact Us  |  For Advertisers  |  For Business Partners  |  Site Index  |  RSS
SEARCH 
TechTarget provides technology professionals with the information they need to perform their jobs - from developing strategy, to making cost-effective purchase decisions and managing their organizations' technology projects - with its network of technology-specific websites, events and online magazines.

TechTarget Corporate Web Site  |  Media Kits  |  Site Map




All Rights Reserved, Copyright 2004 - 2009, TechTarget | Read our Privacy Policy
  TechTarget - The IT Media ROI Experts