ASP.NET Authentication Issues on IIS7 - User.Identity.Name is empty for Windows authentication

Question

We have an ASP.NET application on ASP.NET 4.0 using MVC 3 which uses Windows authentication.

When run from Visual Studio 2010 everything works as expected but when rolled out to IIS7 the Windows logged in user never gets populated (checking User.Identity.Name). No dialog prompt for user credentials comes up either.

The web.config setting:

<authentication mode="Windows" />

In IIS I can see that Windows authentication is enabled, as is Anonymous (disabling Anonymous results in a 403 Forbidden and no content being shown).

I've tried both enabling and disabling "Kernel-mode authentication" (useKernelMode="true"), but this doesn't seem to make any difference. Though I do remember that we had to disable this setting on another site on a different server to get the authentication to work properly (might point to a potential issue further down the stack?).

In case it's useful, from IIS's applicationHost.config:

<security>
  <authentication>
    <anonymousAuthentication enabled="true" />
    <digestAuthentication enabled="false" />
    <basicAuthentication enabled="false" />
    <windowsAuthentication enabled="true" useKernelMode="false">
      <providers>
        <clear />
        <add value="NTLM" />
      </providers>
    </windowsAuthentication>
  </authentication>
</security>

Any ideas what the issue could be?

Thanks in advance for any suggestions.

Update 1

I managed to find another IIS7 server to test on and I found if I disabled Anonymous access everything worked as desired. However I still have issues on the original IIS7 server even when I disable Anonymous access as well (I'm keeping Anonymous disabled now). So there must be some issue further down the stack I guess. Any ideas? Something I need to fix as it's going to keep popping up and biting us I imagine.

Update 2

If I enable Digest Authentication on the problem IIS7 box then I am challenged with the login prompt dialog and everything works as expected if I provide suitable credentials. But being an internal web app with users already logged in to the domain we don't really want to challenge them this way. Credentials should be passed through transparently as it works on the second IIS7 box.

Update 3

Some progress... I've found that if the web app is in the root and not a sub site then directly editing the applicationHost.config file for IIS7 to give the following authentication settings allows the site to work as expected:

<authentication>
  <anonymousAuthentication enabled="false" />
  <windowsAuthentication enabled="true">
    <providers>
      <clear />
      <add value="NTLM" />
    </providers>
  </windowsAuthentication>
  <digestAuthentication enabled="false" />
</authentication>

Using IIS7's UI to configure the authentication doesn't give quite the right results. authentication items are either missing after wards (as I guess IIS7 assumes they are being inherited) or they have the wrong settings (windowsAuthentication seems to need the providers configuration above present to work correctly).

Unfortunatly the web application in question is actually a sub application as there's an internal version (using windows authentication > www.site.com/internal) and an external version (using forms authentication > www.site.com/external). I still can't get the authentication to work as a sub application yet. I just get a "Error Code: 403 Forbidden".

Answer 1

In this case it was a Microsoft ISA Server issue. Seems the request was being routed internally through ISA for the Windows Authenticated site, once ISA was removed the problem disappeared.

I don't know a lot about ISA and how it routes requests but I assume it must have been stripping out some important information from the request because of some rule someone will have configured.

As a side note in case it helps diagnose similar setups: I was told by the network admin staff that internal traffic was not routed through ISA, but pinging the website internally showed that ISA was actually in play.