Changes to NTLM authentication for HTTPWebRequest in Version 3.5 SP1
Security changes were made in Version 3.5 SP1 that affect how integrated Windows authentication is handled by the HttpWebRequest, HttpListener, NegotiateStream, and related classes in the System.Net namespace. These changes can affect applications that use these classes to make web requests and receive responses where integrated Windows authentication based on NTLM is used. This change can impact web servers and client applications that are configured to use integrated Windows authentication.
Overview
The design of integrated Windows authentication allows for some credential challenge responses to be universal, meaning they can be re-used or forwarded. If this particular design feature is not needed then the challenge responses should be constructed at a minimum with target specific information and preferably also with some channel specific information. Services can then provide extended protection to ensure that credential challenge responses contain service specific information such as a Service Principal Name (SPN). With this information in the credential exchanges, services are able to better protect against malicious use of credential challenge responses that might have been improperly obtained.
Multiple components in the System.Net and System.Net.Security namespaces perform integrated Windows authentication on behalf of a calling application. This section describes changes to System.Net components to add extended protection in their use of integrated Windows authentication.
Changes
The NTLM authentication process used with integrated Windows authentication includes a challenge issued by the destination computer and sent back to the client computer. When a computer receives a challenge it generated itself, the authentication will fail unless the connection is a loop back connection (IPv4 address 127.0.0.1, for example).
When accessing a service running on an internal Web server, it is common to access the service using a URL similar to http://contoso/service or https://contoso/service. The name "contoso" is often not the computer name of the computer on which the service is deployed. Naming support using Active Directory, DNS, NetBIOS, the local computer's hosts file (typically WINDOWS\system32\drivers\etc\hosts, for example), or the local computer's lmhosts file (typically WINDOWS\system32\drivers\etc\lmhosts, for example) are configured to send requests to "contoso" to the appropriate server computer.
When configured for large deployments, it is also common for a single virtual server name to be given to the deployment with the underlying machine names never used by client applications and end users. For example, you might call the server www.contoso.com, but on an internal network simply use "contoso". This name is called the Host header in the client web request. As specified by the HTTP protocol, the Host request-header field specifies the Internet host and port number of the resource being requested. This information is obtained from the original URI given by the user or referring resource (generally an HTTP URL).
The AuthenticationManager class controls the managed authentication components ("modules") that are used by WebRequest derivative classes and the WebClient class. The AuthenticationManager class provides a property that exposes a AuthenticationManager.CustomTargetNameDictionary object, indexed by URI string, for applications to supply a custom SPN string to be used during authentication.
Version 3.5 SP1 now defaults to specifying the host name used in the request URL in the SPN in the NTLM (NT LAN Manager) authentication exchange when the CustomTargetNameDictionary property is not set. The host name used in the request URL may be different from the from the Host header specified in the System.Net.HttpRequestHeader in the client request. The host name used in the request URL may be different from the actual host name of the server, the machine name of the server, the computer's IP address, or the loopback address. In these cases, Windows will fail the authentication request. To address the issue, we need to notify Windows that the host name used in the request URL in the client request ("contoso", for example) is actually an alternate name for the local computer.
There are several possible methods for a server application to work around this change. The recommended approach is to map the host name used in the request URL to the BackConnectionHostNames key in the registry on the server. The BackConnectionHostNames registry key is normally used to map a host name to a loopback address. The steps are listed below.
To specify the host names that are mapped to the loopback address and can connect to Web sites on a local computer, follow these steps:
1. Click Start, click Run, type regedit, and then click OK.
2. In Registry Editor, locate and then click the following registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0
3. Right-click MSV1_0, point to New, and then click Multi-String Value.
4. Type BackConnectionHostNames, and then press ENTER.
5. Right-click BackConnectionHostNames, and then click Modify.
6. In the Value data box, type the host name or the host names for the sites (the host name used in the request URL) that are on the local computer, and then click OK.
7. Quit Registry Editor, and then restart the IISAdmin service and run IISReset.
A less secure work around is to disable the loop back check, as described in https://support.microsoft.com/kb/896861. This disables the protection against reflection attacks. So it is better to constrain the set of alternate names to only those you expect the machine to actually use.
See Also
Concepts
Integrated Windows Authentication with Extended Protection