Upgrading and Repairing Networks

Passwords and Policies

Windows NT enables the administrator to set certain parameters that control passwords and accounts. This is called the account policy for the domain. To view the defaults or make changes, select Account from the Policies menu in the User Manager for Domains utility. The Account Policy dialog box (see Figure 36.15) is displayed.

As you can see, you can configure various settings here. The values you choose for these parameters should reflect the degree of security you want to enforce at your site. At the same time, you need to balance your concerns with the abilities of your users. For example, if you set a large minimum password size and a low value for the number of days it can be used, users might end up writing down passwords just to keep track of them.

These are the parameters you can configure here:

• Minimum Password Age and Maximum Password Age The Minimum Password Age specifies the number of days that must elapse before a user is allowed to change a password. The Maximum Password Age is the number of days that a password can be used, after which the system will force the user to change it. Both of these parameters can be set to a value ranging from 1 to 999 days.

• Minimum Password Length This is the minimum number of characters that must be used for a password. Too small a value will make it easy for hacker programs to guess a password. Too large a value will make it difficult for users to think up new passwords. This parameter can be set to a value ranging from 1 to 14, or you can permit a blank password (no password), although it is hard to imagine a network where you might want to allow, as a policy for every user in the domain, a blank password.

• Password Uniqueness The system will keep a history list of passwords used by each user and will not allow them to reset their password to one that is still in the list. This prevents users from constantly reusing a few easy-to-remember passwords, which can be bad for security purposes. Set this parameter to a value from 1 to 24. Selecting not to keep a history list is probably not a good idea because many users will take advantage of this option, and eventually someone else will find out what their usual password is.

• Account Lockout You can set up the system so that a user account is "locked out" after a number of failed login attempts. This can be used to prevent an unauthorized user from trying to guess a password for an account, as is done in the brute-force method by many hacker programs that simply go through a dictionary, trying every word until they crack an account. If you set a value for bad logon attempts, you also can use the Reset Count After field to a time value (in minutes). This field specifies the period of time during which the failed logon attempts are counted. The Lockout Duration fields can be used to permanently lock the account until an administrator intervenes, or to set a time in minutes that the account will be disabled. A good idea is to set a small value for the Lockout After parameter (3 to 5 is a good choice), while using a long lockout value. Thirty minutes to an hour will usually suffice to deter unauthorized users.

At the bottom of this dialog box, you can see two other check boxes. The Forcibly Disconnect Remote Users check box must be checked in order for the user to be disconnected from the server when he stays logged on past the authorized period specified in the Hours button of the user's Account Properties dialog box. If the second check box, User Must Log On in Order to Change Password, is checked, users will not be able to log on after their password expires and change it. The administrator will have to perform this function instead. If this box is not checked, after a user password expires the user still will be allowed to log on but will be required to change the password before performing any other function.

Detecting Failed Logon Attempts

User logon failures occur for many reasons. The most common reason is that users forget passwords or type them incorrectly enough times to trigger the account lockout mechanism. Because Windows NT allows you to create a single username and password logon for each user, the problem of multiple passwords is usually not a problem as it is some other networks.

The Windows NT Event Viewer utility, found in the Administrative Tools section along with the User Manager for Domains, can be used to check for failed logon attempts. This is the first place you should look when a user is having problems logging on to the domain or connecting to a resource on a remote server. The user might not be providing the correct password or might be trying a username for which there is no account. The Event Viewer keeps three log files: Application, System, and Security. It is in the Security log file that you will find messages that relate to logon attempts.

Some of the more common logon attemptrelated messages found in the Event Viewer are listed in Table 36.1.

Table 36.1. Common Logon Errors You Can See Using the Event Viewer

Event ID	Description
528	Successful logon
529	Invalid username or password
530	Violation of logon time restrictions
531	Account disabled
532	Account expired
533	Logon not allowed on this computer
534	Invalid logon type (network or interactive)
535	Expired password
536	Netlogon service not running
537	Unexpected error
538	Successful logout
539	Account currently locked out

As you can see, successful logon and logout events can be tracked. These types of messages can be useful when you are trying to determine who was on the system, perhaps during off hours, when you are trying to troubleshoot security problems. The other messages can be helpful in quickly identifying what the problem is when a user cannot log on to a server or connect to a resource.

The security log file you can examine using the Event Viewer can be configured to track all successful and unsuccessful logon attempts. This includes users who log on locally at the computer, connections made through network access, and logons by special accounts that you set up to run services.

Windows NT does not automatically track events such as these. You must enable the types of events you want to audit before they will be recorded in the security log file. See Chapter 43, "Auditing and Other Monitoring Measures," for information on how to set up the events to audit for Windows NT computers.