When configuring the Web Proxy listener on a Microsoft ISA firewall, one of the things you will find in addition to the authentication methods available is an option to ‘require all users to authenticate’.
Selecting this option produces the following warning message:
Now why would Microsoft give us this option, then complain when we attempt to use it? I have no idea. But it is important to read this message thoroughly and understand what it is saying and why.
As the message indicates, requiring all users to authenticate may block traffic to sites such as Windows Update. The reason for this is that the Windows Update client on our servers and workstations runs in the background, under the context of the service host (svchost.exe) and is unable to provide authentication information to the ISA firewall. This same scenario applies to any unattended processes or services you might have running that require access to the Internet.
One thing that the warning message does not mention is that requiring all users to authenticate to the Web Proxy listener also breaks the automatic detection mechanism for Firewall Clients. The reason for this is that the ISA Firewall Client lacks the ability to respond correctly to the ‘HTTP 401 Unauthorized’ response that the ISA firewall returns when the Firewall Client attempts to retrieve the ‘wspad.dat’ file.
As the aforementioned warning goes on to say, Microsoft recommends enforcing user authentication on firewall policy access rules and publishing rules instead of requiring all users to authenticate to the Web Proxy listener. In this case it would seem that just because you can, doesn’t mean you should. If you must for some reason enable this setting (and honestly, I can’t think of any reason you would need to) there are some workarounds to allow automatic detection by the Firewall Client under these circumstances. Refer to Microsoft knowledge base article 88563 for more information.
One of my very favorite things about the Microsoft ISA firewall is the fact that you can do just about anything by leveraging the ISA Server administration COM object. Through scripting you can alter the configuration, automate repetitive or complex tasks, gather session information, import and export data, and much more. Here is a short example of a script that will display the version information for the ISA software you are running:
Dim Root, Server
Set Root = CreateObject(“FPC.Root”)
Set Server = Root.GetContainingServer
Set Server = Nothing
Set Root = Nothing
If you are interested in scripting the ISA COM object at all, ISA Server Administration Scripting on MSDN is a great place to get started. There you will also find a complete reference to all of the ISA related COM objects, as well as some sample scripts. There are some great web sites that have some excellent ISA scripts you can download and use as is. Jim Harrison’s ISATools.org is an excellent resource, as is Jason Fossen’s ISAScripts.org.
The Microsoft ISA Server Firewall Client is a wonderfully amazing piece of software that allows you to very granularly control network communication on hosts which it is installed (you can download it here). If you are not familiar with the Firewall Client, it is a software component that can be installed on Windows hosts that allows you to proxy any TCP or UDP based communication. There is no need to configure individual applications to work with the Firewall Client. It is a layer service provider that transparently intercepts Winsock calls and if the destination is remote, the Firewall Client sends that communication to the ISA firewall. Your routing infrastructure becomes transparent to your clients, and you gain the ability to enforce user and group based access control. Best of all, the Firewall Client logs not only the user name for each request, but the application that made the request as well. Very powerful stuff!
Troubleshooting Firewall Client communication can sometimes be difficult, however. Thankfully enough, there is a command line utility included with the Firewall Client that makes that job much easier. If you navigate to the ‘Program FilesMicrosoft Firewall Client 2004’ folder you will find a program called ‘fwctool.exe’. This tool allows you to do things like enable and disable the client software itself:
It can also be used to display the version of the Firewall Client software you currently have installed:
You can alter the configuration of the Firewall Client:
And you can display the current configuration information as well:
The Firewall Client has the ability to automatically configure the web browser that is installed on the workstation. This option can be displayed, enabled, or disabled from the command line as well:
You can also verify connectivity to the ISA firewall by using the PingServer option:
I absolutely love the Firewall Client because of its power and flexibility. Having the ability to leverage strong user and group based authentication on ALL TCP and UDP protocols is fantastic. Look for more posts here on my blog about the Firewall Client and how to troubleshoot it as well as to leverage it.
Several people have written to me in response to my earlier blog post ‘HTTP 2.0 Specification?‘ asking why I would have my ISA firewall behind a Cisco ASA. The answer is simple: enhanced security! I am following a long standing security best practice by implementing security in layers; defense in depth. Now, it’s not that the ISA firewall isn’t totally and completely capable of acting as an edge firewall, because it most certainly is. In this case though, I have elected to use an ASA as my edge firewall because I don’t need any real intelligence there. All I want is to do some very simple packet filtering here; basically just filtering out the bulk of the noise from the Internet and allowing my internal ISA firewall, with its advanced deep application layer inspection capabilities and granular user and group based access controls to do the important network communication inspection.
In addition to enhanced security, there are some other benefits to using the ASA (or another firewall) at the network edge. If someone were to circumvent the access controls that are in place on that edge firewall, they would not be able to use those same methods of exploitation on the ISA firewall. If I practice security in layers but deploy the same model firewall at each layer, an attacker can use the same method used to bypass my internal firewalls as they used to bypass my edge firewall.
An additional benefit by using another firewall at the network edge is that by squelching ‘Internet noise’, the logs on the ISA firewall become much more meaningful. It allows me to find important information much more quickly than having to sift through mountains of data this is mostly port scans and probes that occur constantly on the public Internet. This also frees up resources on my ISA firewall that are better put to use on inspecting important traffic.
I wanted to share with everyone what I thought was an entertaining issue that was brought to my attention by one of our (Celestix) support engineers recently. The issue was a classic one for most seasoned ISA firewall administrators; 502 proxy error (request not supported) when accessing a specific site, but the same site can be reached without issue behind any other firewall or router. Clearly the ISA firewall, with its deep application layer inspection capabilities, is objecting to something in the communication stream and denying our request. Now, there are plenty of other documented examples of this type of scenario, but what I found particularly entertaining about this specific one (and hence compelled to write about it here) was the response I see coming from the remote web server…
HTTP/2.0? This was not a specification I was aware of, but as a sanity check I posed this question to some folks that know a lot more about this stuff than I do. Thankfully, Jim Harrison did confirm for me that HTTP/2.0 is not a valid specification. Thanks Jim!
Again, this is a fairly common scenario when you deal with the ISA firewall. Because the ISA firewall is capable of understanding communication at the application layer (layer 7), it is designed for security reasons to disallow ANY non-RFC compliant communication. That includes any fictitious HTTP specifications that vendors decide to dream up as well. And once again, this is another shining example of the power and security of the ISA firewall. With these advanced features, the ISA firewall does far more to protect your network communication than any firewall on the market today. In this instance, had this been a malicious site, any other firewall (certainly my ASA!) would blindly allow the communication.
I wanted to bring to your attention today a wonderful document authored by Joe Davies called ‘TCP/IP Fundamentals for Microsoft Windows‘. This is an incredible resource, with over 500 pages of detailed information regarding TCP/IP networking in Microsoft Windows. Recently it was updated to include information for Windows Server 2008. What is really amazing is that it is a free download! Joe Davies has authored (and co-authored) many Microsoft Press books on networking, including the TCP/IP Protocols and Services books, Understanding IPv6, Windows Server 2008 Networking and Network Access Protection (NAP), and many more. Joe is also the author of ‘The Cable Guy‘ column that is featured in Microsoft Technet magazine and online.
Recently while working with one of my customers I came across some odd behavior on a Windows Vista client workstation. We noticed that Windows Vista workstations that were configured as Web Proxy and Firewall Clients only (no default gateway) were unable to access non-web based remote resources (e.g. RDP and FTP) by hostname (single label or fully qualified). They could, however, connect by IP address. The odd thing was that Windows XP clients configured in the identical manner did not exhibit this behavior. Windows XP clients configured as Web Proxy and Firewall Clients without a default gateway could access non-web based remote resources without issue, by hostname or IP. In either case, web proxy communication (HTTP, HTTPS, tunneled FTP) worked perfectly.
Name resolution on the Windows Vista client worked flawlessly, so I opened a case with Microsoft so they could shed some light on this for me. After some additional research on their part they were able to determine that this was expected behavior on Windows Vista. Apparently the DNS resolver in Windows Vista filters out hostnames for destinations that are not reachable from the local host. Without a default gateway, Vista had determined that it couldn’t connect to the resource because it had no route to the remote network (obviously not aware of the Firewall Client) and so communication fails.
The resolution was simple enough…add static routes to any remote internal networks, or if Winsock access to the general internet was required, then add a default gateway. And while you may not encounter this particular scenario in complex, large scale corporate networks, it is fairly common in small, flat networks deployed at many SMB’s. If you are like me and have recommended in these scenarios that you deploy only the Firewall Client, it appears that option is no longer available.