I know that there are thousands of reports of people having trouble getting Integrated Windows Authentication to work with IIS, but they all seem to lead to web pages that don't apply or solutions that I've already tried. I've deployed dozens of sites like this before, so either there's something bizarre going on with the server/configuration, or I've been looking at this too long and not seeing the obvious.
Simply put, everything works perfectly on my local machine, but falls apart on the production server, which as far as I can tell has the exact same configuration.
On the local machine:
On the remote machine:
Last but not least, I tried turning on FREB for 401.2 errors and the results don't seem to tell me anything useful, all I see is the following warning:
MODULE_SET_RESPONSE_ERROR_STATUS
ModuleName IIS Web Core
Notification 2
HttpStatus 401
HttpReason Unauthorized
HttpSubStatus 2
ErrorCode 2147942405
ConfigExceptionInfo
Notification AUTHENTICATE_REQUEST
ErrorCode Access is denied. (0x80070005)
...this seems to just be telling me what I already know (that it's simply rejecting the request instead of negotiating the credentials).
The trace does indicate that the WindowsAuthentication module is correctly loaded because there is a NOTIFY_MODULE_START
line with ModuleName
= WindowsAuthentication
(and various other ASP.NET follow-up events - [un]fortunately, no interesting errors or warnings here).
Can anyone tell me what I might be missing here?
Quick Update:
I'm a little uncomfortable sending a whole Wireshark dump as it would reveal IPs, URLs and other stuff, but I did a side-by-side comparison of the HTTP responses from localhost and the remote server in Fiddler, and it seems fairly self-evident what the problem is:
Localhost:
HTTP/1.1 401 Unauthorized Cache-Control: private Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 WWW-Authenticate: Negotiate WWW-Authenticate: NTLM X-Powered-By: ASP.NET Date: Sat, 17 Dec 2011 23:42:34 GMT Content-Length: 6399 Proxy-Support: Session-Based-Authentication
Remote:
HTTP/1.1 401 Unauthorized Content-Type: text/html Server: Microsoft-IIS/7.5 X-Powered-By: ASP.NET Date: Sat, 17 Dec 2011 23:43:13 GMT Content-Length: 1293
Aside from a few seemingly-inconsequential differences like cache-control, the main difference is that the remote server is not sending the WWW-Authenticate headers back to the client.
So, I guess that narrows the question down to: Why is IIS not sending WWW-Authenticate headers when Windows Authentication appears to be installed, loaded, and exclusively enabled?
Problem solved. I finally decided to compare the module list side-by-side and there actually was one missing. It turns out that there are two Windows Authentication modules:
On the server, the managed WindowsAuthentication
module was there, but not the native WindowsAuthenticationModule
highlighted above. Why it was configured that way is anyone's guess, but apparently if the native module is not loaded, the managed module will cheerfully load and silently fail.
So for any future readers who encounter this problem, make sure you have both modules loaded, because IIS will not warn you if one of them is missing.
We found this didn't necessarily fix the problem for developers working locally on ASP.NET sites running under Windows Authentication. We found a registry hack that disables the loopback check; this fixed it: -
registry key - HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
Create a DWORD with value 1 called "DisableLoopbackCheck"
You will have to reboot the machine for the setting to take effect
User contributions licensed under CC BY-SA 3.0