Jan. 25, 2011, 8:58 a.m.
posted by vdv
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:
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:
Each Windows platform stores the password hash in a different location:
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.html. 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:
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
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.
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.
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 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.
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:
C:\>cmdkey /list Currently stored credentials: Target: laptop Type: Domain Password User: laptop\administrator
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.
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.
When a user forgets the local password, use the steps in Procedure 11.4 to reset the password using the PRD.
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:
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 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.
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: