We just published a new article at Tales from the Edge Community Site that describes how to troubleshooting LDAPs authentication through ISA Server 2006. Check it out at:
http://technet.microsoft.com/en-us/library/dd316279.aspx
One last Christmas present for IAG administrators!! It was launched this month the IAG TechNet Library which will be the main source of documentation for IAG. This means that old PDFs for IAG will be retired of updates, those PDFs are still valid for reading and understanding the core concept of IAG and also to have a foundation of the product, however from now on make sure to add the link below to your favorites:
http://technet.microsoft.com/en-us/library/cc303240.aspx
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
401.1 and 401.2-Authentication Problems (IIS 6.0)
HTTP Status Codes in IIS 6.0 (IIS 6.0)
This post could easily be called “Slow Internet through ISA Server”, but I decided to change the title and the focus. I’m doing that for a simple reason: people still thinking that only Windows system needs to be patched. What an untrue statement this is and how I’m convinced more and more that if you don’t think secure in all layers you soon or later will be owned.
This post is about of a phone call with a friend of mine that was supposed to be just 10 minutes but it took one hour to finish. He was having a problem on his network and as usual “nothing change” but “Internet access stopped to work”. Believe or not this is one of the rare scenarios where this was true. Nothing really change on his network, on his ISA Server but suddenly his ISA was timing out for all Internet access request.
His topology was like this here:
ISA Server was only in use for proxy/cache purpose, all the web proxy clients were pointing to this ISA box to have internet access. According to some tests that were done if we point directly to his edge firewall as gateway he was able to access Internet.
The Problem
After capturing a simple netmon while client was trying to access Internet I could see a very interesting behavior:
16:56:53.121 192.168.1.1 192.168.1.10 ICMP ICMP:Redirect Message
16:56:53.136 192.168.1.1 192.168.1.10 ICMP ICMP:Redirect Message
16:56:53.152 192.168.1.1 192.168.1.10 ICMP ICMP:Redirect Message
16:56:53.168 192.168.1.1 192.168.1.10 ICMP ICMP:Redirect Message
There were tons of those ICMP Redirect packages from the router to the ISA Server while the communication was happening. This was a déjà vu for me, those ICMP packages flowing in the network makes me remember the old times where Windows NT was vulnerable to ICMP Attack and we had lots of server hanging issues. Anyway, by opening the ICMP Package it was possible to see an even more interesting detail:
+ Ipv4: Src = 192.168.1.1, Dest = 172.16.4.80, Next Protocol = ICMP, Packet ID = 43969, Total IP Length = 56
- Icmp: Redirect Message
Type: Redirect Message, 5(0x5)
Code: Redirec datagrams for the host 1(0x1)
Checksum: 43532 (0xAA0C)
GatewayIPAddress: 192.168.1.111
The gateway address in red is explained in RFC 792 as “Address of the gateway to which traffic for the network specified in the internet destination network field of the original datagram's data should be sent.”
Looking to the diagram you might be thinking: who is 192.168.1.111? Well that’s was exactly my question. For my surprise, it was a workstation!! We unplugged this workstation from the network, disabled ICMP Redirect in the router (#no ip icmp redirect), restarted the router and everything started to work just fine. Hum, not ISA Server again right? Exactly!!
Conclusion
His old Cisco router was completely out of date and vulnerable to Cisco IOS Route Manipulation via ICMP Redirects. That’s an old vulnerability that was already fixed, but as I said in the beginning of the post: people sometimes think that only Windows system needs to be patched. Although this is a buddy of mine I told him that he forgot to do his homework on this case and that was pretty much his fault. The next course of action for him was to scan that network and to see if there was any kind of malware on it and also update the router and switches.
Do you want to know how TMG plays in the EBS solution? If you do, than next week is your chance to get a full clarification from Amy Babinchak and Tom Shinder in a live presentation. For more information check out Tom’s blog:
http://blogs.isaserver.org/shinder/2008/12/09/amy-babinchak-and-tom-shinder-present-on-the-ebs-tmg-firewall/
I would like to share with you this article that I wrote for Microsoft Security Tip of the Month (November 2008). This article was reviewed by Yury Berezansky, Senior Developer from TMG Team in Haifa and responsible for the Malware Inspection feature in TMG.
Check it out the complete article here:
http://technet.microsoft.com/en-us/library/dd253247.aspx