Change passwords regularly. Enforcing hard-to-guess passwords is only one way to protect passwords. You can also require users to change their passwords regularly to make passwords a moving target. This security measure is important because over time, passwords can be guessed, shared, and written down. In addition, employees who have access to a shared account might change jobs or leave the company. I recommend that you have users change their passwords about every 90 days so that the window of opportunity doesn't stay open indefinitely.
When you set the Maximum Password Age option in the Account Policy dialog box, NT checks each password's age every time users log on. As the specified expiration date approaches, NT starts prompting users to change their passwords. By default, NT displays a password-expiration notification 14 days before a password's expiration and every time users log on thereafter until they change their passwords. (You can control how far in advance NT starts prompting for a password change with a registry tweak, which I discuss later.) However, even if you specify a maximum password age, some users might specify the same password as their new one, defeating your policy. You can deter this problem by enabling the Password Uniqueness option in the Account Policy dialog box. If you set this policy, NT remembers users' previous passwords and prevents them from using those passwords again. I recommend setting this option to its maximum of remembering 24 passwords. You might encounter some determined users who loop through 24 immediate password changes to cause NT to forget their favorite passwords and thus be able to keep them again. To deter this behavior, you can set the Minimum Password Age option so that users can't change their passwords for the specified number of days. For example, if you set the Password Uniqueness option to Remember 24 Passwords and the Minimum Password Age option to Allow Changes In 2 Days, it would take users 48 days to get back to their favorite passwords.
Beware that imposing these restrictions usually isn't a popular move and will cause some uncooperative users to start writing down their passwords. So I stress that you implement written policies and password training sessions.
If you want to change password restrictions in a domain that already contains many users, you need to know about an important caveat: NT looks at maximum password age and minimum password length only when you change your password. Therefore, these two policies aren't retroactive on the passwords that existing users in the domain are using. For example, suppose you currently have 100 users and you change the maximum password age from Password Never Expires to Expires In 90 Days and wait a year. No one's password will expire during that year, except for those users who voluntarily changed their passwords or had an administrator reset them. After you set the Maximum Password Age and Minimum Password Length policies or use the Passprop and Passfilt utilities, users must change their passwords for these policies and utilities to take effect. In the "User-Specific Policies" section, I show you how to force password changes in one simple step.
Set account-lockout policies. The third way to protect passwords during the logon process is to set the Account lockout option in the Account Policy dialog box. NT locks out a user account after it detects, within 24 hours, three consecutive failed logon attempts because of a bad password. The word consecutive is key because if an intruder tries two password attempts and then the real owner of the account logs on successfully, NT resets the failed logon count and starts over. You can specify that the account remain locked until an Administrators or Account Operators group member unlocks the account manually. Another option is to have NT unlock the account automatically after so many minutes.
Notice the two check boxes at the bottom of Figure 1. The Forcibly disconnect remote users from server when logon hours expire check box affects how NT treats users who remain logged on past their time-of-day restrictions, which I explain shortly. This check box is disabled in Figure 1 because User Manager for Domains is accessing a member server's SAM instead of the domain SAM. Workstations' and member servers' SAMs don't support hour restrictions, so in this case, the check box isn't applicable.
The Users must log on in order to change password check box is a strange description for a logon policy that controls how NT handles expired passwords. By default, this check box is clear, which means that when a user logs on with an expired password, NT requires the user to change the password, then lets the logon proceed. Depending on how securely you view expired passwords, you might view this default as a risk because users can still gain access to a system long after a password expires. If you select the Users must log on in order to change password check box, NT doesn't let users log on after their passwords expire. Users must have an administrator or account operator reset their passwords. However, don't immediately conclude that you should select this check box. Selecting this check box might conflict with a popular user-specific logon policy: the User Must Change Password at Next Logon check box in the user account's properties. Suppose you select the Users must log on in order to change password check box in the Account Policy dialog box. Later, a user requests that you reset his password because he has forgotten it. When you change his password, you select the User Must Change Password at Next Logon check box in the user's account properties so that he can select a new password that you don't know. However, when the user tries to log on to change his password, NT will deny access, claiming that the password is expired. Thus, you can't set both options.
Keep in mind that the password restrictions and lockout policies in Figure 1 are global, which means that all the users in your domain are subject to the same policies. You can't, for example, require stronger passwords for just your administrators without creating a new domain. To handle such situations, you can apply user-specific policies.
User-Specific Policies
User-specific policies override global policies for a given user account. Each user account has several options that affect the user's ability to log on. Administrators or account operators can edit these options by double-clicking a user in User Manager for Domains. Figure 2 shows the New User dialog box that appears.
In the New User dialog box, you can change a user's password by entering the new password in the Password and Confirm Password fields. You can specify that the user must change his or her password at the next logon by selecting the User Must Change Password at Next Logon check box. As I described previously, administrators typically set this policy when they reset passwords in response to users forgetting their passwords. Supposedly, this practice ensures that administrators don't have continuing access to the user accounts. However, anyone with Administrator authority can use LC4 to crack users' passwords. Therefore, rather than selecting the User Must Change Password at Next Logon check box, you must trust administrators and try to limit how many people have this level of authority.
Register
