7.1 LAN Manager and NTLM

LAN Manager, or LM, is an authentication protocol designed (at its time) to maximize password security in a Windows-based environment. The LM protocol was first used in Microsoft's LAN Manager product a very long time ago and is still the authentication protocol of choice for older operating systems, such as Windows 95 and Windows NT 3.51 and earlier. Later, when Windows NT was introduced, LM was enhanced and renamed the NTLM authentication protocol. Although NTLM has been around for a long time, it's still a basically good authentication protocol, and it is the native network authentication protocol of Windows NT 4.0 and earlier operating systems.

7.1.1 A Brief History of LM and NTLM

LM was introduced, as you might expect, in Microsoft's LAN Manager product of the late 1980s, which evolved over time into Windows NT. It is very similar to NTLM and is supported in most Microsoft products, including Windows for Workgroups 3.11, Windows 95, Windows 98, Windows Me, and all versions of Windows NT through 4.0. LM's long history is reflected in the protocol's priorities. At the time it was invented, most computer networks contained only a single network operating system. The World Wide Web didn't exist, and computer networks from different companies were rarely connected to one another. Computer crime was usually limited to common embezzlement, not the complex intrusion schemes of today. Multitier applications were practically unheard of; most computer networks were used essentially for file and print sharing and the occasional client-server application. Client-server applications usually implemented their own security mechanisms, so the operating system?and LM?wasn't concerned with supporting those applications' security requirements.

LM was designed to combat the security challenges of its day, which primarily involved intruders who stole passwords by eavesdropping on network logon traffic. LM's strength is that it never transmits the user's password across the network, even in an encrypted format.

NTLM is the successor of LM, and it was introduced in 1993 with the release of Windows NT 3.1. In LAN Manager, the hash of each password had to be stored at each LAN Manager server. This presented a security risk as well as a lack of data centralization. NTLM's biggest change to this was its introduction of the concept of a domain controller. These domain controllers kept the password hashes for all users in a domain and were the only servers trusted to keep this information. However, NTLM changed little in the way the authentication mechanism worked.

In Windows NT 4.0 Service Pack 4, Microsoft introduced a new version of this authentication. Called NTLM Version 2 (NTLMv2), it is a great improvement over LM and NTLM. It uses much longer keys for the hash algorithm and takes advantage of passwords longer than 14 characters. These changes, among other cryptographic changes, make NTLMv2 a far more secure authentication protocol than its predecessors.

For the remainder of this book, it is not important to draw the distinction between LM and NTLM authentication, which is mostly in the cryptography used to create the different password hashes. The authentication process itself is similar enough between the two that we can discuss them as one technology. We will call it NTLM.

7.1.2 How NTLM Works

NTLM is based on the concept of a cryptographic hash, which you learned about in Chapter 2. Windows stores user passwords in a special section of the Windows Registry called the Security Accounts Manager, or SAM, or in the Active Directory database in Windows 2000 or later domains. Passwords are never stored in clear text; instead, each password is run though a one-way hash algorithm, and the result is stored in the SAM. This process is illustrated in Figure 7-1.

The main weakness in LM is how it creates its password hash. It really doesn't use a hash algorithm at all; it uses the DES encryption algorithm with some static data. Although this cryptography was considered reasonably secure at the time, it is easily broken today.

Figure 7-1. Storing hashed passwords in the Windows SAM

7.1.2.1 Logging on

When a user attempts to log on to a Windows NT domain, NTLM uses the following process (which is illustrated in Figure 7-2):

Figure 7-2. The NTLM logon process

A user types his password into the logon dialog box on his client computer.
The client computer runs the password through the standard NTLM one-way hash, producing a hashed password that should be identical to the one stored on the domain controller.
The client computer transmits a logon request to the nearest domain controller, including the username that the user provided.
The domain controller sends a logon challenge to the client computer.
The client computer responds to the challenge by encrypting the challenge data with the hash of the password.
The domain controller creates its own response to the challenge with its copy of the hash.
The domain controller compares the responses. If the appropriate pieces match, the logon is successful.

All communications between the client computer and the domain controller are encrypted using a shared secret key. The shared secret is the client computer's own domain password, which both the client computer and the domain controller store in their SAM.

7.1.2.2 Security token

When a user successfully authenticates to the domain, the domain controller sends information to the user's logon process. This process builds a security token on the user's client computer. The security token contains a list of every security identifier (SID) associated with the user. That list includes the SID for the user's own domain user account, as well as the SIDs for any domain user groups that the user's account is a member of. The user's client computer stores this token for future use. The token is also used to start the user logon session's shell, or interactive session. Whenever a process is started through this session, the original security token is associated with that process. In this way, Windows enforces the requirement that all processes run within the security context of some account. That security context is defined by the security token.

7.1.2.3 Accessing resources

When an authenticated user attempts to access resources (such as files) on her client computer, the client computer compares the user's security token to the access control list (ACL) on the resource. If the ACL doesn't contain one of the SIDs in the security token, access is denied. If the ACL does contain one of the SIDs in the security token, the user is granted whatever access is associated with that SID on the ACL. If the token contains multiple SIDs (as they often do) because the user is a member of one or more groups, the cumulative permission from more than one SID may be necessary to obtain the desired level of access. This is automatically done by the security subsystem.

When the user attempts to access resources on other computers, such as file servers, the server she contacts must first contact a domain controller to build its own copy of the user's security token. The server can't trust the security token the user's client computer has, because it's possible (although barely) for the user to falsify that token. The server retains a copy of the user's token in its memory for a period of time, so that subsequent requests for access don't require another request to a domain controller.

The token remains in memory until it is expired or replaced. That means that changes to the user's group membership are not automatically picked up?a new user must get a new token. The most certain way to do that is to log out and log back in.

7.1.3 NTLM Pros and Cons

NTLM has several advantages:

The user's password is never transmitted in its entirety. Only a portion of the hashed password is transmitted, and even that is done over an encrypted communications channel.
The user's password isn't stored in clear text, so even if the SAM is compromised, the user's password cannot be read. Only the hash can be read.
The protocol provides a way for the user's security token to be built and exchanged, enabling authorization as well as authentication.

Unfortunately, as computer networks became more common and more interconnected, NTLM started to show a number of significant flaws:

SAM has several vulnerabilities, which allowed attackers to access the hashed passwords.
NTLM can use a maximum of 14 characters to create its stored hash. These 14 characters are split into two seven-character strings. Cryptographically, it is reasonably easy to brute force attack two seven-character strings with modern computers.
NTLM cannot use lowercase letters. It converts all lowercase letters to uppercase before creating the hash. This reduces the character set for the password, making brute force attacks far more likely to succeed.
The hash algorithm used to store passwords became well known. That allowed attackers to guess users' passwords by running password guesses through the hash until the result matched the result stored in the SAM. Because the algorithm remained constant, large libraries of hashed passwords could be stored and used to quickly attack a SAM.
NTLM used a mechanism known as pass-through authentication to distribute the authentication task. The way pass-through authentication was designed created a bottleneck at the primary domain controller (PDC) of each domain. Some of the tasks done by the PDC, such as password changes, could not be offloaded to any other server.
Attackers began accessing passwords by pretending to be trusted servers. Users' client computers would transmit logon information to the attackers, thinking that they were domain controllers or file servers. NTLM provided no way for users to verify that the server they were connecting to was the one they intended to connect to.
NTLM was largely limited to interoperability with Microsoft products. As computer networks became more heterogeneous, NTLM didn't provide a way to interoperate with non-Microsoft operating systems.
NTLM provided no way for a middle-tier application to access resources on a user's behalf. When a user's client application accessed a middle-tier application, the middle-tier application usually used a generic administrator credential to access backend resources. This technique works, but presents a security threat, because the middle-tier application is running under powerful security credentials.

When Microsoft began developing Windows 2000, they decided a new authentication protocol was necessary. They chose to implement a well-established, standards-based authentication protocol: Kerberos. Of course, NTLM is also included in Windows 2000 and Windows Server 2003, because older Microsoft clients?Windows NT 4.0 and earlier and all Windows 9x versions?don't support the Kerberos protocol.

Microsoft has created an Active Directory client for older Microsoft operating systems. This client provides not only enhanced functionality and Active Directory interoperability, but also NTLMv2 functionality. It does not, however, provide Kerberos compatibility. Only Windows 2000 and higher Microsoft operating systems include support for Kerberos.

7.1.4 Configuring LM

Even though NTLM is inferior to Windows Server 2003's native Kerberos protocol (which I'll discuss next), many Windows clients?including Windows 95, Windows 98, Windows NT, and Windows Millennium Edition?can't use anything but LM or NTLM. Even newer client operating systems?Windows 2000 and higher?still support NTLM. In fact, Windows 2000, Windows XP Professional, and Windows Server 2003 will automatically try and use older authentication methods such as LM and NTLM if Kerberos isn't available or doesn't work. This can present a security weakness.

7.1.4.1 Disabling hash storage

One weakness of LM authentication is that it stores its LM password hashes on domain controllers. While domain controllers are generally pretty secure, storing the hashes at all presents an opportunity for attackers to crack passwords. Because the algorithm used to generate the hashes is well known, attackers with access to the hashes can perform a dictionary attack to try and guess passwords. Basically, this type of attack requires an attacker to run common words, and variations on common words, through the hash algorithm. If the attacker can successfully generate a hash that matches one on the domain controller, the attacker knows the clear-text password that goes along with the hash, rendering your domain vulnerable.

Windows 2000 Service Pack 2 introduced the ability to disable the storage of LM hashes. This can be done both on domain controllers and on member computers or even standalone computers, removing the hashes for local user accounts. You can also disable hash storage for local accounts on Windows XP. Just follow these steps:

Start the registry editor (regedit.exe) on the computer in question.
Find the registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa.
On Windows 2000, if the key NoLMHash does not exist, perform the following steps. From the Edit menu, select New, Key. On Windows XP and Windows Server 2003, select New and then select DWORD Value.
Enter NoLMHash, set the value to 1, and press Enter.
Close the registry editor.
Restart the computer for the change to take effect.

The computer will continue to keep any hashes it already has but will not generate or store new LM hashes for new or changed passwords. If you make this change across your domain controllers, consider forcing your users to change their passwords as soon as possible to remove the hashes from the domain. You must also ensure that all client computers and other authenticating hosts are properly upgraded and configured to support NTLMv2 or Kerberos authentication. Otherwise, authentication requests from these computers will fail.

If you store password history, the LM hashes of those previous passwords are stored in the history. Setting NoLMHash does not clear password history, so those hashes are retained. Only cycling through enough passwords will clear that cache.

7.1.4.2 Disabling NTLM variants

The Windows operating system actually supports several variations of NTLM. I've discussed LAN Manager, or LM, authentication. Next up the ladder is NTLM Version 1, or just NTLM. Since Windows NT 4.0 Service Pack 4, Windows has also supported the newest variant, NTLM Version 2. NTLMv2 is supported natively on Windows 2000 and later operating systems and can be added to Windows 95 and Windows 98 by installing the Microsoft Directory Services Client, first provided on the Windows 2000 CD-ROM.

NTLMv2 is cryptographically much stronger than LM and NTLM. Although still a hash-based process, it uses much stronger cryptography and handles the password differently. It addresses numerous shortcomings of NTLM, including the 14-character password limit and the uppercase conversion of letters, which allowed for a much larger entropy of password characters. NTLMv2 is strongly preferred over NTLM and should be used whenever down-level clients allow it.

Although most applications trust Windows to carry out authentication tasks, some require more direct information and may make authentication APIs themselves. You should test all applications in your environment with the restricted authentication configuration before you deploy it.

Once all client computers in your organization support it, you should configure them to use only NTLMv2, and not other variants of NTLM. Doing so will provide the best security for your environment. After installing the Directory Services Client (available from http://www.microsoft.com/windows2000/server/evaluation/news/bulletins/adextension.asp) on Windows 9x computers, you'll still need to explicitly force the use of NTLMv2:

Start the registry editor (regedit.exe).
Locate and click the following key in the registry: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control.
Create a new registry key named LSA by right-clicking the Control key and selecting New Key. Type LSA, and then press Enter.
On the Edit menu, click Add Value, and then add a registry value named LMCompatibility. The value must be a REG_DWORD, and you should set its value to 3.

The LMCompatibility parameter specifies the mode of authentication and session security to be used for network logons. Although I recommend using 3 to require clients to use NTLMv2 authentication and not allow any weaker method (without potentially breaking other LM or NTLM processes in your environment), you can use any of these values:

0: This allows the computer to send the older LM and NTLM response and to never use NTLMv2 session security. Clients will use LM and NTLM authentication and never use NTLMv2 session security. Domain controllers accept LM, NTLM, and NTLMv2 authentication.
1: Allows the computer to use NTLMv2 session security if negotiated. Clients use LM and NTLM authentication and use NTLMv2 session security if the server supports it. Domain controllers accept LM, NTLM, and NTLMv2 authentication.
2: Allows the computer to send NTLM responses only. Clients use only NTLM authentication and use NTLMv2 session security if the server supports it. Domain controllers accept LM, NTLM, and NTLMv2 authentication.
3: This allows the computer to send NTLMv2 responses only. Clients use NTLMv2 authentication and use NTLMv2 session security if the server supports it. Domain controllers accept LM, NTLM, and NTLMv2 authentication.
4: Causes domain controllers to refuse LM responses. Clients use NTLM authentication and use NTLMv2 session security if the server supports it. Domain controllers refuse LM authentication (that is, they accept NTLM and NTLMv2 only).
5: Causes domain controllers to refuse LM and NTLM responses (accepting only NTLMv2). Clients use NTLMv2 authentication and use NTLMv2 session security if the server supports it. Domain controllers refuse NTLM and LM authentication (they accept only NTLMv2).

Notice that the exact function of this registry value depends on whether or not you're working on a client computer or server or on a domain controller. The value should be applied to all computers regardless of role to force them to use the desired authentication protocol first. For more information about deploying this setting through Group Policy, see Chapter 5.