Authentication in Windows Server 2008 R2 and Windows 7

As a Windows administrator, you've certainly come across the two main Windows authentication protocols: Kerberos and NTLM. In this article, I'll give you an update on how Kerberos and NTLM are supported in Windows 7 and Windows Server 2008 R2. Before that, however, I want to make sure you understand the main differences between the two protocols.

Kerberos and NTLM in Short

Microsoft introduced Kerberos support in Windows 2000. NTLM has been around much longer, since the Windows NT days. Kerberos is a trusted third party (TTP)-based authentication protocol and NTLM is a challenge/response-based authentication protocol. See Table 1 for more differences between the two protocols.

During an NTLM authentication exchange, the resource server (such as a file server) generates an NTLM challenge that's forwarded to the client. The client creates an NTLM response with the user’s password hash, and the server validates that response. If the client uses a local account, the server validates the user's response with the user password hash that's stored in the local Security Account Manager (SAM) database. If the client uses a domain account, the server forwards the response to a domain controller (DC) for validation, because only DCs have a copy of the user password hash in their Active Directory (AD) databases.

In the Windows Kerberos implementation, the TTP is a Windows 2000 or later DC that hosts a Kerberos Key Distribution Center (KDC) service. The KDC facilitates the authentication between a Kerberos-enabled client and a server. The KDC service is automatically installed as part of the AD installation and is made up of two subservices: the Authentication Service (AS) and the Ticket-Granting Service (TGS).

When a user logs on to a Windows domain using Kerberos, the Windows client will first authenticate the user against a DC using the user password. At the same time, the client will request a Ticket Grant Ticket (TGT) to the AS. The TGT can be looked at as a temporary password (the default TGT lifetime is 8 hours) that will replace the user’s password in subsequent authentication requests. When the user wants to access a resource server, the client presents the TGT to the TGS to obtain a session ticket for authenticating to the resource server. Note that as opposed to NTLM, Kerberos isn't used for local authentication against a Windows SAM, but only for domain-based authentication against a DC.

Kerberos is the default authentication protocol in Windows 2000 and later Microsoft OSs. Windows uses a negotiation mechanism to determine which authentication protocol will be used. If the Kerberos default fails or isn't supported by one of the client or server components involved in an authentication, Windows will fall back to NTLM.

Why Kerberos is the best option

There are several reasons why Kerberos is a better authentication protocol than NTLM. This is certainly true for the first version of NTLM, NTLM version 1 (NTLMv1). Microsoft released a more secure version of NTLM in Windows NT 4.0 SP4—NTLM version 2 (NTLMv2) that tackles some of NTLMv1's security issues. However, Kerberos is still a more secure choice.

When using Kerberos, a user’s password hash is exposed much less frequently than when using NTLM. The password hash is only exposed when the user requests a TGT—basically, once every eight hours. The password hash in NTLM is exposed each time the client uses NTLM for authenticating to a server. This is an important security advantage of Kerberos over NTLM. Tools exist (e.g., L0phtcrack) that scan network traffic for NTLMv1 password hashes, capture them and then do a brute-force crack on them to derive the user's password.

Another Kerberos advantage is that it uses timestamps to protect against replay attacks. That's why it's crucial to have a time synchronization service that works well in a Kerberos-centric Windows environment. (Windows 2000 and later provide time services out of the box.) Computer clocks that are out of sync between systems can generate additional Kerberos authentication traffic or, in the worst case, can cause Kerberos authentication to fail. Microsoft learned from Kerberos and introduced timestamp support in NTLMv2.

Kerberos also supports advanced authentication features like mutual authentication and authentication delegation. Mutual authentication means that the user and service authenticate with one another, while NTLM only provides user authentication. Without this feature, users might provide their credentials to a bogus server.

A service can access remote resources on behalf of a user with authentication delegation. In other words, a user can give rights to an intermediary machine to authenticate to an application server on the user’s behalf. The result is that an application server can make authorization decisions based on the user identity rather than on the identity of the intermediary machine. Authentication delegation is very handy in multi-tier applications, such as database access using a web-based front end.

Although Microsoft provides important cryptographic changes in NTLMv2, Kerberos uses more state-of-the-art encryption algorithms. I expand on that topic in greater detail in the section on Kerberos crypto.

NTLM Restrictions

Kerberos is clearly the better authentication protocol. But even in a Server 2008 AD environment Windows still often uses NTLM. For example, Windows uses NTLM when you connect to a pre-Windows 2000 system, or when you connect to a share using net use and an IP address (instead of a NetBIOS name). Also, applications that don't have properly configured service principal names (SPNs) will keep on using NTLM.

To find out whether you're are using NTLM or Kerberos, you can use netmon or another network tracer to visualize the NTLM traffic, or you can check the content of your Kerberos ticket cache using the klist tool (which is bundled with Windows 7 and Server 2008). In Windows 7 and Server 2008, Microsoft offers new group policies that you can use to track and also block the use of NTLM by your users and applications. There are three of these policies: one for incoming NTLM traffic (for server-level tracking and lockdown), one for outgoing NTLM traffic (for client-level tracking and lockdown), and another one for domain traffic (for DC-level tracking and lockdown). You can find them in the Computer Configuration, Windows Settings, Security Settings, Local Policies, Security Options Group Policy Object (CPO) container. They all start with Network security: Restrict NTLM:

Each policy setting has audit and block options. When you enable NTLM auditing, it will create event log entries with the source NTLM and with numbers 8001, 8002, 8003, and 8004. The log entries are stored in the Event Viewer (Local), Applications And Services Logs, Microsoft, Windows, NTLM, Operational container. I advise you to deploy NTLM auditing in a test environment first and ensure that the test environment is representative for all your applications. If you just start blocking arbitrarily, you'll likely have applications that stop working. To make sure that no events are lost, you must have an audit event collection solution in place before you test NTLM auditing—you can use the built-in Windows Event Collector service and Event Subscriptions or a third party tool. I also recommend you start monitoring NTLM on your servers first. You can use your clients for detailed analysis after the server NTLM use becomes apparent. After you've clearly identified what applications are using NTLM, you can define an NTLM blocking strategy. This strategy could include an exception strategy for older applications that can't be rewritten or reconfigured and that will always require NTLM.

Unfortunately, you can't use these NTLM restriction settings on older Windows systems. But you can still control the NTLM protocol versions on those systems. You can disable the LM portion of the NTLM authentication protocol (which is inherently weak), or enforce the use of the NTLMv2 protocol. To do so, use the Network Security: LAN Manager Authentication Level GPO setting, which is located in the Computer ConfigurationWindows SettingsSecurity SettingsLocal PoliciesSecurity Options GPO container.

Kerberos Crypto

The cryptographic protocols that authentication protocols use significantly impact the quality of their security. As I mentioned, Kerberos scores better in this space than NTLM. The RC4 encryption algorithm has been supported by Windows Kerberos since the Windows 2000 release and is still supported (more pricisely, RC4_HMAC_MD5 is supported) in Server 2008 and Windows 7. Microsoft added support for the Advanced Encryption Standard (AES) encryption type in Server 2008, Windows Vista, and later OSs, and Windows 7 and Server 2008 R2 machines support AES (AES128_HMAC_SHA1 and AES256_HMAC_SHA1) Kerberos encryption types out of the box. AES is a newer and stronger encryption algorithm than DES. The Kerberos logic on domain controllers will switch to the AES encryption type when you change your AD domain to the Windows 2008 Domain Functional Level (DFL).

DES encryption types for the Kerberos authentication protocol are disabled by default In Windows 7 and Server 2008 R2. This fact may cause compatibility issues if one of your legacy applications is hardcoded for only DES encryption or if the Windows account that runs a service (the service account) is configured to use only DES encryption. These services or applications will fail unless you can reconfigure the service or application to support another encryption type (RC4 or AES), or you re-enable DES support.

To check whether one of your applications or services are hard-coded to use only DES encryption, you can run a network trace when the application or service starts and check the content of the Etype fields in the Kerberos authentication headers. To determine whether an AD user or computer account or the computer account is configured for only DES encryption, you must check whether the Use Kerberos DES encryption types for this account option is set on the Account tab in the object properties. (You can access these properties from the AD Users and Computers MMC snap-in.)

If you make the checks above and find that you're affected by this problem, you can enable the DES encryption type for Kerberos authentication on computers running Windows 7 or Server 2008 R2 using the GPO setting Network security: Configure encryption types allowed for Kerberos, which is located in the Computer Configuration, Windows Settings, Security Settings, Local Policies, Security Options GPO container.

Of the two Windows authentication protocols, Kerberos is the better one. You should always try to force your users and applications to use Kerberos instead of NTLM. The new NTLM restrictions in Windows 7 and Server 2008 R2 offer a good tool to help you achieve this.