9

I have a web application set up in IIS 7 configured with Windows Authentication. I can authenticate to the machine via it's fully qualified url from any other machine and it uses the proper Domain. However, when I try to connect to the machine from itself via the fully qualified domain (either in another service, or just via url in IE), the Windows Login prompt tries to force the use of the computer as the domain, and not the proper domain for logging in. Trying to specify the domain with domain\username or username@domain.com fails.

I should note that viewing the web application via localhost on the machine works, but using the full site.company.com/webservice style url does not work on the local machine, because the login domain is wrong. What can I do to make it use the proper login domain?

roviuser
  • 255
  • 1
  • 2
  • 6

3 Answers3

11

I was trying to do the same thing. Access a web site on the local IIS using a FQDN and kept getting told where to go by IIS.

Anyways, from my digging, you have to disable the loopback check for local IIS websites.

See the following Microsoft support page.

In the event the page goes missing, the I did the following (which is what he recommends in the above blog post)

  1. Open up the registry editor by typing regedit under Run.
  2. Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0
  3. Right-click MSV1_0 and click New and choose to make it a Multi-String Value.
  4. Enter BackConnectionHostNames as name for the entry, and double-click it to modify it.
  5. Type the hostnames you need to use (code-journey.com for instance).
  6. Restart IISAdmin Service (“Start” -> “Administrative Tools” -> “Services”)

Hope this helps.

cmb..

Alex M
  • 103
  • 2
Craig Beuker
  • 228
  • 2
  • 5
4

This is due to a security feature known as LoopbackCheck.

Error message when you try to access a server locally by using its FQDN or its CNAME alias after you install Windows Server 2003 Service Pack 1: "Access denied" or "No network provider accepted the given network path"
http://support.microsoft.com/kb/926642

There are two resolutions:

Method 1 (recommended): 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.

Method 2: Disable the authentication loopback check by setting the DisableLoopbackCheck registry entry in theHKEY_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.
Greg Askew
  • 34,339
  • 3
  • 52
  • 81
  • What did the trick for me was the 2nd option - `DisableLoopbackChecking` in `HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa` – Icarus May 04 '20 at 23:36
1

I can tell you, based on some experience setting up SSO, that IE will automatically pass a kerberos ticket for logon only if the site and client are on the intranet together, or if the site is in the trusted zone. If IE sees http://site.company.com/webservice it will assume that the site is on the internet and will not pass credentials for logon.

There's some useful information at this link regarding IIS, IE, and Kerberos. http://blogs.msdn.com/b/friis/archive/2009/12/31/things-to-check-when-kerberos-authentication-fails-using-iis-ie.aspx

Two things we found that work for allowing the FQDN on the intranet is providing the web server with a certificate and using SSL, or adding it to the Trusted Zone.

Hope this helps in relation to your setup.

  • This doesn't solve the problem. I already tried adding the FQDN to the trusted zone, to no avail. I think though, that that solves a different problem. Adding it to the trusted zone allows *automatic* authentication, which I don't need - I'm alright with specifying credentials, but the issue is that it's not accepting my specified domain for login credentials - it's stuck on the computer name. – roviuser Oct 18 '12 at 19:24