Welcome back to our look at increasing the strength of the authentication systems on your Windows Server 2003 network. In Part One, we began our look at the policies and procedures that you can use to make the default authentication system – passwords – as secure as possible. In this installment, we'll continue this process, and also discuss some of the non-computer based policies you should have in place to govern password use. We'll begin, though, by looking at an important part of your Active Directory based authentication system – the Account Lockout Policy.
The Account Lockout Policy
Simply put, the Account Lockout Policy dictates what happens when a password for a user account is entered incorrectly. Depending on the threshold specified in the policy, the user account in question can be left alone so that another login can be attempted, or it can be locked out preventing any more attempts at gaining access. There are three settings to the Account Lockout Policy, as you can see in Figure 1.
(Click for a larger image)
Unlike the Password Policy, settings in the Account Lockout Policy are not configured by default, so you should enable them. The first decision to make is how many times you want the wrong password to be tried on an account before the account is locked out. This is defined by the Account Lockout Threshold setting. The default value of zero means that incorrect passwords can be entered an unlimited number of times before the account is locked out. In a moderately secure environment, a setting of three is considered sufficient to allow the user enough tries to access the system. Any more than three, and you can surmise that either the user has forgotten the password, or that someone is trying to crack the password on the user's account.
Once the threshold is reached and the account locked, you can determine how long it stays in that state through the Account Lockout Duration setting. A value of zero will mean that the account lockout will need to be cleared manually by an administrator. Alternatively, you can set a time period after which the account will be automatically unlocked.
The last option in the Account Lockout Policy is the Reset Account Lockout Counter After setting. This allows you to specify how long the system will remember the failed logon attempts. For example, if you set the Account Lockout Threshold setting to 3, and the Reset Account Lockout After parameter to 30 minutes, you would be able to have two failed logon attempts in each 30 minute period without locking the account.
Even in a moderately security conscious environment, the only setting that is worth configuring from the Account Lockout Policy is the Lockout Threshold. Once that threshold is reached, it seems only reasonable that the user should call the help-desk (or you) and get the user account unlocked. Configuring automatic resets and account lockout counter resets might make your authentication strategy seem more complete, but in practice it simply weakens the overall policy. Besides, don't you want to know when a user is having password problems bad enough that they need to try passwords more than three times without getting it right? With automatic resets configured, you may never get to find that out.
The problem is, though, that Microsoft believes that if one part of the Account Lockout policy is configured, other parts should also be configured to complimentary settings. In fact, setting the Account Lockout Threshold to 3 failed attempts causes the Account Lockout Duration and Reset Account Lockout Counter After parameters to be automatically set to 30 minutes apiece. Therefore, in order to get the desired scenario of accounts not automatically resetting, and to effectively negate the system remembering the number of failed attempts in a given period, you can simply configure the settings to their highest value of 999999 minutes, which is almost 1667 hours, or over 69 days. It would be an exceptionally patient user or hacker who could use those thresholds to their advantage.