Win2k3 Password Policies Lock Out the Badguys - Page 2

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.

Next Week….
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 then!