Reduce the Risk
To protect against password sniffing, upgrade NT to Win2K, load the AD client on Win9x systems, and migrate your Win2K domains from mixed mode to native mode. These actions will reduce the occurrence of NTLM authentication on your network.
For situations in which you can't eliminate NTLM, such as connections between Win2K and NT systems, consider adjusting the LMCompatibility Level settings on the systems involved. LMCompatibilityLevel is a Registry setting that NT 4.0 SP4 introduced that also exists in Win2K. In Win2K and NT, you can find the setting under the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA Registry key. Selecting an LMCompatibilityLevel value of at least 1 can prevent the weak LAN Manager response from transmitting during connections. Eliminating the LAN Manager response makes L0phtCrack crack the NT response, which takes much longer than cracking the LAN Manager response. LMCompatibilityLevel also lets you require NTLMv2 for all network connections, which completely defeats L0phtCrack 2.5. (For information about LMCompatibilityLevel, see "Inside SP4 NTLMv2 Security Enhancements," September 1999.)
In Win2K, you can use Group Policy to control the LMCompatibilityLevel setting. Under \Computer Configuration\Windows Settings\Security Settings\LocalPolicies\Security Options, you'll find a policy called LAN Manager Authentication Level. Figure 2 shows the valid settings for this policy. When you define a value for this policy in a Group Policy Object (GPO), Win2K sets the corresponding value for LMCompatibilityLevel in the Registry of each system to which that GPO applies. If you want to specify a standard LMCompatibilityLevel for all computers in your domain, open the Microsoft Management Console (MMC) Active Directory Users and Computers snap-in, open the properties for the domain root, and click the Group Policy tab. Open the Default Domain Policy GPO and maneuver to the LAN Manager Authentication Level policy dialog box that Figure 2 shows. Set the LAN Manager Authentication Level to at least Send LM & NTLM - use NTLMv2 session security if negotiated.
Account Policies
Password and account lockout controls are similar in Win2K and NT. Win2K, like NT, has control options for minimum password length, maximum and minimum password ages, password uniqueness, and account lockout thresholds. However, in Win2K, you configure password and account lockout controls differently than in NT. To configure password and account lockout policy for your Win2K domain accounts, you need to open the Default Domain Policy GPO.
To reach the Default Domain Policy GPO, open the MMC Active Directory Users and Computers snap-in, right-click the domain, and select Properties. Select the Group Policy tab and edit the Default Domain Policy. Then, navigate to the Password Policy and Account Lockout Policy folders under \Computer Configuration\Windows Settings\Security Settings\Account Policies, which Figure 3 shows. Win2K users are subject to control only by the password and account lockout policies whose definitions reside in GPOs that link to the root of the domain control. AD, not the domain controller's local SAM, manages Win2K domain users. AD looks only at the group policies at the domain root. This setup might disappoint you if you planned to use group policies linked to lower organizational units (OUs) in AD to set password requirements for different departments in your company. For example, you might have planned to require five-character passwords for users in marketing and seven-character passwords for users in IT administration. But because AD looks at group policy only at the domain level, all users in the domain must adhere to the same password and account lockout policy.
When you specify values for your domain's password policy, don't configure them independently. You need to combine the values to achieve an aggregate protection level for your passwords. The procedure for setting your domain's password policy involves three steps: requiring users to choose high-quality passwords that are difficult to guess, requiring users to change passwords on a regular basis, and slowing attackers who use repeated logon attempts to guess passwords. Setting values for each of the three steps gives you flexibility if people in your organization resist one of the protection methods. For example, users might resist making regular password changes. In that case, you can weaken the controls for that step and strengthen controls for other steps.
Step 1. In \Computer Configuration\Windows Settings\Security Settings\Account Policies\Password Policy, select a value for the Minimum password length setting to require users to select quality, difficult-to-guess passwords. A more effective alternative is to select the Passwords must meet complexity requirements option, which requires that passwords contain characters from at least three of the following cate-gories: A-Z, a-z, 0-9, and nonalphanumeric characters (e.g., !, $, #, %). In addition, you can use notification packages, which are custom DLLs, to implement advanced password requirements that go beyond minimum password length and complexity requirements. You can specify notification packages by adding the DLL's name to the NotificationPackages value under the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA Registry key in Win2K and NT. (For more information about notification packages, see the Microsoft article "HOWTO: Password Change Filtering & Notification in Windows NT" at http://support.microsoft.com/support/kb/articles/q151/0/82.asp.)
Step 2. You can use the Maximum password age option to require password changes on a regular basis, making passwords moving targets. To prevent users from using the same password when the system requires them to change it, use the Enforce password history option, which enables Win2K to remember users' previous passwords. You can set the number of previous passwords that Win2K remembers so users can't reuse them. I recommend setting the number of passwords at 24, which is the maximum. However, users who are determined to use their favorite password can loop through 24 password changes to make Win2K forget their original password and trick the system into accepting the original password. To prevent this tactic, you can set the Minimum password age option to 1 or 2 days, which prevents users from executing a series of immediate password changes.
Step 3. To slow attackers, use the account lockout options in \Computer Configuration\Windows Settings\SecuritySettings\Account Lockout Policy, which Figure 4, page 109, shows. The combination of values that Figure 4 shows for Account lockout duration and Account lockout threshold tells Win2K that if it detects within any 24-hour period five consecutive failed logon attempts that involve an incorrect password, the OS should lock out the account. The Account lockout duration option's value is 0, so the account stays locked out until the legitimate user asks an administrator to unlock the account. If you want Win2K to automatically unlock the account after a certain time, specify a time period for the Account lockout duration policy.
Win2K offers a new account policy, Store password using reversible encryption for all users in the domain. This policy causes Win2K to store user passwords in clear text in AD, where anyone can find and read them. Microsoft's Group Policy Reference states, "The intent of this policy is to provide support for applications which use protocols that require knowledge of the user password for authentication purposes." An example is support for the AppleTalk protocol. Unless you need support for Macintosh computers that use AppleTalk, don't enable Store password using reversible encryption for all users in the domain. When you open a user account object in the MMC Active Directory Users and Computers snap-in, you'll notice the Store password using reversible encryption option under the Account tab. This option has the same effect as the Store password using reversible encryption for all users in the domain policy. However, when you select the option on a user account, you'll affect only one user instead of the entire domain.
Use Caution
Passwords benefit from better protection in Win2K, but they're still vulnerable. Make sure you avoid situations in which Win2K uses the old NTLM authentication protocol. Implement strong password-quality and password-change policies and strict lockout policies for your user accounts. You need to set policies in GPOs that link to the domain root. Don't forget to use L0phtCrack and pwdump2 to regularly crack your domain's passwords and assess password quality. Follow up your efforts with feedback to users who select poor passwords, and provide training to help users pick quality passwords. If you follow these guidelines, your system will have passwords that intruders can't easily crack, sniff, or guess.
Register
