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?
Best Answer
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.vbsscript 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.vbsscript (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):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:
Microsoft recommends verifying the value "took" by querying it again after you've set it.