ASP MVC Preview 5 and IIS 6 Windows Authentication

Question

I just created the base ASP MVC website for deployment on our intranet. He expects users to be in the same domain as the IIS mailbox, and if you are not an authenticated Windows user, you should not be granted access.

I just deployed this for IIS6 running on Server 2003 R2 SP2. The web application is configured with its own pool with its own pool user account. The IIS directory security settings for the web application are set only in the "Integrated Windows System", and the web.config file has:

<authentication mode="Windows" /> 

In a remote desktop session on the IIS6 server itself, the IE7 browser window can successfully authenticate and navigate the web application when accessed via http: // localhost / myapp .

However, also from the server, if it is accessible through the server name (i.e. http: // myserver / myapp ), then IE7 presents a credential dialog, which after three attempts to enter the correct credentials will eventually return "HTTP Error 401.1 - Unauthorized: Access denied due to invalid credentials. "

The same problem occurs when the workstation looks at the URL of the web application (naturally, using the server name, not "localhost").

IIS6 is a member of the only domain that we have and does not have a firewall.

Is there something that I could not properly configure for this?

Thanks,

---

I have tried offers from Matt Ryan, Graphain and Mike Dimmick so far without success. I just created a virtual machine test lab with a Server 2003 DC server and a separate server 2003 IIS6 server, and I can replicate the problem.

I see an entry in the IIS6 system event log when I first try to access the site through a non-localhost URL (i.e. http: // iis / myapp ). FQDN errors do not work either.

Source: Kerberos, Event ID: 4
The kerberos client received a KRB_AP_ERR_MODIFIED error from host / iis.test.local. The target name used is HTTP / iis.test.local. This indicates that the password used to encrypt the Kerberos service ticket is different from the password on the destination server. Typically, this is due to identically named computer accounts in the target area (TEST.LOCAL) and the client area.

Answer 1

After extensive Googling, I managed to find a solution in the following MSDN article:
How to create a service account for an ASP.NET 2.0 application

Specifically, the “Additional Considerations” section, which describes “Creating the Basic Service Names (SPNs) for Domain Accounts,” using the setspn tool from Windows Support Tools:

setspn -A HTTP / myserver MYDOMAIN \ MyPoolUser
setspn -A HTTP / myserver.fqdn.com MYDOMAIN \ MyPoolUser

This solved my problem both in my virtual test lab and in my original problem server.

It is also important to note in the article that using Windows authentication with users of the user pool limits the associated DNS name that will be used only by this pool. That is, another pool with a different identifier must be associated with a different DNS name.

Answer 2

Looks like the new Windows Server 2003 Service Pack 1 (SP1) re-check protection feature. As I understand it, it is designed to prevent a certain type of interception attack.

From http://support.microsoft.com/kb/896861

Problem

When you use a fully qualified domain name (FQDN) or a custom host header to view a local website hosted on a computer running Microsoft Internet Information Services (IIS) 5.1 or IIS 6, you may receive an error message that resembles the following: HTTP 401.1 - Unauthorized. Login Error This problem occurs when the website uses integrated authentication and has a name that maps to the local feedback address.

Note. You will receive this error message only if you try to view the website directly on the server. If you are viewing the website from a client computer, the website is working properly.

CAUSE

This problem occurs if you install Microsoft Windows XP Service Pack 2 (SP2) or Microsoft Windows Server 2003 Service Pack 1 (SP1). Windows XP Service Pack 2 (SP2) and Windows Server 2003 Service Pack 1 (SP1) include a loopback check feature that is designed to prevent reflections on your computer. Therefore, authentication fails if the FQDN or user header of the host you are using does not match the local computer name.

Bypass

• Method 1: Disable loop check.
• Method 2: specify host names

See http://support.microsoft.com/kb/896861 for more details.

---

Edit - I just noticed that you said that you see this on client PCs too ... which is more unusual. But I still look to check one of these workarounds to see if it fixed the problem (and if so, it might indicate a problem with your DNS configuration).

Answer 3

It seems to me that you did everything right.

I am sure that you are sure that you are using "DOMAIN \ user" as your user account, not just "user"?

Answer 4

IE7 only sends Windows credentials (NTLM, Kerberos) if it identifies the server as being on the Intranet. IE7 also added an intranet zone lock feature - if you are not in a domain, there are no servers in the intranet zone by default. This was done to prevent migration-zone attacks.

To change this, open the Tools / Internet Options tab, Security tab, then Local Intranet. Then you can manually add servers that should be processed as Intranet by clicking the "Sites" button, then "Advanced", or tell IE not to automatically detect your intranet and, if necessary, select other check boxes.

Answer 5

I ran into the opposite problem - my site is authenticated externally, but not locally.

I compared it with the sites we operate on, and the difference was that the site that failed authentication used Windows authentication.

However, the other sites I work with (this is a dev server) have basic authentication.

I don’t know why, but it’s fixed.

However, at the same time, I noticed the default domain and kingdom settings.

I know this is very unlikely, but can they even help?