It should be self evident that a password-protected computer system cannot be considered safe if it's possible to compromise the password database. Windows does not have a spectacular track record in this regard, so it's worth your time to understand how passwords are formatted, stored, and protected. You should also be as familiar as possible with the tools used by bad guys to get access to your system passwords.
This topic also covers two new password-related features in Windows Server 2003:
This feature permits storing alternate credentials for accessing standalone servers or servers that are on an outside domain.
Password Reset Disks.
This feature permits users who have forgotten their local password on a standalone machines to reset the password as part of the logon sequence.
Password Format and Storage
A user's clear-text password is never stored by Windows Server 2003 or any NT-based operating system. The password is converted into a one-way function or OWF, and it is this OWF that is stored, either in the SAM or in Active Directory. Another term for this OWF is a hash because it is obtained by running the user's password through a cryptographic process called a hashing algorithm. The system discards the clear-text password as soon as the hash is calculated.
Windows uses two different methods to hash a user's clear-text password:
DOS-derived Windows (Windows 3.11, Windows 9x, and ME).
These systems use an algorithm based on the Data Encryption Standard (DES). This hash is commonly called the LanMan password because it is used to perform LanMan Challenge-Response authentication.
NT-derived Windows (classic NT, Windows 2000, Windows Server 2003, and Windows XP).
These systems use the MD4 algorithm. MD stands for message digest. See Chapter 18, "Managing a Public Key Infrastructure," for more information. The MD4 password hash is commonly called the NTLM password because it is used to perform NT LanMan Challenge-Response authentication.
Each Windows platform stores the password hash in a different location:
DOS-derived Windows stores the hash in a password (pwl) file in the Windows directory.
Classic NT stores the hash in the SAM database in the Registry. The PDC stores the password hashes for a classic NT domain and replicates the contents to backup domain controllers (BDCs).
Modern Windows stores the hash for local accounts in the local SAM. The hash for domain accounts is stored in Active Directory.
Of the two password hashes, the legacy LM password hash is much more vulnerable. (For a detailed analysis, see www.insecure.org/sploits/l0phtcrack.lanman.problems.shtml. When you read this reference, pay particular attention to the ability of password crackers to derive the LM password hash by sniffing the contents of the LM Challenge-Response transactions. This makes it possible to get passwords without actually accessing the SAM or Active Directory.) Here is a quick rundown of the reasons:
LM passwords are limited to 14 characters.
The passwords are hashed in two, 7-byte units, making it simpler to attack each unit.
The passwords use ASCII characters that must be uppercase. This severely limits the universe of possible characters.
Only a limited number of special characters are permitted in the password.
The algorithm used to create the LM one-way function is relatively rudimentary.
NTLM passwords are much more secure than LM passwords for the following reasons:
The hashing algorithm uses 128-bit MD4, which is significantly stronger than the DES hashing method used on LM passwords.
The passwords length limit is 128 characters, although normal users seldom use passwords longer than 8 to 10 characters.
NT passwords use Unicode characters, not ASCII, which theoretically makes them more secure, although password crackers generally assume that the original password used ASCII characters, at least in Western countries. A single unusual character in a password dramatically decreases its vulnerability.
Active Directory stores passwords as hidden attributes of user and computer objects. These attributes are as follows:
This is the LanMan password. DBCS stands for double-byte character set. The LanMan password history is stored in hashed form in LmPwdHistory.
This is the non-reversible NT password used by Windows 2000, 2002, and XP. The password history is stored in hashed form in NtPwdHistory.
Starting with NT4 SP4, Microsoft improved the session negotiation and authentication transaction processing in NTLM Challenge-Response. The new version, NTLMv2, comes in Windows 2000, 2002, XP, and the Dsclient update available for Windows 9x/ME. By default, Windows Server 2003 negotiates down to older authentication methods unless local or group policy has been set to block this action.
Password Storage Vulnerabilities
Password-cracking programs work most efficiently when they have a copy of the password list from the SAM or Active Directory that they can pound away at.
There are password dump programs that can steal password hashes for later processing. The most popular of these dump utilities is PWDUMP3E. Using PWDUMP3E, an intruder with administrative privileges can save the password hashes to a file, transport the file to another machine, then use a password cracker such as l0phtcrack to break the passwords.
I highly recommend that you obtain a copy of PWDUMP3E and l0phtcrack to check the vulnerability of the passwords on your system. You'll probably be astonished at how fast and easy it is to find most of the passwords on your system.
You can take steps to improve your users' passwords by setting a variety of group policies. This section contains the most commonly implemented password policies.
Eliminate Weak LanMan Passwords
You can set a policy that prevents storing LanMan passwords in Active Directory. This significantly cripples password-cracking programs such as l0phtcrack. It is theoretically possible to find a collision with an NTLM hash, but the process is much more complex than with LM password hashes.
Even though the algorithms used to hash LM and NTLM passwords cannot be reversed, it's possible to "guess" a password by looking for a known word with a hash that matches the password hash.
The algorithms that produce the LM and NTLM passwords are well known. It's possible to build a list of pre-hashed passwords to speed up a dictionary attack. If the original password is not a common word, the cracking program tries one combination of characters and numbers after another until it finds one that works.
The most notorious password-cracking program is l0phtcrack, although there are others. You can get details about l0phtcrack at www.insecure.org/sploits/l0phtcrack.lanman.problems.shtml. The most current version is LC3, available for purchase (a crippled time trial is available for download) from www.atstake.com.
You can find a tidy list of other popular password-cracking and system-scanning tools at www.insecure.org/tools.shtml.
The group policy that controls this setting is Network security: Do not store Lan Manager level hash values on next password change. The policy entry is set in the Default Domain Controllers policy. The item is located at Computer Configuration | Windows Settings | Security Settings | Local Policies | Security Options.
The legacy password will not be removed from Active Directory until the client changes the current password. With the default settings, this could take as many as 42 days. You can shorten the interval using the Maximum Password Age policy. This policy entry is set in the Default Domain policy. It is located at Computer Configuration | Windows Settings | Security Settings | Account Policies | Password Policy.
Finally, you should eliminate all legacy authentication mechanisms except for NTLMv2. This ensures that the non-Kerberos authentication transactions use the most secure password handling. The group policy that controls this setting is Network Security: Lan Manager Authentication Level. The policy entry is set in the Default Domain Controllers policy. The item is located at Computer Configuration | Windows Settings | Security Settings | Local Policies | Security Options.
Before setting these policies, you must enable your downlevel clients to use NTLMv2 authentication. For Windows 9x and ME clients, distribute the DSCLIENT patch from the Windows Server 2003 CD. For NT4 clients, make sure you are running SP4 or later.
You must also set an Lmcompatibility Registry entry at the Windows 9x and ME clients. This Registry entry prevents the clients from sending LanMan password requests.
Account Lockout Policies
You don't want to give a bad guy the opportunity to bang away at a logon window trying all sorts of possible passwords until one just happens to work. An account lockout policy discourages this behavior by disabling the user account after a given number of invalid logon attempts.
Account lockouts cost money because they result in Help Desk calls. You can minimize the impact by setting an interval after which the lockout clears automatically. The group policies that affect account lockout settings are located in Computer Configuration | Windows Settings | Security Settings | Account Policies | Account Lockout Policy. There are three parameters to set:
The number of invalid logon attempts permitted before the account is locked out.
All of the policies discussed in these topics can also be set locally for a standalone server. This is important to remember if you are responsible for servers in a DMZ or some other situation that makes it difficult or impossible to create a domain.
Lockout reset time.
The interval between invalid attempts after which the lockout count is returned to zero. For example, a lockout reset time of 10 minutes would cause the lockout counter to continue incrementing for invalid logon attempts made every nine minutes.
The interval following a lockout after which the lockout is automatically cleared and the user can try to log on again.
The Local Security Authority imposes the lockout policy on any service that accepts network connections. This includes CIFS/SMB, FTP, telnet, and HTTP. Repeated invalid logon attempts using any combination of these services will also trip the lockout.
The lockout policy has very few exceptions. The Administrator account cannot be locked out, but this exception does not apply to accounts with administrative privileges. Computer accounts cannot be locked out. Neither can domain trust accounts.
MD5-CHAP and Digest authentication require that the verifying server know the client's clear-text password. The same is true when authenticating Macintosh clients using the Random Number Exchange UAM in the AppleTalk File Protocol (AFP) or remote access via AppleTalk Remote Access Protocol (ARAP).
Neither the NTLMv2 password nor the legacy LanMan password can be used for these transactions because the system stores one-way functions that cannot be used to derive the original password. Active Directory can accommodate authentication mechanisms requiring clear-text passwords by storing a reversibly-encrypted password. When an MD5-CHAP or Digest client attempts access, the system decrypts the password and uses the result to verify the user's identity.
The group policy that controls this setting is Store Password Using Reversible Encryption For All Users In The Domain. The policy entry is set in the Default Domain policy. It is located at Computer Configuration | Windows Settings | Security Settings | Account Policies | Password Policy.
Now that we've seen some of the vulnerabilities of passwords and how to help overcome them (or at least limit our exposure), let's look at other places that Windows uses passwords.
Clients running older Samba versions may not work with Windows without reversible password support. Newer Samba clients use NTLMv2 and can act as domain controllers in a Mixed domain.
Computers that are members of a domain have a password associated with their computer account. Active Directory stores the hash for this password in the computer's object, just as it does for user passwords. In addition to authentication and authorization, the computer password hash is used to encrypt data sent between the member computer and a domain controller. This is called a secure RPC connection. The data stream in the secure connection is encrypted using RC4 (a streaming encryption algorithm licensed from RSA Security) with the computer's password hash acting as the encryption key.
Diagnosing Computer Password Problems
Problems with the secure channel between a member computer and its domain controller can cause errors such as Unable to contact domain controller... when a user attempts to log on to the domain. If you think you are having problems with a computer's network authentication, test the secure channel with NLTEST as follows (the example uses a domain called company.com):
DNS problems can also cause logon failures because the client cannot locate a domain controller to use as a logon server. If you get connection failures in NLTEST, you should look at network connectivity and name resolution.
The computer password used to set up the secure channel is changed every 30 days by default. Both the member computer and its logon server must be on the network for this transaction to occur. If a member computer (such as a laptop) is off the network at the time the password change is due, the client will change its password the next time it contacts the domain.
You can force a password change using NLTEST as follows:
If a member server has lost its secure channel connection and cannot regain it, you can disjoin and rejoin the computer to the domain. The simplest and fastest way to do this is to log on at the member server using the local Administrator account then running the NETDOM utility from the Resource Kit as follows:
netdom remove server13 /domain:company.com
Then run the following:
netdom join server13 /domain:company.com
Restart the machine to let it complete the secure channel connection to the domain.
In modern Windows, a single domain password gives access to member servers throughout a forest thanks to transitive Kerberos trusts. Accessing servers outside the forest, such as standalone servers in a DMZ or servers in other domains, requires a separate authentication transaction with a separate password.
When you connect to a server outside your forest, you are prompted to enter a name and password for the target machine. When doing cross-domain authentications, you may need to specify a domain name in the format:
If you make this a persistent connection, the system reestablishes the session at the next logon and prompts once again for credentials.
Microsoft makes password management a little easier in Windows Server 2003 by including a new credentials database. This database is exposed via a Control Panel applet called Stored User Names and Passwords. You can store your username and password in the credentials cache and use them to automatically authenticate when reconnecting to the target server.
The credentials cache is stored in a file called Credentials in your profile under Application Data\Microsoft\Credentials\<user_sid>. The file is encrypted with your private key, which is itself encrypted with the Master crypto key. See Chapter 18, "Managing a Public Key Infrastructure," for more information about the PKI components of Windows Server 2003.
Names and passwords in the credentials cache are available at the command line for the NET USE command. For instance, let's say you create a drive mapping from the command line as follows: net use * \\server13\shared_folder. If you have an entry in the Credentials cache for Server13, the system will make the connection without the need to specify a username or password.
When using NET USE to make a connection, you can automatically save alternate credentials in the credentials cache via the /savecred switch. You'll be prompted for your username and password, which are then stored in the credentials cache if the logon is successful.
If you prefer to do all your credentials management from the command line, take a look at the new CMDKEY utility. This utility creates, displays, and deletes credentials in the credentials cache. For example, to add a new username and password to the cache, use cmdkey /add:<server_name> /user:<user_name> /pass:<password>. To see the contents of the credential cache, use cmdkey /list. Here is a sample listing:
Currently stored credentials:
Type: Domain Password
Windows Server 2003 only stores CIFS/SMB credentials in the credentials cache. Upcoming versions will store Internet Explorer credentials, as well. This will enable the system to store usernames and passwords for web sites.
Storing Names and Passwords
To store a set of credentials, proceed as directed in Procedure 11.2.
Procedure 11.2 Storing User Names and Passwords
Open the Stored User Names and Passwords applet in Control Panel.
Click Add. The Logon Information Properties window opens. Figure 11.8 shows and example.
Figure 11.8. Logon Information Properties window of Stored User Names and Passwords applet.
Enter the fully qualified domain name of the server. The flat name would work, but you want to get accustomed to entries that don't rely on WINS.
Enter the username in the form <domain>\<name>. If you are connecting to a standalone machine, enter the flat name of the machine instead of the domain, as in SERVER1\jjones. (The name is not case-sensitive.)
Enter the password.
Click OK to save the change. The name of the server appears in the pick list.
It is unfortunate that Microsoft chose to use the phrase Credentials cache for the new Stored User Names and Passwords feature because they already use a similar phrase in another context referring to logons when a domain controller is not available. In that context, the cached credentials are stored in a Secrets key in the Security hive in the Registry (often called LSA Secrets).
The ability to reset a password for another user is a highly privileged operation, as you might well imagine. If you can change a user's password, you can log on as that user and get access to the user's files and processes. The user's password also protects the Public Key Infrastructure (PKI) keys stored for the user, which protect the user's encrypted files, encrypted email, and secure web access, along with any other application that relies on the system's PKI providers.
Utilities are readily available that make changing a user's local password a trivial exercise. For example, the for-fee version of ERD Commander 2002 (www.winternals.com) makes it possible to boot a machine using the four Setup disks then change the password of any user in the local SAM database, including the Administrator account. (You cannot use this utility to change the passwords for Active Directory accounts.) Using a tool like ERD Commander, you can change a user's local password then log on as that user and get access to the user's data.
Password Reset Handling for Local Accounts
Windows 2000 had a significant shortcoming regarding password resets. When you reset a user's local password in Windows 2000, the system rebuilds the master crypto key using the new password. This means that you can use ERD Commander to change a user's password then log on locally and open any files that were encrypted with the user's local account. (This deficiency does not apply to files encrypted while the user is logged on to the domain.)
Windows Server 2003 and XP correct this deficiency by leaving the master crypto key in its original state unless the user changes the password using the Change Password option from the Windows Security window. If you reset a user's local password using any other mechanism, you will not get access to the user's encrypted files or any other PKI-protected information. You'll be warned about this if you use the password reset feature in the Users and Computers applet in Control Panel.
If you reset a user's local password and, later on, the user discovers that the reset caused a loss of access to encrypted files or email, the user can change the password back using Ctrl+Alt+Del | Change Password. This regains access to encrypted files and email. You may need to relax local password history requirements to permit the user to reuse a password.
Password Reset Disk
One of the most common support calls is the "forgotten password" call. In a domain, this problem can be quickly corrected by resetting the user's domain password. If you support standalone desktops or servers, though, a forgotten password becomes a nasty problem. If you cannot get physical access to the machine, you must walk the user through a local logon using the Administrator account. This compromises the password. (For some reason, users who cannot remember their own password for longer than five minutes will remember the local Administrator password for years.)
A new feature in Windows Server 2003 and XP called the Password Reset Disk, or PRD, helps alleviate this problem. The PRD is a floppy created by the user that contains a special key created by the system for the user. If the user forgets his local password, he can use the PRD to authorize a local password reset. Procedure 11.3 demonstrates how it works.
Procedure 11.3 Creating a Password Reset Disk
Log on using a local account. (The PRD does not apply to domain accounts because those passwords can be reset using AD Users and Computers or some other enterprise tool.)
Press Ctrl+Alt+Del and select Change Password.
Click Backup. The Forgotten Password Wizard opens.
Click Next. The Create Password Reset Disk window opens. Insert a blank, formatted floppy in Drive A.
Click Next. The Current User Account Password window opens. Enter your current password.
Click Next. The wizard writes the certificate information to the floppy.
Click Finish. The wizard closes. The floppy now contains a file with a PWS extension. This file contains a hash of the user's identification.
When a user forgets the local password, use the steps in Procedure 11.4 to reset the password using the PRD.
Procedure 11.4 Using a PRD to Change a Password
Press Ctrl+Alt+Del to log on.
Enter the correct username but an incorrect password. The system responds with an error asking if you want to reset your password.
Click Reset. This opens the Password Reset Wizard.
Click Next. The Insert Password Reset Disk window opens. Insert the floppy containing the PWS file into Drive A.
Click Next. The Reset the User Account Password window opens. Enter a new password and confirm it. This must be a different password than the one that currently exists in the SAM.
Enter a password hint. Hints are saved in clear text for each user under HKLM | Software | Microsoft | Windows | Hints. The hint should not indicate the password in any way. "My wife's name" is not a good hint because that information is easily obtained. "Third rock from the sun" has the same problem unless it's a hint for a password of "johnlithgow". The hint "e raised to pi*i" would be acceptably inscrutable except the answer, "-1", is too short for a good password.
Click Next. The password change is applied.
Click Finish. The Password Reset Wizard closes and you are returned to the logon window. Enter the new credentials and log on.
Password Reset Disk Contents
As you can see from the preceding section, if a user's PRD falls into a third party's hands, that third party can use the PRD to get access to the local system. Here are a few highlights about the file on the PRD:
The PWS file contains a digital signature that identifies the user who created the file. It does not contain the user's password or any derivative of the password. It also does not use the user's PKI information to create the signature, so it is not tied to the user's profile.
The signature contains information specific to the user's instance on a particular machine, so you cannot use the PRD to reset a user's password on another machine. Also, the information in the PSW file is not tied to the user's profile. You can delete the user's profile and the user can still use the Password Reset Disk to get logged on.
You cannot use the PRD to change a password to the existing password, regardless of the local password history security setting. The password reset transaction must actually change the password. The new password must meet any complexity requirements in the local security settings.
If you reset your password using the PRD, you will not lose access to encrypted files or any other component protected by the PKI subsystem. This includes encrypted email and access to protected web sites.
After you've logged on with the new password, you can change your password back to the original (if you remember it) using Ctrl+Alt+Del | Change Password.
If an administrator changes the user's local password, the user can still use the PRD to reset the password again.
If you reset your password using the PRD, you will lose all entries in the credentials cache created by the Stored User Names and Passwords applet in Control Panel.
If an administrator deletes a local user account and then makes another account with the same name, the PRD will not work for the new account.
A user with accounts on several machines cannot use a PRD from one machine to reset a password on another.
You can copy the PWS file to another floppy and use that floppy as the PRD.
The same PSW file can be reused any number of times within the limitations listed in the preceding. The system keeps track of each use of the PRD by making entries in a history file (CREDHIST) in the user profile under Application Data | Microsoft | Protect.
When a process owned by a user accesses a resource on a remote Windows server, the underlying network application (CIFS/SMB or Winsock, for example) handles authentication transparently to the user.
If the process is owned by the Local System account or some other account with no network security context, it cannot authenticate on the remote server. Instead, it attempts a null session connection with the remote server.
Only a few server processes in Windows are designed to accept null session connections. For example, when a client scans for shares on a server using Network Neighborhood, the network file system makes a null session connection to the server to obtain the share list.
Every process needs an access token, so when the local server builds an access token for a null session connection, it attaches the well-known SID of the Anonymous Logon account. For this reason, the terms anonymous logon and null session are more or less synonymous in Windows.
In classic NT and Windows 2000, the Anonymous Logon account was automatically made a member of the Everyone group. This permitted a thread running in a null session context to access quite a bit of information about a server. This spawned a set of utilities designed to scan for NetBIOS services and other resources that accept null session connections. An example is the LanGuard network scanner, a free download from www.languard.com/languard/lanscan.htm. Figure 11.9 shows an example of the kind of information collected by LanGuard when run against a classic NT4 BDC. Windows Server 2003 reveals much less information because of the additional restrictions put on null sessions.
Figure 11.9. NetBIOS service and port scan results using LanGuard.
In Windows Server 2003, the Anonymous Logon account is not a member of the Everyone group. This helps restrict what a NetBIOS scanner can detect. It's still possible to get a lot of information, though, simply by doing a raw port scan.
If null session scanners are a concern for you, you should enable group policies to block anonymous enumeration of shares and account names. These policies are located in Computer Configuration | Windows Settings | Security Settings | Local Policies | Security Policies. Here are the policy names:
Do not allow enumeration of SAM accounts (Enable)
Do not allow enumeration of SAM accounts and shares (Enable)
Let Everyone permissions apply to anonymous users (Disable)
You may have a share that absolutely must be accessed anonymously, such as a printer share. If so, you can add the share to the Network Access: Shares that can be accessed anonymously group policy.