1
votes

Client setup:

  • Only browser that is affected is IE 6-8 (Firefox, Chrome, Opera, and Safari all work fine)
  • A user will try to access our web application from a company laptop that is not connected to our network.
  • This machine will be a member of our workgroup and have the company DNS listed as a trusted intranet site. (to which the application in question would be a member)
  • The security logon mode is set to Automatic Logon only in intranet zone only, and IWA authentication is enabled on the clients browser.

Server setup:

  • Windows Server 2003 fp2
  • The application will first redirect to an Authorization asp page which has anonymous access disabled and IWA enabled in IIS.

What should happen is that, since the client is not currently on the network, when this page is called it should prompt the user for network credentials. But with IE, instead of prompting, the user gets a "Page cannot be displayed" error because the IIS manager is denying access to the asp page. If the company DNS is removed from the trusted intranet site list then it prompts correctly but disables single sign-on the next time that computer is connected to the network or VPN.

My assumption is that since IE uses IWA and the site is listed as an internal site, when no network is found IE just sends nulls to the server attempting to authenticate which is swiftly punted back. Other browsers do not have security zones so when network credentials are not present the server prompts for them.

Is there a way to get around this so that our clients can keep the company DNS in the intranet zone but still have the server prompt for credentials when not on the network? Any attempt to allow for anonymous access on the asp page, as far as I know, will cause AUTH_USER to return null and again break SSO.

2

2 Answers

2
votes

IE will refuse to use NTLM/Negotiate through a proxy unless that proxy injects a

Proxy-Support: Session-Based-Authentication

response header.

Furthermore, IE will take zone-settings into account when deciding what the proper behavior is. You may want to adjust your Trusted Sites setting for Logon to "Prompt for Username and Password."

0
votes

Most likely the cause of your problem is a proxy that your clients are going through. This proxy is probably blocking NTLM authentication from the client. This is a common problem I have seen several times in the past.