As I describe in "Authenticate Internet Access with ISA Server," June 2003, http://www.secadministrator.com, InstantDoc ID 38773, Microsoft Internet Security and Acceleration (ISA) Server 2000 supports three methods for providing controlled Internet access for internal clients: Secure Network Address Translation (SecureNAT), Web proxy, and firewall. SecureNAT doesn't require any configuration on the client computer other than setting the default gateway of the client machine to be the ISA Server machine, a task that's usually automated by using a DHCP server. (In a subnetted environment, the ISA Server system doesn't need to be the default gateway, but the default route needs to go through the ISA Server machine.) However, SecureNAT access doesn't use username-based authentication, so you might prefer the Web proxy and firewall methods, which provide user-specific access control.
The Web proxy method requires setting one client browser option, and the firewall method requires Firewall Client software installation. Although the Web proxy and firewall configuration might not look like a chore at first, remote clients and maintaining client configurations as you add and remove ISA servers complicate the task for administrators. Fortunately, you can easily set up the ISA Server Web Proxy service and Firewall Server so that configuration is automated for users.
Figure 1 shows my enterprise's network topology. An intranet with the address 10.0.0.0 connects a server named ALPHA (which runs DHCP and DNS and has the address 10.0.0.2) and a client named BETA-CLNT. The intranet also connects to the Internet through an ISA Server machine named ISA-LEON. My objective is to ensure that with minimal configuration on the user's part, BETA-CLNT can access the Internet through ISA-LEON. I first configure the Web proxy access (which allows only HTTP and HTTP Secure—HTTPS—traffic), then the firewall access (which enables applications such as FTP and Telnet to get to the Internet).
Web Proxy and Firewall Recap
To refresh your memory of the Web proxy and firewall Internet access methods, let's recap. ISA Server consists of two services: the Web Proxy service and Firewall Server. Client browsers set to use the Web proxy access method send all HTTP requests directly to the ISA Server machine, which performs the requests on the client's behalf. This method works only for applications such as Microsoft Internet Explorer (IE) that can use Web proxy. To provide Internet access for other client applications such as FTP and Telnet, ISA Server supplies the Firewall Client application for the client machines. Firewall Client is implemented as a Layered Service Provided for Winsock and provides Internet access for client applications.
Administrators frequently configure clients to use both Web proxy and Firewall Client Internet access. Administrators might want to use Web proxy access because unlike Firewall Client, Web proxy can prompt the user for his or her proxy credentials. Firewall Client doesn't prompt the user for credentials and uses the user's logon credentials instead.
If you configure the client browser to use Web proxy, the client will use Web proxy for HTTP and HTTPS requests, regardless of whether Firewall Client is present. If you don't configure the browser to use Web proxy, IE assumes a direct Internet connection. However, because Firewall Client intercepts every Winsock call, ISA Server's Firewall component will still provide the Internet connection.
Configuring WPAD with DHCP
To set up intranet client machines for automatic discovery of the ISA Server machine as a Web proxy, you need to perform three tasks. First, you must configure the ISA Server machine to support the Web Proxy Autodiscovery Protocol (WPAD). Second, you must ensure that the client machine can locate the computer running ISA Server and providing the proxy service. And third, you must ensure that the client browsers support WPAD.
To configure ISA Server to support proxy autodiscovery, right-click ISA-LEON in the Microsoft Management Console (MMC) ISA Management console, which Figure 2 shows, and select Properties. Go to the Auto Discovery tab, which Figure 3 shows, select Publish automatic discovery information, and enter the port for the autodiscovery information. ISA Server makes the autodiscovery information available on the port used for all outgoing requests (you can see this port on the Outgoing Web Requests tab)—port 8080 in my installation. The Auto Discovery tab makes the autodiscovery information available on any additional port of your choosing—port 9090 in my setup.
Your approach to ensuring that the client machine can locate the ISA Server machine depends on your enterprise's network architecture. If DHCP is present in the enterprise, the client broadcasts the DHCPINFORM message and requests option 252. The DHCP server stores various client-configuration parameters in the form of options, which it sends to the client machine upon request. Option 252 is reserved for WPAD. ALPHA runs the intranet's DHCP server, so you can add option 252 to its DHCP scope. Open the MMC DHCP console, right-click ALPHA, and select Set Predefined Options. The Predefined Options and Values dialog box will appear; click Add. Figure 4 shows how to add option 252, WPAD. After you click OK, you'll see the Predefined Options and Values dialog box again—this time, containing information about your new option. The string http://isa-leon:8080/wpad.dat represents an automatic configuration URL that the client browser will use to connect to the ISA Server Web Proxy service to obtain proxy information. (You enter this string as a value for DHCP option 252.) Note that the URL points to a specific ISA Server machine. If your environment has an array of multiple ISA Server machines, using an automatic configuration script is more efficient. I talk about that option later in this article.
The DHCP server will send the URL to the client's browser when the client makes a DHCPINFORM request. Notice the port number. It can be either the ISA Server machine's outgoing port (8080, in my case) or a port that you've configured specifically for the autodiscovery information (9090).
After you've configured the option on the DHCP server, you must enable it for the scope. To do so, in the DHCP console, right-click Scope Options under the intranet's DHCP server, and select Configure Options. On the General tab, scroll down the list of the configured options, and select 252 WPAD.
IE versions starting with 3.02 support WPAD, so as long as your clients are using IE or any other browser supporting autodiscovery, the third step in configuring clients in a DHCP network to use proxy autodiscovery is easy. On the client computer's browser menu, go to Tools, Internet Options, Connections. Click LAN Settings and select the Automatically detect settings check box in the Local Area Network (LAN) Settings dialog box, as Figure 5 shows.
After you've performed these three steps, when the user on the client machine navigates to any URL, the following takes place: The browser obtains the URL for the WPAD entry (in my case, http://isa-leon:8080/wpad.dat) from the DHCP server. The browser reads the contents of the wpad.dat file. To see the contents of your wpad.dat file, enter your autodiscovery URL in an intranet client browser and open the wpad.dat file in Notepad.
The wpad.dat file is a JavaScript file that implements a few functions. All the functions that this file uses are documented at http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/ie/reskit/ie6/part6/c26ie6rk.asp. The key one is FindProxyForUrl, which tells the browser which proxy server to use to reach the URL that the user entered.
ISA Server creates the wpad.dat file based on the ISA Server configuration. For example, adding domains to ISA Server's Local Domain Table (in the ISA Management console under Network Configuration) alters wpad.dat in such a way that FindProxyForUrl will always return DIRECT when the browser requests a proxy name for any machine from the local domain table.
The beauty of autodiscovery is that ISA Server creates a complex wpad.dat file that the browser uses to find the optimal route to the requested URL. Any change in the ISA configuration is reflected in the wpad.dat file and therefore affects all clients configured to use autodiscovery.
Configuring WPAD with DNS
You can also achieve proxy autodiscovery by using DNS instead of DHCP, which is beneficial if your enterprise doesn't use DHCP. The first step is to make sure that ISA Server publishes proxy autodiscovery information on port 80. If you have any other application (such as IIS) on the ISA Server machine that already uses port 80, you must reconfigure that application to use a different port. Next, go to the MMC DNS console and add a new alias (CNAME) record for WPAD to the forward lookup zone for the domain in which the ISA Server machine is located. My home domain is leonhome.com, so the Fully Qualified Domain Name (FQDN) for my ISA server is isa-leon.leonhome.com.
Testing the DNS setup is simple. I configure BETA-CLNT to use a DNS server running on ALPHA by manually configuring the TCP/IP properties for BETA-CLNT to use the DNS server 10.0.0.2. Alternatively, a DHCP server can supply the DNS server address as a DHCP option. Then, I can easily verify that BETA-CLNT's browser can access the wpad.dat file by entering http://wpad.leonhome.com/wpad.dat at the browser. Select the Automatically detect settings check box in the browser's Local Area Network (LAN) Settings dialog box as I described earlier, and when the user on the client machine navigates to any URL, the browser will check wpad.dat for the right proxy server to use.
The DHCP approach affords a higher level of granularity than DNS. DNS forces ISA Server to listen on port 80 for autodiscovery requests and allows only one ISA Server WPAD entry for the entire domain. DHCP, however, allows different WPAD entries for different scopes (but only one WPAD entry per scope). Large enterprises are likely to have more than one ISA Server, and DHCP can point the client to the nearest ISA Server machine.
Configuring Firewall Client
As I've just demonstrated, you (or a user) can easily configure a client browser to use ISA Server's Web proxy server. Alternatively, you can install ISA Server's Firewall Client on the clients and configure browsers to access the Internet directly (i.e., not through a proxy). After you install Firewall Client on the client, all Winsock applications can enjoy Internet access without special configuration. The Web proxy and firewall methods of accessing the Internet have no formal connection. However, installing Firewall Client offers the extra benefit of optionally configuring IE to use Web proxy. This configuration takes place only upon initial installation of Firewall Client. After you install Firewall Client, it doesn't interact with the browser's proxy settings in any way.
You can make all the Web proxyrelated client configuration changes by using the Client Configuration node of the ISA Management console. As Figure 2 shows, the Client Configuration node has two subnodes: Web Browser and Firewall Client. In the right pane, double-click Web Browser to open the Web Browser Properties dialog box, which Figure 6 shows. The General tab lets you specify browser settings that Firewall Client installation program will configure during client setup. You can use this tab to automatically configure IE during Firewall Client setup so that the browser will use a specific proxy server and port (ISA-LEON and port 8080) and the Automatically discover settings option.
If you install Firewall Client and set the browser to use Web proxy, the browser will use Web proxy. If you install Firewall Client and set the browser to access the Internet directly, the browser will use the firewall. (Internally, ISA Server's HTTP Redirection Filter redirects firewall HTTP requests to the Web proxy service, but you can configure ISA Server not to redirect HTTP requests.)
The Web Browser Properties dialog box's General tab also lets you set browsers to use an automatic configuration script, an option that I mentioned earlier. You don't really need such a script if you have only one ISA Server system, as our sample scenario does. However, I'd like to take a moment to explain the script because it's a better choice if you have multiple ISA Servers. To explain the script, I first need to explain ISA Server's distributed caching feature.
ISA Server uses the Cache Array Routing Protocol (CARP) to effectively retrieve cached content. CARP provides distributed content caching for an array consisting of more than one physical ISA Server machine. CARP provides positive scalability—increasing the number of servers in the array causes more effective caching. CARP overhead is much lighter than the overhead of other caching technologies such as the Internet Cache Protocol (ICP). Here's how CARP works: The CARP array determines which ISA Server machine in the array has a needed cache entry according to the server name's hash value combined with the URL's hash value. Such calculations ensure that cache entries are evenly distributed between all ISA Server machines. The administrator can adjust the load factor of each machine to account for the difference in the CPU or physical memory. The load factor is taken into consideration when the hash function is applied. Therefore, a machine with a less powerful CPU will cache fewer entries.
Each ISA Server machine in an array contains information about all the other array members and can make this information available to clients in a routing script. The General tab in Figure 6 shows the URL for such a script (in this case, http://ISA-LEON:8080/array.dll?Get.Routing.Script). ISA Server updates the script whenever you add a server to or remove one from the array. Note that the script returns information such as what array member to use for a specific URL request to ensure that the request goes to an ISA Server machine that contains that URL in its cache.
The script, which functions similarly to the wpad.dat file I described earlier, is the preferred method of setting up a browser for Web proxy access in an array environment. The script has the most recent information about all the array members and ensures that in the distributed cache environment that an array provides, a client browser request goes to the server on which the content is cached.
Firewall Client software installation will automatically set IE to use the automatic configuration script if you select the Set Web browsers to use automatic configuration script check box on the General tab. If you elect to use the automatic configuration script, before sending the user's URL request, IE reads the script, which contains the hash function that processes the user's URL and gets back the name of the ISA Server machine that contains the desired cached content.
Now that I've explained how configuring Firewall Client affects the Web proxy browser settings, I describe how to configure the actual firewall settings. The second subnode under Client Configuration in the ISA Management console lets you configure options for Firewall Client, a helper application that's implemented as a Layered Service Provider for Winsock. In the console's right pane, double-click Firewall Client to open the Firewall Client Properties dialog box. On the General tab, which Figure 7 shows, make sure that the Enable ISA Firewall automatic discovery in Firewall Client check box is selected. To further improve users' experience, you can configure Firewall Client to automatically detect which ISA Server machine it should use. You use the dialog box's Application Settings tab to configure which processes will use the firewall and which ones won't.
The ISA Server installation program automatically creates Firewall Client and maps it to the %programfiles%\microsoft isa server\clients directory. Then, you install Firewall Client on each client computer. Users on my intranet install Firewall Client directly from the \\isa-leon\mspclnt share. Alternatively, you can leverage Active Directory's (AD's) software installation feature to assign Firewall Client to specific users and computers, then automatically install the software the next time the user logs on. After the software is installed, it appears as an icon in the system tray. Double-clicking it opens the Firewall Client Options dialog box. (For more information about AD's software installation feature, see "Software Installation in Windows 2000," February 2000, http://www.winnetmag.com, InstantDoc ID 7886.)
Installing Firewall Client software on the client machine forces all client settings to take effect. These settings include the settings you configured in the Web Browser Properties dialog box. Any client-related changes you make after Firewall Client installation are automatically propagated to the client machines at a regular interval. Users can also click Update Now in the Firewall Client Options dialog box to download changes from ISA Server immediately.
After you install Firewall Client, it intercepts each Winsock call. Instead of letting a network request go through as usual, Firewall Client creates a special channel to the ISA Server machine and routes the request to ISA Server's Firewall service. The firewall performs a network request on the client's behalf and sends a response back to the client. The result is a seamless Internet connection for all network applications running on the client computer.
In this article, I ventured into an explanation of ISA Server's automatic Web proxy and firewall configuration options. My aim was to demonstrate that users need to perform little or no special configuration to have Internet access through ISA Server. I showed you how to enable Web browsers to access URLs through automatic WPAD. I also described how to let applications access the Internet with the help of ISA Server's Firewall Client. ISA Server offers one more option for seamless Internet access: SecureNAT. I covered SecureNAT in detail in "Authenticate Internet Access with ISA Server." Setting up the client machine to use SecureNAT is a snap: You use the TCP/IP settings on the client machine to point a default gateway of the client to the ISA Server machine. If you use DHCP to provide client configuration parameters, you can make the default gateway a DCHP scope option. In this case, the client will configure itself upon network start-up and thus will use ISA machine as its default gateway.
