Changes to NTLM authentication for HTTPWebRequest in Version 3.5 SP1

Switch View :
ScriptFree
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 http://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

Reference

Community Content

pritishjacob
Alternate workaround incase the above doesn't work for you (MOSS 2007)
Got here from having the symptoms described in http://sharepoint.microsoft.com/blogs/LKuhn/Lists/Posts/Post.aspx?ID=82 but the workaround presented here and http://support.microsoft.com/kb/896861 didn't work (but maybe has to do with running MOSS on a win2008 x64 server).

This problem reared its head happened after applying these updates to the MOSS WFE; kb952004 kb956572 kb959426 kb960803 *kb963027* .

Also, simultaneous with these symptoms, we got an HTTP 403.14 when browsing to the root (e.g. http://dev-intranet/)

Resolved by:
1. detaching content database of the affected site (central admin > application mgmt > content databases, Remove Content Database)
2. create new web application (central admin > application mgmt > create or extend web app > create new web app) with mostly defaults except database authentication & search server
3. created a new site collection in this new web application * observe the ability to get to this new site (central admin > application mgmt > create site collection)
4. detach the database of the new site (central admin > application mgmt > content databases, Remove Content Database)
5. stsadm -o addcontentdb -url http://NewSiteURL -databasename DetachedOriginalContentDB (apparently the attach aspx times out with large databases or is otherwise flaky)
6. go to the crawl log (shared services admin > search settings, view crawl log) * observe crawler sailing through new application's content database
7. edit bindings in IIS manager of the old non-functional Site, change the port to something unused and random, and remove the hostname (i.e. if its mapped to a DNS entry this is the host header info)
8. edit bindings in IIS manager of the newly created functional Site, change the hostname, port, IP address to the desired final state/match the DNS entry (e.g. hostname=dev-intranet, port=80)
9. edit alternate access mappings (central admin > operations > alternate access mappings, edit public URLs for the Collection that was just created in step 2; if your crawl is in progress, move the Default URL to the Intranet URL space. Enter the IIS binding name/host header (step 8) into the Default URL

Sébastien Nunes
Restart the IISAdmin service and run IISReset are not enough
Restarting the IISAdmin service and running IISReset are not enough, many users through the web says the had to reboot the server, which additional services should be restarted to avoid rebooting all the server ?