22

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:

  • The machine is running Windows 7 Ultimate, Service Pack 1, IIS 7.5.
  • The site has been tested successfully, using both IIS and the VS Web Development Server.
  • The IIS site config has all authentication methods disabled except Windows Authentication.
  • The local machine is not on any domain.
  • The Providers set up are Negotiate and NTLM (not Negotiate:Kerberos).
  • Extended Protection is Off.
  • All browsers tested (IE, Firefox, Chrome) show the challenge prompt and allow me to log in to the localhost domain with my (local) Windows account.
  • All browsers tested also work using an opaque local IP address - so the browsers themselves don't seem to care whether the site appears "local" or "remote".
  • I've added a display line to the web page which shows the currently-logged-in user and it shows exactly what I would expect (whichever local user I logged in with).

On the remote machine:

  • The server is running Windows Server 2008 R2, IIS 7.5.
  • Loading the web page results in an immediate 401.2 error: You are not authorized to view this page due to invalid authentication headers. No challenge prompt ever appears.
  • The IIS site config has all authentication methods disabled except Windows Authentication.
  • The remote machine is not on any domain.
  • The Providers set up are Negotiate and NTLM (not Negotiate:Kerberos).
  • Extended Protection is Off.
  • On the remote machine (remote desktop session), the same error appears in Internet Explorer regardless of whether the domain is localhost or the external IP address.
  • If I try to view the remote web site from my local machine, the error is still 401, but a slightly different 401. No subcode, with the text: Access is denied due to invalid credentials.
  • The Windows Authentication IIS role feature is installed.
  • The WindowsAuthentication Module is added (at the Server level).
  • The exact same error occurs if I turn off Windows Authentication and enable Basic Authentication.
  • The site does load if I turn off Windows Authentication and enable Anonymous (obviously).
  • I've already followed all of the troubleshooting steps on Microsoft Support: Troubleshooting HTTP 401 errors in IIS
  • I've already tried the workaround shown on another Microsoft support page (supposedly to force NTLM as the only method).

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?

the-wabbit
  • 40,319
  • 13
  • 105
  • 169
Aaronaught
  • 492
  • 2
  • 4
  • 13
  • Mind capturing a plaintext wireshark of the authentication attempt (change your password to something throwaway first - we don't want your real password hashes on the net)? A 18 months or so back a Windows patch made some changes to HTTP NTLM negotiation (by the way, are the systems patched all the way up?) which blew up a vendor's app and gave me way more experience than I care to admit with analyzing negotiation conversations. – Shane Madden Dec 17 '11 at 22:30
  • @ShaneMadden: I kind of do mind on account of all the various bits of information I'd be exposing, but I can do a Fiddler session which should be almost the same, and then I can at least anonymize IPs and so on - and in fact I already did, the results should be pretty self-explanatory (the client is not showing the credentials prompt because the server isn't asking for any). – Aaronaught Dec 17 '11 at 23:50
  • Oh, interesting, [somebody seems to have reported this problem on Stack Overflow](http://stackoverflow.com/q/1589202/38360) as well - no answers there, sadly. – Aaronaught Dec 17 '11 at 23:53
  • @Aaronaught How did you get a different username here than on Cooking? When I first saw this question, I thought it was someone spoofing you. – Ward - Reinstate Monica Dec 18 '11 at 07:34
  • @Ward: Anybody can edit their username, it's part of the profile. This was my original one, only use others on the non-tech sites. – Aaronaught Dec 18 '11 at 13:41

2 Answers2

15

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:

Module List

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.

ThoriumBR
  • 5,272
  • 2
  • 23
  • 34
Aaronaught
  • 492
  • 2
  • 4
  • 13
  • The managed WindowsAuthentication module isn't what it sounds like. It's support for Windows identities in ASP.Net, and it's always installed (when ASP.Net is installed). But the Windows Authentication *native* module is what gets installed when you tick the Windows Auth component in Server Manager, and that's what you need in order for that authentication option to become visible in the Authentication GUI. – TristanK Dec 18 '11 at 00:32
  • @TristanK: In this case, that component was ticked, but the module was not installed. (The option was, however, visible in the Authentication GUI - so I'm pretty sure that screen depends on the managed module, not the native one.) – Aaronaught Dec 18 '11 at 00:38
  • I'm thinking that it may have gotten this way due to some tampering with the config files (probably ApplicationHost.config). But I guess it doesn't matter how it got all out of whack; it did. – Aaronaught Dec 18 '11 at 00:58
  • Well, clearly. Windows Auth doesn't not-work unless something happens to break it; in this case, while the question states the configuration is identical, that turns out to be untrue; so it didn't work the same. QED. – TristanK Dec 19 '11 at 01:06
  • 1
    This missing module issue just bit me in Windows Server 2012 R2. It's incredible that there is no indication when this condition occurs. Anyway, thanks so much for this answer; I was literally tearing my hair out! – Rob Davis Mar 20 '17 at 16:21
  • Where to see the list of both managed and native modules in IIS? – Ned Dec 06 '18 at 14:24
5

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

sh1rts
  • 161
  • 1
  • 3
  • I found i could toggle between DisableLoopbackCheck being 1 and 0 and the change would take effect immediatly. In addition you can see Event ID 4625 in the event log Security log with message "The account failed to log on" . – alastairtree Aug 31 '16 at 11:47
  • Thank-you! 2 days of faffing about with IIS authentication and .Net versions only to find it's because I was using my hosts file to create a dummy DNS entry whilst testing a site migration. – JohnLBevan Oct 11 '17 at 19:05
  • it's safer to set BackConnectionHostNames instead of DisableLoopbackCheck, see https://support.microsoft.com/en-us/help/926642/error-message-when-you-try-to-access-a-server-locally-by-using-its-fqd for details. – Recep Jun 16 '20 at 19:02