Part Two: Biometrics and smart-cards are hot, but a sane password policy can do a lot to keep your network secure. Here's how to give would-be crackers the boot with the Win2k3 Account Lockout Policy.
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.
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
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
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.
Continued on page 2: Auditing Logon Activity
Continued From Page 1
Auditing Logon Activity
With your Password and Account Lockout Policies
configured, you are well on your way to creating a more secure
authentication environment. However, there is one more aspect of the
authentication system that you should consider – logon auditing.
While Password Policies and Account Lockout Policies control what
passwords are in use, and what happens when passwords are entered
incorrectly, as an administrator you'll want to stay on top of what
authentication failures are occurring and where. A user who enters the
wrong password multiple times and ends up being locked out is likely to
call you to get the account reset, alerting you to the issue. A hacker
is less likely to make that call.
Figure 2. |
(Click for a larger image)
By default, successful logon events through domain controllers
are recorded in the Security log of the system on which the logon
occurs. This is by virtue of the Audit Policy that is configured
through the Default Domain Controller Security Policy. This information
is useful for determining what user successfully logged on and when,
but it is no help in identifying logon failures. For that, you'll need
to enable auditing of Failed Logon attempts as well. This can be
achieved through the Local Policies, Audit Policy node of the Default
Domain Controller Security Policy. A policy configured in this way is
shown in Figure 2.
With the policy set, you can use the Event Viewer to see what failed
logon attempts have occurred on the system. An example of a Security
log with a series of failed logon attempt is shown in Figure 3.
Figure 3. |
(Click for a larger image)
Irrespective of whether or not you set the Audit policy to
record failed logon attempts, you should get into the habit of checking
the Security log on a regular basis. It is a good way of identifying
potential security issues before they turn into definite problems.
Password Usage Policies
In addition to computer-based policies like the Password
and Account Lockout policies, you should also have a paper-based
password usage policy in place. This policy, which should be made
available to employees when they join the organization, specifies what
you expect of them in relation to password use.
At the very least, the password usage policy should state that the
user must not give their password to anyone else, and that they must
make every reasonable effort to ensure that the password does not
indirectly become known to anyone else. It should also specify the
procedures that must be followed if the user realizes that their
password has become compromised. This last point is very important, as
it can significantly reduce the time that an exposed password remains
'in the wild'.
Although many organizations already do include a password use policy
as part of their computer use policy, it is worth considering creating
a completely separate document specifically to cover passwords. A
separate document reinforces the importance of the policy, and
increases the chances that new employees will read and understand the
points described, rather than just skimming past the sections on
password use in a larger document and then signing on the dotted line.
As with all other computer use policies, the document should also
describe what steps will be taken to deal with infractions.
So as you can see, with the right policies and procedures in place,
even passwords can provide a sufficient level of protection to all but
the most security conscious networks. But in Part Three of this
article, we'll look at what your options are to take the authentication
security of your Windows Server 2003 network one step further. Until