Supported scenarios for restricting NTLM in a domain
Updated: November 9, 2012
Applies To: Windows 7, Windows 8, Windows Server 2008 R2, Windows Server 2012
This reference topic describes the possible scenarios for setting the security policies to restrict NTLM authentication in a domain.
NTLM is a proprietary Microsoft authentication protocol that was developed for compatibility with the Windows NT operating system, primarily for SMB authentication. The Negotiate Security Support Provider (Spnego SSP) can select NTLM as a supported authentication protocol based on various conditions, and applications and services can explicitly specify NTLM usage (usually to reduce authentication compatibility issues). However, Kerberos is the preferred protocol selection during the negotiate process because it provides mutual authentication between client and server.
Because NTLM does not provide server (or mutual) authentication, it is an inferior authentication protocol. Beginning with Windows Server 2008 R2 and Windows 7, the Windows operating system includes Group Policies and security policies to help you assess and reduce NTLM usage.
In this topic
Potential issues with legacy and current NTLM usage
NTLM-reduced usage scenarios beginning with <token xmlns="https://ddue.schemas.microsoft.com/authoring/2003/5">nextref_server_7</token> and <token xmlns="https://ddue.schemas.microsoft.com/authoring/2003/5">nextref_client_7</token>
Potential issues with legacy and current NTLM usage
The following list describes some common issues in your environment when you have mixed Windows operating system deployments and applications that use NTLM.
NTLM authentication is used in your applications
It is possible that some of the applications deployed in your environment have NTLM hardcoded as the authentication protocol. There are several ways to understand this usage, either by using the NTLM plug-in to the Application Verifier tool or by using the audit security policies for restricting NTLM.
SAMBA compatible devices and applications
Communication and file sharing between Windows and UNIX or Linux is managed through a protocol suite known as the Common Internet File System, or CIFS. CIFS implements the Server Message Block (SMB) protocol and Samba is an open source CIFS implementation. Applications can be changed to use another authentication protocol such as Kerberos, but existing hardware devices often cannot be changed.
Applications do not provide a valid pszTarget name
The Negotiate SSP requires a valid pszTargetName to be able to use Kerberos if available and to enable security enhancements to the NTLM protocol. NTLM relies on the client application to forward the authentication request appropriately but Kerberos requires the SPN. Using an FQDN SPN permits better access in cross forest trust scenarios. UPNs can also be used for the pszTargetName in User-to-User communication. Failure to pass a target name prevents mutual authentication.
Applications passing NetBIOS names in cross forest environments
NTLM relies on the application to find the target server, so the challenge-response authentication works. However, because the client cannot decode the NetBIOS name, Kerberos cannot use it to determine the intended server target. The Key Distribution Center (KDC) provides only information from the global catalog in a particular domain per forest, not across forest trusts.
Application authentication in environments with external trusts
For environments with external trusts, NTLM works because it relies on the application to find the target server. Mutual authentication is difficult to achieve in this topology because the client cannot ascertain a trusted relationship to the server.
Access based on an IP address
When an application or user accesses resources through an IP address, mutual authentication cannot be performed and therefore NTLM is used. Registering IP addresses is generally impractical in environments using DHCP, and beginning withWindows Vista, the operating system examines the format of the requested SPN and if it is only an IP address, NTLM is explicitly used.
Registering SPNs
In versions of the Windows operating system before Windows Server 2012 and Windows 8, NTLM does not require registering SPNs, but Kerberos does. This means that you need to consider the effort to register (or change) the SPNs for services when reducing NTLM usage in your environment.
Note
Extended Protection for Authentication, which is Microsoft’s solution to increase the protection and handling of credentials when authenticating network connections by using NTLMv2, requires SPNs to be registered. For more information, see Extended Protection for Authentication.
Anonymous support
NTLM supports anonymous authentication but the Kerberos protocol does not. This means that you need to consider the effort to change the authentication scheme from anonymous authentication when reducing NTLM usage in your environment.
DCOM and Netlogon
In special cases, the Negotiate SSP allows the server to select NTLM even when a Kerberos ticket was obtained. This occurs when a remote user performed a network logon without specifying DELEGATE, which launched the DCOM servers to impersonate that remote user.
Remote access by using NTLM
NTLM works for the remote corporate access while the Kerberos protocol does not because the client computer outside the corporate firewall cannot obtain a Kerberos ticket.
Note
If there are other alternatives for remote access that are more secure than using NTLM, then those technologies should be pursued. In Windows Server 2012, a new service, the Key Distribution Center service, is available for this purpose. For more information, see What's New in Kerberos Authentication.
NTLM-reduced usage scenarios beginning with Windows Server 2008 R2 and Windows 7
The security and Group Policies introduced in Windows Server 2008 R2 and Windows 7 can help you assess NTLM usage in your environment and, in some cases, help you reduce the number and frequency of NTLM authentication requests. But the policies are designed only to help you understand and control the traffic. You might have modify applications, replace network devices, install audit tools and event collection systems, and upgrade operating systems, depending upon your project goals. To understand the project elements you might have to address, see Evaluating your environment for NTLM reduction.
There are three NTLM blocking scenarios within a targeted domain:
Deny NTLM from users in the domain to servers in the domain
Deny NTLM from users in the domain to servers in other domains
Deny NTLM from users from other domains to servers in the domain
The following table shows the authentication usage for each combination, whether supported or not.
| Scenarios and corresponding security policies | Supported? | My users to my servers | My users to other servers | Other users to my servers |
|---|---|---|---|---|
Allow all NTLM traffic. No configuration. |
Yes |
NTLM allowed |
NTLM allowed |
NTLM allowed |
Allow my users to use NTLM, but not other users. |
No |
NTLM allowed |
NTLM allowed |
NTLM denied |
Allow NTLM authentication only in my domain. |
No |
NTLM allowed |
NTLM denied |
NTLM denied |
Deny NTLM authentication in my domain. Network Security: Restrict NTLM: NTLM authentication in this domain |
Yes |
NTLM denied |
NTLM allowed |
NTLM allowed |
Deny NTLM authentication to my servers from any domain. |
Yes |
NTLM denied |
NTLM allowed |
NTLM denied |
Allow NTLM authentication to my servers from any domain. |
Yes |
NTLM allowed |
NTLM denied |
NTLM allowed |
Deny my users to use NTLM authentication. Network Security: Restrict NTLM: NTLM authentication in this domain |
Yes |
NTLM denied |
NTLM denied |
NTLM allowed |
Deny all NTLM traffic. Network Security: Restrict NTLM: NTLM authentication in this domain |
Yes |
NTLM denied |
NTLM denied |
NTLM denied |