1
votes

I have an intranet site hosted IIS 7 with windows authentication, configured to accept Negotiate. I also set the configuration setting to use per-connection Kerberos (non-NTLM) authentication:

 <system.webServer>
   <security>
     <authentication>
       <windowsAuthentication authPersistNonNTLM="true" />
     </authentication>
   </security>
 </system.webServer>

Now Chrome correctly authenticates once with a Kerberos ticket, and then does not send any authorization headers on subsequent requests.

Internet Explorer however DOES send a large Kerberos ticket with EVERY REQUEST. The server is sending back the correct Persist-Auth: true header. So IE should know not to bother pre-authenticating. This behavior can be observed in at least IE9 and IE10 on Windows 7 64bit.

Is there some other reason for this behavior? A way to fix it?

Also please note that I am using Kernel mode on IIS7 and no virtual directory security.

If I have IE9/IE10 connect with NTLM it does NOT pre-authenticate (which is correct behavior).

I'm hoping there is some magical header I can manually add to my server responses so IE will behave correctly ...

2

2 Answers

2
votes

You didn't mention what kind of URL you are using for the intranet site - did you use the hostname or a DNS alias? Was it a short (netbios) name or fully qualified? Do you notice the same behavior when using these different types of URLs? Did you check if those extra headers in fiddler were really Kerberos, or if SPNEGO was falling back to NTLM?

Fiddler really behaves as a proxy server; it can intercept your traffic only because it registers with WinInet as a proxy. CNAMEs and proxies interact in a complicated manner with Kerberos, which can make it hard to see what is really going on. With a CNAME, IE will actually create a Kerberos ticket request for the hostname instead. Adding a proxy in the mix will further change this behavior. If this is the issue you are experiencing, it is specific to Microsoft products, which is why you found modern browsers work correctly.

You did the right thing by doing a wire trace, because troubleshooting Kerberos with a proxy is not a good idea.

2
votes

Alright it looks like Fiddler was the problem. Perhaps fiddler combined with something strange about our intranet? I don't know the whole story here...

But when Fiddler is capturing traffic, every IE request had the Kerberos ticket as described. With Fiddler not running, IE behaved is Chrome, and only sent the ticket once per connection to the web server.

I discovered this by running a netsh trace both with Fiddler running and with it not running.

Perhaps when checking your Kerberos authentication it is best not to use Fiddler. If anyone knows more about this I would appreciate the education.