why does windows authentication / impersonation fail on asp.net application with iis 7.5 / windows 7 /

Question

I'm troubleshooting why I can't get past the login dialog on an ASP.Net site configured for Windows Authentication and Impersonation.

I have an ASP.Net 2.0 application and I'm trying to deploy it on Windows 7 with IIS 7.5. I've created a new site, and bound it to localhost and a fully qualified domain name. the FQDN is in my hosts file, and is redirected to 127.0.0.1

The site is also running with an AppDomain I created, with integrated pipeline mode, and the process model identity is set to ApplicationPoolIdentity.

Web.config includes the following:

<trust level="High" />
<authentication mode="Windows" />
<authorization>
  <deny users="?"/>
</authorization>
<identity impersonate="true"/>`

ACL on the directory for the site is set to Everyone (Full Control - For testing). The Application Pool virtual account (Windows 7 thing) is set to full control on the physical directory for the site also.

IIS authentication has ASP.Net impersonation enabled and Windows Authentication enabled.

When I connect to the site as localhost, it permits me to get past the login prompt and the application loads without incident.

When I connect to the site as the FQDN set in the host headers bindings for this site/ip/port, I cannot get past the login prompt. Clicking cancel generates a http 401.1 error page.

Why?

Answer 1

The URL provided by Velvet is down. I found a cached version on archive.org:

" 401.1 Error When Accessing SharePoint From Server

I ran into this issue several times in the past in setting up SharePoint environments (for both internal development use and customers) so I figured it was time to write a blog post about it. If you are running SharePoint Server 2007 or WSS 3.0 on Windows Server 2003 SP1 or later you will run into authentication issues if you are trying to access a SharePoint site using host headers from the server itself (i.e. host file has portal.mydomain.com pointed to 127.0.0.1). This issue manifests itself as the result of a loop back security check that Microsoft built in to Windows Server 2003 SP1 and later. The purpose of the loopback check is to eliminate denial of service attacks however it causes issues with access SharePoint sites locally from the server. In a typical production environment this is typically not a problem since you rarely access SharePoint sites (besides central admin) from a front end web server itself. However I do have physical and virtual development environments where all activities take place from the server, so this can cause some heartburn unless you have worked through the issue before. You can read the detailed KB article at KB926642 & KB896861. Here is a rundown of how to fix the problem. I typically disable the loopback check however this is not recommended for production server environments.

Method 1: Disable the authentication loopback check Re-enable the behavior that exists in Windows Server 2003 by setting the DisableLoopbackCheck registry entry in the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa registry subkey to 1. To set the DisableLoopbackCheck registry entry to 1, follow these steps on the client computer:

1. Click Start, click Run, type regedit, and then click OK.
2. Locate and then click the following registry subkey: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
3. Right-click Lsa, point to New, and then click DWORD Value.
4. Type DisableLoopbackCheck, and then press ENTER.
5. Right-click DisableLoopbackCheck, and then click Modify.
6. In the Value data box, type 1, and then click OK.
7. Exit Registry Editor.
8. Restart the computer. Note You must restart the server for this change to take effect. By default, loopback check functionality is turned on in Windows Server 2003 SP1, and the DisableLoopbackCheck registry entry is set to 0 (zero). The security is reduced when you disable the authentication loopback check, and you open the Windows Server 2003 server for man-in-the-middle (MITM) attacks on NTLM.

Method 2: Create the Local Security Authority host names that can be referenced in an NTLM authentication request To do this, follow these steps for all the nodes on the client computer:

1. Click Start, click Run, type regedit, and then click OK.
2. Locate and then click the following registry subkey: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0
3. Right-click MSV1_0, point to New, and then click Multi-String Value.
4. In the Name column, type BackConnectionHostNames, and then press ENTER.
5. Right-click BackConnectionHostNames, and then click Modify.
6. In the Value data box, type the CNAME or the DNS alias, that is used for the local shares on the computer, and then click OK.

Note Type each host name on a separate line.

Note If the BackConnectionHostNames registry entry exists as a REG_DWORD type, you have to delete the BackConnectionHostNames registry entry. 7. Exit Registry Editor, and then restart the computer.
"

From: http://blogs.bluethreadinc.com/thellebuyck/archive/2008/10/30/401.1-error-when-accessing-sharepoint-from-server.aspx on June 05 2009

Answer 2

and the answer for this one is going to be a security feature known as the authentication loopback check, introduced way back in Windows 2003 SP1, as per: http://support.microsoft.com/kb/926642

i was trying to connect to my iis host headers instance using a host header defined in my /etc/hosts file as pointing to 127.0.0.1, while logged in at the machine running iis - this is the loopback scenario.

it bites you in various contexts, such as this (http://blogs.bluethreadinc.com/thellebuyck/archive/2008/10/30/401.1-error-when-accessing-sharepoint-from-server.aspx) or this world of hurt in google (http://www.google.ca/search?q=authentication+loopback+check&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-US:official&client=firefox-a)

THE FIX involves some simple regedit work: http://blogs.bluethreadinc.com/thellebuyck/archive/2008/10/30/401.1-error-when-accessing-sharepoint-from-server.aspx

i also did not need to enable impersonation for my situation, and so i disabled that, and now i can connect using my faked fqdn both locally and remotely