Multiple Authentications Prompt while Accessing a Web Site Published through ISA Server 2006
1. Introduction
This post is about an interesting case where customer was publishing a web site through ISA Server 2006 and he wants to receive an authentication prompt when users access the web site rather than show the Forms Base Authentication page. No problem on that, but the issue was that when the external users were trying to access the web site by typing the URL one authentication prompt showed up (which was expected), after typing the credentials and click OK another authentication prompted showed up again (which was not expected). Here is the authentication window that appears when tried to logon:
Figure 1 – First authentication window.
After authenticate on this window, it comes the same prompt again and again. If the user keeps trying to authenticate it will end up with the error message below:
Figure 2 – Second authentication window.
If you careful read this error message you will see that it shows the 401.2 Unauthorized from IIS. This should already raise a flag that the issue might not be on ISA. However, to be on a safe place let’s move on to the data gathering.
2. Gathering Information
In scenarios like this, where the error message is flagged by IIS the first thing that you should do is to review the IIS logs and see if the traffic is indeed reaching the back end web server. By default IIS logs are located at %systemroot%\system32\LogFiles\W2SVC1, however is always good to double check where the Web Admin stored this file. Open IIS Manager, go to Web Site’s properties and click in Properties button under Web Site Tab / Enable Logging session as show in Figure 3.
Figure 3 – IIS Log Location
After opening this folder, check the log file that corresponds to the latest access from the test that you did from outside and check if you see the error code (401) in there. See where you should look in Figure 4:
Figure 4 – IIS Log with detail information.
That’s nice to see (at least for the ISA Admin J); now we know for sure that ISA is not the one sending the 401 to the client. But then it comes the question from the Web Admin: but why from the Internal network it works just fine?
To be able to answer that you need to review the IIS configuration and check if it matches with ISA Publishing rule. Let’s see the relevant parts for ISA Server first:
Figure 5 – Listener used in this scenario.
As you can see, in this case we are using HTTP Basic and Windows Authentication for validation method.
Figure 6 – Delegation Tab in the Publishing Rule.
ISA is not delegating credentials; it is passing through the traffic to the Web Server and letting the web server to authenticate the request.
Figure 7 – Users Tab in the Publishing rule.
Since the listener is requesting authentication we have All Authenticated Users here by default. Now let’s see the only par that really matters on this case for the IIS configuration, which is the Directory Security:
Figure 8 – Authentication on IIS.
3. Wrapping Up
As you could see in Figure 8, IIS is using Integrated and Basic Authentication, this means (per KB258063):
Windows Integrated authentication, also known as Windows NT Challenge/Response, must be enabled in the Web site properties in IIS. Anonymous authentication is attempted first, followed by Windows Integrated authentication, Digest authentication (if applicable), and finally Basic (clear text) authentication.
This pretty much explains why it works internally, the internal client that it is already logged in the domain will use Windows Integrated first and it will authenticate. When we are trying to connect from outside ISA requests the first authentication (based on the listener configuration that is using Basic), since ISA Server is not delegating it sends the authentication request to IIS, which prompts again for authentication. IIS fails to negotiate the authentication method with the client (IE) and prompt again; at that point the attempts to authenticate are logged in the IIS logs as we saw. ISA Server externalize that the user was not able to be authorized by logging the event below:
Figure 9 – ISA Logging.
There are two ways to resolve that: changing the directory security on IIS or changing the delegation on ISA Sever. Most of the time the administrators prefer to make changes on ISA Server, which is understandable. The options on ISA could be:
· Change the Users tab for All Users: not good since we want to pre-authenticate and allow only authorized users.
· Change the Authentication Delegation for Basic: not good since internally the traffic is not encrypted (he is using HTTP on port 82).
· Change the Authentication Delegation for NTLM: best option for this scenario. It will resolve the issue and keep the traffic secure.
After agree in choose this option, we just need to open the publishing properties and change the delegation to NTLM as show below:
Figure 10 – New Delegation Tab.
After make this change and apply the traffic flowed perfectly and we could see the HTTP 200 on IIS Logs as show below:
Figure 11 – Successfully authentication.
4. Additional References
Here some great resources to troubleshooting IIS authentication issues:
Troubleshooting HTTP 401 errors in IIS