Ask the Directory Services Team : Negotiate security support provider behavior

 

Negotiate security support provider behavior

Greetings DS blog readers,

Todd here. I wanted to talk a little about the Negotiate security support provider (SSP) and how there are times when it will intentionally use NTLM rather than Kerberos. [And if that’s not interesting, keep reading anyway because there is a slick trick in here for network captures - Editor]

In a properly configured and functioning domain when SSP Negotiate is utilized and the client application resides on the target server to be accessed, SSP Negotiate will choose NTLM instead of Kerberos. Microsoft Negotiate acts as an application layer between Security Support Provider Interface (SSPI) and the other SSPs. When an application calls into SSPI to log on to a network, it can specify an SSP to process the request. If the application specifies Negotiate, Negotiate analyzes the request and picks the best SSP to handle the request based on customer-configured security policy.
Currently, the Negotiate security package selects between Kerberos and NTLM. Negotiate selects Kerberos unless it cannot be used by one of the systems involved in the authentication, the calling application did not provide sufficient information to use Kerberos, or the client and server are the same machine. For efficiency and security reasons NTLM is chosen over Kerberos when the client and the server are the same machine. This behavior is by design.

How to reproduce the behavior

Note: The test computer must be part of a domain and on a routed network for the reproduction to work.
1. On your test computer create a share.
2. Install a network capture utility. (Netmon, Wireshark, etc...)
3. Add a network route to the test machine to allow network traffic to be seen with the source and destination are the same location.
Run the following command on the machine where you need to see the to and from traffic on itself:
route add <IP Address of the server that you are on> <IP Address of default gateway of the server you are on>

This causes the server to send internal packets over the network that would ordinarily stay completely local and not be viewable in a network trace. The packets will just return to the test computer itself.

PLEASE NOTE: To remove the “route add” issue the command “route add <IP Address of the server that you are on>”

Note that each packet going from the server to itself will appear twice ... once exiting the server on its way to the router, once returning from the router on its way back to the server. You can ‘post-process’ the capture to eliminate the duplicate packets (i.e. don't display the packets where the source Ethernet address matches the router).

In Netmon 3.x you can use a Display Filter constructed similar to:

HTTP and Ethernet.SourceAddress == 0x010203040506

For Wireshark you can use the following display filter:

(tcp.port == 80) && (eth.src == 01:02:03:04:05:06)

You will need to replace the 0x0102030405 or the 01:02:03:04:05:06 with the MAC address of your web server.

4. Start the network capture.
5. Access the share on the test computer from the test computer (i.e. from itself, to itself).
6. Stop the network capture.
7. Review network trace.

You should see the following sequence in the trace:

i. A GET request
ii. A HTTP 401 Unauthorized response with:

WWW-Authenticate:Negotiate

…in the HTTP header
iii. A second GET request with NTLM authentication

Here is the workaround

In order to allow a client application to utilize Kerberos in this usage scenario; the following steps can be enacted.
1. Create an alias (CNAME) host record for the machine with a unique name for the forest. This can be accomplished using the DNS snap-in, expanding out he forward lookup zone for the domain which contains the web server, right clicking on the domain name and select New Alias (CNAME)…

2. Register SPNs for the alias on the computer object. You can use Setspn to register an SPN which would be formatted similar to “Setspn –A HTTP/<alias_ you _registered_in_DNS> <webservername>”

3. When accessing the machine with a browser use the alias. This will allow Kerberos to be utilized even if the client resides on the server.
References
http://msdn.microsoft.com/en-us/library/aa378748(VS.85).aspx

I hope this has been enlightening.

Best regards,

Todd Maxey

Posted: Wednesday, January 21, 2009 4:34 PM by NedPyle

Ask the Directory Services Team : Negotiate security support provider behavior