On my system, I don't want to require domain users to enter their username and password when they use IIS 5.0. Therefore, I've set my site to allow only Integrated Windows authentication. Now, when a user types the NetBIOS computer name, the system doesn't prompt the user for a username and password. However, the system still prompts a user for a username and password when the user on a Windows 2000 client accesses the Web site using an IP address or the Fully Qualified Domain Name (FQDN) of the Web site. How can I prevent the system from prompting users for a username and password when they use the FQDN or IP address of my servers?
One benefit of using Integrated Windows authentication in IIS 5.0 or Windows NT Challenge/Response authentication in IIS 4.0 is that you can avoid forcing users to present credentials to log on to the server. When IIS requires a client to authenticate (e.g., you've disabled Anonymous authentication, or NTFS permissions require it), IIS attempts to use an intranet user's network credentials to grant access to the resource without prompting the user for credentials.
When IIS attempts to use intranet credentials, an exchange between IIS and the client browser that's transparent to the user occurs. The IIS end of this negotiation works well. However, managing the Microsoft Internet Explorer (IE) end can be a bit difficult when you want IE to use a Microsoft authentication method such as Integrated Windows or NT Challenge/Response.
One example of IE's idiosyncrasies is that IE 5.5 won't use Kerberos if you use an FQDN in the URL, although an earlier version of IE 5.x would. (For more information about this idiosyncrasy, see the Microsoft article "Kerberos Does Not Negotiate Using Internet Explorer 5.5 If an FQDN Is Used to Connect," http://support.microsoft.com/support/kb/articles/ q299/2/70.asp.) This idiosyncrasy could cause a well-running Kerberos authentication scheme to fail suddenly after you upgrade to IE 5.5. Authentication then falls back to the less-secure NT Challenge/Response authentication. Although IIS doesn't prompt users to provide credentials, your network is using a less-secure authentication.
To return to the question at hand, the Microsoft article "Error Message: HTTP 401.2—Unauthorized: Logon Failed Due to Server Configuration" (http://support.microsoft.com/sup port/kb/articles/q251/1/99.asp) details the problem that this question poses. Note that this article says that it's about IIS 5.0; it's really about IE. (The article also claims that you can't use Integrated Windows authentication across a firewall, but that depends on how you configure the firewall.) Nevertheless, the article's key point is relevant and states that if there is a period (.) in the URL, IE assumes that you're designating an Internet address and thus doesn't initiate authentication with IIS.
To make matters more confounding, if you use a proxy server and have gone through the trouble to set up IE to bypass the proxy server for local addresses, IE 5.x uses the proxy server anyway, even if the URL contains a period. (For more information about this bug, see the Microsoft article "Internet Explorer Uses Proxy Server for Local IP Address Even if the 'Bypass Proxy Server for Local Addresses' Option Is Enabled," http:// support.microsoft.com/support/kb/articles/q262/9/81.asp.)
Given the information in these articles, you can assume that IE's sole means for determining whether an address is local or remote is to check whether the URL contains a period. Clearly, this solution is incomplete. Other possible solutions to this problem are also limited. For example, IE does have a setting that controls how the browser behaves when IIS asks the browser to authenticate itself. To select this setting, choose Tools, Internet Options, then click the Security tab. Click Internet, then click Custom Level. Scroll down to User Authentication, which Figure 3 shows. By default, the Automatic logon only in Intranet zone option is selected.
To force IE to send credentials in the Internet zone, select the Automatic logon with current username and password option. When you select this option, IE automatically sends credentials when prompted if you've enabled Integrated Windows or NT Challenge/Response authentication. However, if the automatic logon fails, the system doesn't prompt users to enter correct credentials, which leaves them locked out of sites that they otherwise might have been able to enter had they been prompted.
Ultimately, the solution to this problem lies with the ability to add sites by name to the Intranet zone. You can enter your FQDN, complete with periods, and IE will treat it as an intranet site, even though it's external. In addition, you can use wildcards, so *.yourcompany.com will work for all hosts that use the form host-name.companyname .com. For more resources, see "For More Information."