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

Checklist: Seven steps to properly set account lockout

Is it riskier to set account lockout or not? Weigh the pros and cons of using account lockout at all, and get seven steps for making these settings work to your advantage here.

My good buddy Scottie likes to quip that 'no good deed goes unpunished.' He's finding a lot of reasons to say this around the security folks we both know. It seems some true and tested security recommendations are backfiring. Specifically, let's take for example the usual advice to set account lockout options in a Windows domain.

If you do set account lockout and someone tries to logon to an account using the wrong password, the account will automatically lock after the specified number of tries -- and no one can logon using it.

Setting this option is supposed to provide two advantages:
1. A would-be attacker can't use the account unless he's capable of guessing the password within the number of tries you set.
2. If you have enabled auditing, configured it to record these events and reviewed your logs, you may discover these attempts at compromise.

On the other hand, setting this option may also bring two disadvantages:
1. Legitimate users may fumble-finger attempts at logon and lock themselves out. Does this seem far-fetched? I once did so in front of an audience of 500 people.
2. Automated attacks on accounts can trigger whole-scale lockout of multiple accounts. The password cracking attempt becomes a denial-of-service attack (and some say that may have been the goal).

Still, I believe that properly-implemented account lockout options can work to your advantage. Account lockout settings should be set in a Group Policy Object linked to the domain. You'll find them at Windows Settings/Security Settings/Account Policies/Account Lockout Policy. Here's how to use them.

You may download a printer-friendly version.

Checklist: How to properly set account lockout options
1. Set account lockout threshold to 25 invalid logon attempts
After 25 tries the account will be locked out. (Even I don't think I'd enter an incorrect password 25 times!) This should keep the authorized user from locking themselves out
just because they are having a brain hiccup. It does give the attacker a little more time to get the password, but unless the password is simple, 25 tries is hardly enough to
compromise the account.
2. Set account lockout duration to 30 minutes
For Windows Server 2003, this is the default if the threshold is set. The account lockout duration is the length of time that the account will remain locked out before it is reset. It's
a good idea to set this feature. The alternative is to require administrators to reset accounts, a time-consuming venture in a large environment -- a real show-stopper should you get
massive account lockout due to an automated attack. Yes, you will increase the risk that an attack can succeed. All the attacker has to do is wait out the lockout time and try again.
On second thought, make your account lockout duration something other than 30 minutes. Let's foil the would-be attacker reading this document.
3. Set the "reset account lockout counter after ..." option to 30 minutes
Windows keeps track of the number of bad password attempts in a lockout counter. This setting returns that total to zero after the number of minutes you prescribe. By providing a
time here, the counter won't continue to increase if the time limit is reached. That can also keep the help desk calls down. It also allows an attacker to program around your defense.
All she has to do is fly in under your radar (so to speak), sending, for example, 24 tries in 30 minutes, then none for a couple of minutes, then continue the cycle until she succeeds.
But she'd have to know your settings, and if you're doing a good job of reviewing your audit logs, you should notice this pattern pretty quickly.
4. Set auditing for logon events and monitor logs
Account lockout locks out accounts. That should let you know that something is amiss. However, if you aren't auditing logon events, you're missing many other more subtle
attempts at compromise. It may be the only way to nip such an attack in the bud or prevent it from occurring again by helping you discover the source of the attack.
5. Protect accounts from automated attacks originating from the Internet
Where would such attacks come from? Intuition says from the Internet. You shouldn't be able to logon from the Internet without some remote-access service such as a VPN.
Unless an attacker can establish such an authenticated, authorized connection, he can't run an automated attack from the Internet. Block NetBIOS ports from Internet access
and require the use of VPNs, SSL or other secure remote-access processes.
6. Protect accounts from automated attacks originating from external users
Protect accounts from automated attacks originating from partners, customers and others whom you may allow access to your networks. Isolate resources you make available to
these users. They shouldn't have free access to your entire network.
7. Protect accounts from insider attacks
This is the really rough one. Your legitimate users have to be able to authenticate to the domain. How can you protect yourselves from their abuse of this privilege? Every practice
that you adopt that limits users' ability to install and run unauthorized software helps you to mitigate this risk. Learn how to protect yourself from insider hacks in this
previous checklist by Roberta.

Windows Security Checklists offer you step-by-step advice for planning, setting up and hardening your Windows security infrastructure.
E-mail the editor
to suggest additional checklist topics.

Roberta Bragg is author of "Hardening Windows systems" and a resident expert. She is an MCSE, CISSP and Microsoft MVP, and a well-known information systems security consultant, columnist and speaker.

Click to ask Roberta a question or purchase her book here. Also, if you have specific questions or comments about any of Roberta's checklists, click to e-mail her directly. Copyright 2004

Dig Deeper on Windows Server troubleshooting