Export (0) Print
Expand All
This topic has not yet been rated - Rate this topic

Supported scenarios for restricting NTLM in a domain

Published: November 29, 2012

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.

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.

    noteNote
    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.

    noteNote
    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.

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:

  1. Deny NTLM from users in the domain to servers in the domain

  2. Deny NTLM from users in the domain to servers in other domains

  3. 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.

Network Security: Restrict NTLM: Incoming NTLM Traffic

Yes

NTLM denied

NTLM allowed

NTLM denied

Allow NTLM authentication to my servers from any domain.

Network Security: Restrict NTLM: Incoming NTLM Traffic

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

See Also

Did you find this helpful?
(1500 characters remaining)
Thank you for your feedback

Community Additions

ADD
Show:
© 2014 Microsoft. All rights reserved.