Share via

Changes to authentication in XPSP2

  • Article

One of my customers ran into an interesting issue when upgrading their developer workstations to Windows XP SP2 - they stopped being able to debug ASP.NET applications running on the local IIS5.1 webserver. They went through the standard steps of ensuring permissions and appropriate security group membership, but it still failed. Turns out they have a less than standard configuration and ran into a new security check in Windows XP SP2. First their configuration.

 

They are running multiple websites on IIS5.1, which until this case I didn't know was possible. It is, as long as only one site is running at a time. Each site represents one of the potential sites their developers could be working on. Then each VS.NET is configured to point at a FQDN for the site. For instance, say the production web site was www.contoso.com, the dev project would be configured as www.contoso.dev. Then (and here is where things get interesting), www.contoso.dev is configured in their DNS servers to resolve to 127.0.0.1. Other projects have other DNS names that resolve to 127.0.0.2, 127.0.0.5, etc, etc. Since these are all in the loopback range, they all resolve to the local machine.

 

Forgetting about their reasoning for this for a moment, what was happening was authentication was failing on the website. We could see this from the IIS logs that looked something like this:

 

2005-02-25 16:20:20 127.0.0.21 - DEBUG /Default.aspx 401 398 Microsoft-Visual-Studio.NET/7.10.3077 -
2005-02-25 16:20:20 127.0.0.21 - DEBUG /Default.aspx 401 235 Microsoft-Visual-Studio.NET/7.10.3077 -

Browsing with IE to the DNS name with anonymous disable gave us the credential prompt, which would not take any valid credentials. The interesting thing was this - if we browsed to https://localhost, it worked fine. If we put www.contoso.dev in the hosts file, it worked. So what was going on?

 

Turns out, SP2 added a new protection against reflection attacks. Namely, SP2 no longer allows authentication to be performed across the loopback interface if the name does not
match the name of the local machine. This can be disabled a couple different ways:

 

  1. Disable the loopback check completely by adding the following registry key (requires reboot):
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\DisableLoopbackCheck
    This key should be a REG_DWORD and set to 1
  2. Instead of opening it up to any hostname mapped to 127.0.0.1, you can limit the hostnames allowed by adding each hostname to the following registry key:
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0\BackConnectionHostNames
    This key should be a REG_MULTI_SZ and set to the host name you are using.

 

Probably the safest is to add www.contoso.dev to the second registry key.

 

A ton of thanks to Kyle Terns, a support engineer on the IIS team for the help in tracking this one down.

 

UPDATE:  Looks like there is a KB Article on this now (896861)

Comments

  • Anonymous
    February 16, 2005
    This is the kind of support information that can be really valuable and will probably never appear in a KB article. Thanks for posting it!

    Ken
  • Anonymous
    February 16, 2005
    I've been told a KB article is in the works on this. Knowing it does take a while for that to appear (and the fact I spent so much time troubleshooting this with the ASP.NET, IE and IIS support queues) I decided to publish it here.