I have a public-facing web server (Windows Server 2008, IIS 7) with a web site which allows anonymous access. I have a subdirectory on this site which I have protected by disabling Anonymous Authentication and enabling Windows Authentication.

Working remotely, I have no problem logging in (any browser) to see these protected pages using:
username (no domain)

But... when there is an ASP.NET runtime error, I have to run at on the server in order to see the error. Here's the problem: For some reason, I cannot log in to these protected pages running IE8 on the server. The login dialog box pops up, but no login/pw works in any variation I've tried. What am I missing here? What is the format the server is looking for?

Edit: username/password is just a Windows login.

3 Answers 3


This is caused by the loopbackcheck which is enabled by default starting in Windows Server 2003 SP1. Basically it does an extra check and blocks your Windows Auth request from working on the same (loopback) machine.

You can turn it off by following the instructions in this KB article: https://mskb.pkisolutions.com/kb/896861.

Contrary to what the doc says, you don't need to reboot for IE to notice. It will work immediately. Here are the instructions that you can follow (the same as in the KB article)

  1. Click Start, type regedit, and then click OK.
  2. In Registry Editor, locate and select the following registry key: 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.

Test your page again on the local machine. It should work for you at this point.

  • What implications does this have for other software? Security considerations?
    – user21146
    Commented Dec 9, 2010 at 21:13
  • Nevermind, I can RTFM. Thanks for the answer, the KB article did the trick.
    – user21146
    Commented Dec 9, 2010 at 21:27
  • Great, glad that fixed it. That's a good question. "Why is it not the default" is always the question to ask. The setting is to protect against reflection attacks: owasp.org/index.php/Reflection_attack_in_an_auth_protocol. I can't say that it's a very likely attack on a properly configured web server, but do change at your own risk. Commented Dec 9, 2010 at 22:03

You might try another browser on the server to see if you have the same authentication error across the board, you could quickly test out with portable versions of Firefox/Chrome/Opera: http://portableapps.com/apps/internet

  • Thanks for the suggestion, but still no go with Firefox and Chrome.
    – user21146
    Commented Dec 6, 2010 at 23:33

In what IE security zone is the app URL? Have you tried putting the URL in the Intranet zone? or did you try to Force NTLM in the Local Security policy? See here: Cannot log in to Windows Auth protected pages while on the server). See this thread which sounds like the exact issue you are experiencing. https://stackoverflow.com/questions/2563445/why-does-integrated-windows-authentication-fail-when-clients-access-off-the-netwo

Do you have Enhanced Security Configuration enabled?

One method of bypassing the issue is to use ssh to forward the traffic to your workstation.

Use this as a guide to configuring the SSH tunnel: http://www.commandlinefu.com/commands/view/55/start-a-tunnel-from-some-machines-port-80-to-your-local-post-2001


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .