People often compare the many levels of Windows NT security to layers of an onion. One of the outermost layers of the onion is the many checks that NT performs before letting users log on. You can protect your network from many risks if you don't let unauthorized users log on. You can secure NT's logon policies in three areas:
- Global policies in the SAM database. These policies affect all users in a computer's or domain's SAM.
- User-specific policies in user accounts. You can specify different policies for different users.
- Values in the registry. You can affect a user's logon process by tweaking the registry.
Global Policies
Global policies let you enforce password policies and lock out accounts when NT detects someone trying to guess a password. These policies are called global because they affect all the user accounts in the SAM to which you're connected through User Manager for Domains. Depending on the SAM you're editing, you might be defining policies for all the users in your domain or just the local accounts on one computer. Each NT workstation and member server has a local SAM in which you can define local user accounts that are valid on that computer only. (For more information about the differences between local and domain SAMs, see "Related Articles in Previous Issues.")
To set global account controls, open User Manager for Domains and select Policy, Account on the menu bar. Figure 1, page 64, shows the Account Policy dialog box that appears. At the top of the dialog box, notice the word Computer, which specifies that you're working with the specified computer's local SAM. If the dialog box says Domain, you're working with a domain SAM.
By setting the Password Restrictions options in the Account Policy dialog box, you can impose password-management best practices on your users. Understanding and setting password restrictions is important because users are typically pretty careless with passwords. You can protect passwords three ways: require that users create hard-to-guess passwords, make users change their passwords regularly, and set account-lockout policies.
Create hard-to-guess passwords. By setting the Minimum Password Length option, you can require that users create hard-to-guess passwords. For most environments, I recommend that you set the minimum length to 7. Because of an arcane vulnerability in how NT hashes passwords, I don't recommend more than 7 unless you go all the way up to 14. If you can train users to use a random sequence of 7 letters, numbers, and symbols, you'll have passwords that are quite strong. However, imposing a minimum password length doesn't guarantee hard-to-guess passwords because users can just repeat the same letter or number seven times. If you really want to require passwords that are hard to guess, you need to use a password filter, such as the Passfilt or Passprop utility in the Microsoft Windows NT Server 4.0 Resource Kit. Both utilities require users to create passwords that include a combination of letters, numbers, symbols, and case.
Just requiring users to create hard-to-guess passwords isn't enough. You also need to back up this requirement with written policies that demonstrate management's support for the requirement, training sessions that teach users how to select and remember strong passwords, and a monthly or quarterly audit of passwords with a utility such as @stake's L0phtCrack 4.0 (LC4). You might even consider using an acceptable use policy to help remove the temptation to write down passwords. Acceptable use policies document the company's expectations about the proper use of its computers. Such policies also provide legal recourse (e.g., termination of employment, recovery of related loss) in the event someone breaches the policy.
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.
You can select the User Cannot Change Password check box for accounts over which you want to retain control, such as shared accounts or the user accounts for users who refuse to select hard-to-guess passwords. You can select the Password Never Expires check box for user accounts that you don't want to be subject to the domain-level maximum password age. You can also use this option for server-application service accounts (e.g., Microsoft SQL Server) to prevent the common situation in which you reboot a server one day and none of the important services start because their account passwords have expired. Unfortunately, I've also seen administrators set the Password Never Expires option to make an exception for uncooperative users who have enough clout to refuse to change their passwords regularly.
The Account Disabled check box is a useful control for temporarily protecting user accounts of employees who are on vacation or another type of leave. When you disable an account, NT won't let the user log on, regardless of whether the user knows the correct password. You can disable an account when an employee leaves the company instead of immediately deleting the account. Keeping the account around for about 30 days lets you reconstruct what the user had access to if a replacement is hired or if suspicion arises as to the employee's actions before leaving. Disabling the account also saves you from having to recreate the account if the employee changes his or her mind and comes back a week later.
You can limit which days of the week and which hours each day a user can log on. Given the unpredictable schedule of most users today, setting this policy isn't too practical. However, if you have users who work definite hours (e.g., a bank teller), you can click Hours to obtain the Logon Hours dialog box. In it, you simply select a time period, then click Allow or Disallow. If users try to log on outside the allowed times, NT rejects the attempt. If users log on during the allowed time period and remain logged on into a period in which they're explicitly disallowed, NT lets the users remain logged on by default. You can use a global policy to change this default. In the Account Policy dialog box, select the Forcibly disconnect remote users from server when logon hours expire check box. Be aware that selecting this check box disconnects users from servers but not their workstations. For example, suppose you limit Bob to logging on between 8:00 a.m. and 6:00 p.m. and you select the Forcibly disconnect remote users from server when logon hours expire check box. At 9:00 a.m., Bob logs on to his workstation and connects to several servers for file and printer sharing. Bob remains logged on past 6:00 p.m. At 6:00 p.m., the file and printer sharing servers disconnect him, but he still remains logged on to his workstation. Note, however, that servers disconnect only inactive users when their logon hours expire. If users are interacting with the servers (e.g., keeping a file open, querying a directory every few minutes), the servers won't disconnect the users regardless of their logon hours.
By default, NT lets users log on from any workstation. If you want to limit the computers to which users can log on, you can apply workstation restrictions. Click Logon To in the New User dialog box to bring up the Logon Workstations dialog box, which Figure 3 shows. You can specify up to eight workstations. If users need to log on to more than eight computers, see "NT Gatekeeper: Restrict Workstation Logons," http://www.secadministrator .com, June 2001, InstantDoc ID 20902.
The last user-specific logon policy you can set is the user account's expiration date. By default, user accounts don't expire. However, you can set an expiration date by clicking Account in the New User dialog box and specifying the date in the Account Information dialog box, which Figure 4 shows. Account expiration is useful for temporary contractors or when you know in advance of a user's departure. You just set the expiration date in advance, and NT takes care of the account for you. I've seen some administrators use this option when they have a chronic problem with not being notified when employees leave the company. These administrators set an expiration date of 30 days for each user and require the human resources (HR) department to provide a monthly report that lists all current employees. Based on these reports, the administrators extend the expiration dates of the valid user accounts. That way, if someone leaves but the administrator doesn't get notified, NT automatically closes the account after 30 days.
User Manager for Domains lets you modify user-specific logon policies for many user accounts in one step. Simply press the Ctrl key while clicking each user account you want to change. Then select User, Properties and make the change. This capability comes in handy when you need to select the User Must Change Password at Next Logon check box to make new domain password restrictions take effect.
When viewing a member server's or workstation's local SAM, you won't find all the user-specific policies I just discussed. The Logon To, Hours, and Account Disabled options aren't present. These controls are available only on domain accounts.
Registry Tweaks
In addition to setting global and user-specific policies, you can make registry changes under the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon subkey to control the logon process. Specifically, you can tweak the registry to display a legal notice during logon, hide usernames in the logon dialog box, and shorten or extend the password-expiration period.
For legal purposes, displaying a legal notice when users log on is important. This notice tells users that they're entering your system and establishes your right to monitor their actions. For best legal recourse, you should display this warning before they enter their credentials. You create this legal notice by adding two REG_SZ registry values under the Winlogon subkey. In the LegalNoticeCaption entry, add a short string that NT will display in the warning window's title. In the LegalNoticeText entry, add the full text, which you should obtain from your legal department. After you specify these values, NT will display the legal notice whenever the user presses Ctrl+Alt+Del at logon. NT waits for the user to click OK in the warning window before letting the person enter his or her username and password.
During logon, NT automatically fills in the Username field in the logon dialog box with the name of the last user who logged on. If this default is a risk in your environment, you can blank out this field by setting the DontDisplayLastUserName entry to the REG_SZ value of 1.
As I mentioned previously, NT starts displaying a password-expiration notification 14 days before a password's expiration date. If you want to shorten or extend how far in advance NT starts warning users, you can change the PasswordExpiryWarning entry's REG_DWORD value from 14 to the number of days you prefer.
You must make the registry tweaks I just described on each user's computer. If you have numerous machines, you can use the System Policy Editor (SPE) for this task. SPE lets you distribute registry changes to every computer in your domain from a central database. You can also use SPE to implement workstation restrictions that guard the workstation after the user has logged on. For example, you can deploy a password-protected screen saver on user desktops and prevent users from disabling it. For a wealth of how-to information and tips about SPE, go to http://www.winnetmag.com/topics and select System Policies or System Policies Editor (SPE).
Stand Guard
You can protect your network from many risks if you don't let unauthorized users log on in the first place. By understanding and using NT's global, user-specific, and registry-level policies, you can effectively guard entry into your domain.
| Related Articles in Previous Issues |
|
This article is the fifth in Randy Franklin Smith's "NT Security Fundamentals" series, which is adapted from "Audit and Security of Windows NT Server," a course that the author developed for the MIS Training Institute. You can obtain the previous articles in the series from Windows & .NET Magazine's Web site at http://www.winnetmag.com. "Controlling User Rights and Built-in Groups," March 2002, InstantDoc ID 23837 "A Model Network," October 2001, InstantDoc ID 22249 "PDCs, BDCs, and Trust Relationships," September 2001, InstantDoc ID 21844 "NT Security Fundamentals," August 2001, InstantDoc ID 21510 |
