5

I've developed a couple of internal sites for my organization that use integrated authentication. Ultimately we want these sites to be accessible externally to users with domain-joined computers. The sites work as expected on domain computers while on the internal network. The problem comes when I take my laptop home and try to access those sites.

IIS only has integrated authentication enabled for the two sites. When I browse to the site using IE8 I get a username/password prompt asking for domain credentials. I can put those in and it will work, but the goal is to use the cached token for integrated authentication.

Next I reasoned that IE wouldn't response to an integrated auth request (is NTLM the right term for this?) unless the site was trusted. I tried adding the site to Trusted Sites but I get the same behavior as the before. I then added the site to Local Intranet sites and that is where things get weird. I get a generic error page from IE, no error code or anything.

Just for funsies I loaded up Firefox (which I had previously set up to use integrated authentication) and I added this new site to network.automatic-ntlm-auth.trusted-uris. Much to my surprise I was able to load the pages up with no problem at all and saw exactly what I was expecting (including verification that the integrated authentication worked).

My mind is a bit boggled at the moment as I'm not really sure where to go from here. I was hoping some of you may be able to provide some insight.

Update 05/11/10 I got to messing with Fiddler as recommended below and saw some discrepancies between how Firefox and IE handle the page request. When I tested Internet Explorer it makes one request, hits a 401.2 (server configuration error) and dies. There are no security log entries when this happens. Firefox encounters this same error initially, but subsequently sends another request and authentication is successful.

Keeping in mind the initial testing was all from outside the network, I looked at a successful auth by IE8 when done inside and it appears to behave the same way as Firefox both internally and externally. The initial request is met with 401.2, then another one is sent and is met with 401.1 (the challenge?) followed by a 200 (success).

So the problem seems to be that when accessing the "intranet" site from outside the network, IE8 experiences a 401.2 and then dies when it should (by measure of other browsers) keep going with the authentication process.

Can someone verify the Fiddler activity that I described?

maik
  • 818
  • 2
  • 9
  • 21

2 Answers2

7

It looks, to me, like you're falling victim to a "bug" in IE8, as was reported to Microsoft here and discussed in more detail here.

I suspect that if you use the AdsUtil.vbs script to set the authentication on the affected directory to "NTLM" instead of the default "Negotiate,NTLM" and the problem will probably go away.

You can verify if you're seeing this behaviour by monitoring the client machine with Wireshark (or your favorite sniffer) and watching to see if it attempts to perform a NetBIOS broadcast name resolution for a domain controller while attempting to access the site.

Some background on the NTAuthenticationProviders value I'm taking about is available from Microsoft KB215383. For IIS6, if the value isn't defined then IIS treats it as "Negotiate,NTLM". My guess is that you're running in the default setting.

You can examine this value using the adsutil.vbs script (which is installed, by default, in %SystemDrive%\Inetpub\AdminScripts). Use the following command to examine the value for the first web site on the machine (obviously, change the path in this example to suit your real application):

cscript adsutil.vbs GET W3SVC/1/Root/NTAuthenticationProviders

Remember-- if the value isn't defined then IIS6 will be using its compiled-in default setting of "Negotiate,NTLM".

To change the NTAuthenticationProviders value for the root directory of the first web site on the machine, use the following command:

cscript adsutil.vbs SET W3SVC/1/Root/NTAuthenticationProviders "NTLM"

Microsoft recommends verifying the value "took" by querying it again after you've set it.

Mark Henderson
  • 68,316
  • 31
  • 175
  • 255
Evan Anderson
  • 141,071
  • 19
  • 191
  • 328
  • @Farseeker: Good call catching my bungled link. I do that more frequently than I'd like to admit. – Evan Anderson May 14 '10 at 00:33
  • That is simply amazing. You guys freaking rock. The explanation was well laid out and the linked articles described exactly what I was experiencing. I will add that the sites I was having problems with were two virtual directories under an IIS site. Out of curiosity (after I found the web site ID) I added the name of the virtual directory to the path (so W3SVC/#/Root/NTAuthenticationProviders becomes W3SVC/#/Root/VirtDir/NTAuthenticationProviders) and that worked exactly as expected. Thank you so much, Evan! – maik May 14 '10 at 04:13
1

Do you have access to the security log of the IIS server? If so, that will help you figure out why Integrated Authentication is failing with IE8. If you don't have access to the logs, you can get a client-side view of the traffic by using WebFiddler, which would let you compare the HTTP authentication traffic between IE8 and FireFox.

Eric H
  • 748
  • 4
  • 10
  • I looked into the security logs on the web server and there are no audit failures, or actually any entries made when IE8 fails from outside. Logs are made normally when authentication works in Firefox. I've updated the original post with info about testing done with Fiddler. – maik May 11 '10 at 20:16