ISA Server is Microsoft’s replacement for Proxy Server 2.0. However, it’s much more than just an upgrade. ISA Server is a complete remake of the old Proxy Server 2.0 product. In fact, ISA Server is Microsoft’s first serious entry into the firewall market. They have done a good job, as they were able to get International Computer Security Association (ICSA) certification less than a month after the release of the product. ISA Server is a true firewall and Web cache solution that integrates seamlessly into your Windows 2000 or Windows NT 4.0 environment. In this Daily Drill Down, I’ll show you how to configure the ISA Server clients. ISA Server supports the following client types:
- The SecureNAT client
- The Firewall Client
- The Web Proxy client
Each type of client has its own advantages and disadvantages and requires that you set up your network infrastructure in a slightly different way. Some of the client types are supported by all operating systems, and some are supported only by Microsoft operating systems.
Let’s take a look at the ISA Server client types and see how to install and configure each one to work with the ISA Server.
The SecureNAT client
ISA Server supports network address translation (NAT), which was not supported by Proxy Server 2.0. Microsoft included NAT client support in order to obtain ICSA certification, because one of the requirements for certification is that no client software be required.
The SecureNAT client is supported by all operating systems. There is no special software to install, and all you have to do to configure a machine to be a SecureNAT client is set its Default Gateway option to an IP address that routes to the internal interface of the ISA Server.
If the SecureNAT client is on the same logical subnet as the ISA Server, then you can set the client to use the IP address of the internal interface of the ISA Server as its Default Gateway. If the SecureNAT client is on a network remote from the internal interface of the ISA Server, then set the Default Gateway on the client to be a router interface that routes Internet-bound requests to the internal interface of the ISA Server.
If your internal network is routed, be sure the routers are configured to send Internet-bound packets to the ISA Server and not to drop packets destined for foreign networks.
DNS configuration for SecureNAT clients
In order for SecureNAT clients to resolve names for Internet hosts, you must configure the client to use a DNS server. The ISA Server will not resolve names on behalf of the SecureNAT client. There are a couple of ways you can configure your DNS infrastructure:
- Use DNS servers on the external network, such as your ISP’s DNS server.
- Configure DNS servers on your internal network to use a forwarder on the external network.
If you choose the first option, you need to make sure the SecureNAT clients have access to the external DNS server by configuring entries in both Protocol Rules and Site And Content Rules on the ISA Server. These rules allow clients to perform DNS queries. If you use the option to configure DNS servers to use a forwarder, you need to configure the internal DNS server to forward all DNS queries for domains for which it is not authoritative. Also, make sure that a Site And Content Rule and a Protocol Rule exist on the ISA Server that allow the internal DNS server to send DNS queries to the external DNS server.
Outbound access control for SecureNAT clients
One of the main reasons for implementing ISA Server is to control outbound access. You want to make sure internal users do not access unapproved content on the Internet. To accomplish this goal, configure Site And Content Rules and Protocol Rules. These rules determine who can access which content, at which time, using which protocols.
The SecureNAT client does not support outbound access controls by user and group memberships. The SecureNAT client does not send any authentication information to the ISA Server. The only way you can control access for SecureNAT clients is through IP addresses, which is done by configuring Client Address Sets on the ISA Server. You then limit access to SecureNAT clients through these Client Address Sets.
The fact that SecureNAT clients do not send authentication information to the ISA Server presents a problem if you require authentication for outbound Web requests. SecureNAT clients are able to access the HTTP protocol service and the Web Proxy service by having their requests go through the HTTP Redirector Application Filter. The HTTP Redirector Filter accepts HTTP requests from SecureNAT and Firewall Clients and passes them to the Web Proxy service.
About the HTTP Redirector Application Filter
The HTTP Redirector Application Filter is an application layer filter on the ISA Server that intercepts HTTP requests from SecureNAT and Firewall Clients. After intercepting the request, the filter can be configured to forward it to the Web Proxy service or forward the request directly to the Web server on the Internet. The filter can also be configured to drop requests from SecureNAT and Firewall Clients. The HTTP Redirector Application Filter allows non-Web Proxy clients to take advantage of features provided by the Web Proxy service, the most important being the Web Proxy Cache and Cache Arrays.
If you have configured rules limiting access by user or group to the HTTP protocol or to a particular site, then requests may fail for the SecureNAT client. The request fails because no authentication information is provided by the SecureNAT client and the HTTP Redirector is not able to forward any authentication information.
To prevent these failures, you need to create an anonymous access rule allowing access to the HTTP protocol and all Sites And Content. Note that there is no option for “anonymous” on the ISA Server. Allowing access to Everyone has the effect of allowing anonymous access. This solution is not ideal because it limits your ability to control outbound access for SecureNAT clients. The best solution is to configure the browsers on the SecureNAT clients to be Web Proxy clients, as you’ll see later in this Daily Drill Down.
Another important consideration regarding outbound access for the SecureNAT client is how it accesses protocols through the ISA Server. Often administrators configure the ISA Server to allow access to all protocols in order to test the ISA Server or to create an open-door policy for outbound access. For SecureNAT clients, all protocols means all protocols that have a Protocol Definition configured on the ISA Server. If there is no Protocol Definition, then the SecureNAT client will not be able to access the protocol, in spite of the fact that you have allowed access to All Protocols.
Configuring the SecureNAT client
The way the SecureNAT client is configured depends on which operating system the SecureNAT client is running. Generally, there are two ways to configure the Default Gateway for SecureNAT clients:
- By entering a Gateway Address on the DHCP server for DHCP clients
- By manually configuring the SecureNAT client’s TCP/IP properties
If you configure the DHCP server to deliver gateway information to DHCP clients, be sure that you have a scope entered for each subnet that has SecureNAT clients and ensure that you have configured a gateway address that is local within each scope.
To manually configure a SecureNAT client running Windows 2000, perform the following steps:
- Right-click My Network Places on the desktop and select Properties.
- In the resulting Network And Dial-Up Connections window, right-click the Local Area Connection icon and select Properties.
- Scroll through the Components Checked Are Used By This Connection list and double-click on the Internet Protocol (TCP/IP) entry. The Internet Protocol (TCP/IP) Properties dialog box will appear, as shown in Figure A.
- In the Internet Protocol (TCP/IP) Properties dialog box, type the IP address in the Default Gateway text box. Click OK.
After the SecureNAT client is configured with a Default Gateway, it is ready to connect to the Internet through the ISA Server.
|Add a Default Gateway to the Internet Protocol TCP/IP Properties dialog box.|
The Firewall Client
A firewall client is a machine that has the add-on Firewall Client software installed. Firewall Client software can be installed on all 32-bit Microsoft platforms. Unfortunately, this leaves Windows 3.x clients out. The Firewall Client software is the same as the Winsock Proxy software used in Proxy Server 2.0. In fact, if you have machines that already have the Winsock Proxy client software installed, you do not need to reinstall the Firewall Client software. The Winsock Proxy client and Firewall Client software are interchangeable.
The Firewall Client software replaces the native Winsock .dll files on the machine on which it is installed. Internet-bound requests are intercepted by the Firewall Client Winsock .dlls, and requests from Winsock applications are sent to the ISA Server.
Passing requests to the Firewall Client .dlls is transparent, and the Winsock applications “believe” that they are directly connected to the Internet. You do not need to configure a Default Gateway or DNS server for Firewall Client computers.
There are several advantages to configuring machines as Firewall Clients:
- They can send authentication information to the ISA Server for user/group-based access control.
- They can use all protocols, even those without a Protocol Definition configured on the ISA Server computer.
- They can manage complex protocols that require secondary connections without the help of an application filter.
- User names are included in the log files since authentication information is sent to the ISA Server.
All these advantages provide a compelling argument for implementing the Firewall Client software on any machine that supports it.
DNS considerations for the Firewall Client
Unlike the SecureNAT client, the Firewall Client does not require you to configure it with a DNS server entry. The ISA Server will perform DNS queries on behalf of the Firewall Client computer. You do not need to allow access for DNS queries for the Firewall Client because the ISA Server does all the work.
However, the issue becomes problematic if the Firewall Client computer must resolve host names for internal network servers. This is especially important in a Windows 2000 environment that is heavily dependent on DNS naming conventions. If you need to support host name resolution for internal resources, then you will have to configure the Firewall Client with an IP address of a DNS server on the internal network that can resolve internal host names.
The Firewall Client software will determine whether a name query request will be sent to the ISA Server or to the internal DNS server based on entries you have made in the Local Domain Table (LDT) on the ISA Server.
Installing the Firewall Client software
When ISA Server is installed, it creates and shares a folder that contains the Firewall Client installation files. There are several ways to access the client installation files:
- Type in the UNC path at the Run command.
- Use a Web browser to access the files.
- Use the Windows 2000 Group Policy Software management feature to assign or publish the Firewall Client installation files.
Let’s look at each of these installation procedures.
Accessing the Firewall Client software via a UNC path
To access the files through a UNC path, perform the following steps:
- Open the Run command on the client, type in the UNC path \\<isa_server_name>\mspclnt\setup.exe, and press [Enter].
- The installation wizard will walk you through the steps for installing the software.
A user must have permissions to install software on the machine that will contain the Firewall Client. Typically, this will be an administrator or power user on Windows 2000 or Windows NT 4.0 machines. Win9x machines have no security, so any user can install the software.
Accessing the Firewall Client software via a Web interface
If you wish to make the Firewall Client installation files available through a Web interface, you will have to make the files available on a Web server. You can do this by performing the following steps on a Windows 2000 machine running IIS 5.0:
- Copy the :\Program Files\Microsoft ISA Server\Clients directory on the ISA Server to another machine running IIS 5.0 on the internal network.
- At the IIS 5.0 machine, right-click on the Clients folder and click the Properties command. Then click on the Web Sharing tab, as seen in Figure B.
|Add a share in the Clients Properties dialog box.|
- Select the Share This Folder radio button and click Add. That brings up the Edit Alias dialog box, as seen in Figure C.
- Type the name you want users to use to access this Web folder in the Alias text box. For the Access Permissions, make sure only Read access is enabled. For Application Permissions, you can allow scripts to be executed. Click OK twice.
|Add a user name to the Edit Alias dialog box.|
I recommend that you copy the files to another machine on the internal network, as you should not run IIS on the ISA Server computer. Running IIS on the ISA Server would reduce its effectiveness as a Bastion Host on the edge of the network.
To access the installation files, users can open a browser and type in the URL http://<server_name>/<shared_firewall_client_folder>/WEBINST. Doing so will bring up a Web page that will walk you through the installation of the Firewall Client software.
Installing the Firewall Client through Group Policy
Perhaps the most convenient way to install the client software is to make it available through the Windows 2000 Group Policy Software Management application. For this to work, the clients will need to run Windows 2000 and be members of a Windows 2000 domain.
Avoid hours of end-user frustration
Do not assign the Firewall Client software to computers. The installation of the Firewall Client software takes place before the user logs on, and it has a tendency to take a very long time to complete. The problem is that the logon dialog box will not be available until the Firewall Client software has completed installing. This can prevent users from logging on for up to several hours!
When you publish the Firewall Client software to users, it will show up on the list of programs that can be installed from the network in the Add/Remove Software applet found in the Control Panel. Perform the following steps to publish software to users:
- Open the Active Directory Users And Computers console via the Administrative Tools menu. Right-click on the Organizational Unit (OU) to which you wish to publish the software and click Properties.
- Click on the Group Policy tab, click on the topmost Group Policy Object (GPO), and click the Edit button to open the GPO for editing.
- Expand the User Configuration node in the left pane, expand the Software Installation node, and right-click on it. Click the New command and then click on the Package command.
- Drill down to the location of the installation files. Click on the MS_FWC.MSI file and click Open. The Deploy Software dialog box appears, as seen in Figure D.
|Enable your software to be Published rather than Assigned.|
- In the Deploy Software dialog box, select the Published option and click OK.
- The Microsoft Firewall Client will now appear in the right pane of the GPO console.
- After completing the software installation steps, log on as a user in that GPO and open the Add/Remove Programs applet from the Control Panel. Click on the Add New Programs button in the left pane, and you will a screen similar to that shown in Figure E.
|Once ready to be deployed, the Microsoft Firewall Client appears in the Add/Remove Programs applet.|
After the Firewall Client software is installed, you can get to the business of configuring it.
Configuring Firewall Client
There are two ways you can configure the Firewall Client software:
- Through the GUI interface at the Firewall Client computer
- Through centralized configuration parameters set at the ISA Server computer
In this Daily Drill Down, we’ll take a look at how to configure the client through the GUI interface at the Firewall Client computer.
You can access the configuration interface either through the Firewall Client icon in the Control Panel, or you can right-click the Firewall Client icon in the tray and click the Configure command. The Firewall Client Options dialog box will appear, as shown in Figure F.
|Choose Enable Firewall Client and Automatically Detect ISA Server in the Firewall Client Options dialog box.|
The Enable Firewall Client option allows you to enable and disable the Firewall Client software. Note that on Windows 2000 clients, you do not need to restart the computer to disable or enable the Firewall Client, and the changes will take place within a short period of time. The option to Automatically Detect ISA Server allows the Firewall Client to use DNS or DHCP queries for wpad entries to find the address of the ISA Server and receive configuration information.
If you choose not to automatically detect the ISA Server, you can enter the name or IP address of the ISA Server in the Use This ISA Server text box. Confirm connectivity with the ISA Server by clicking on the Update Now button. If the Firewall Client successfully connects to the ISA Server, a message will appear informing you of that fact.
When the Show Firewall Client Icon On Taskbar option is enabled, a small icon will appear in the tray indicating that the Firewall Client software is communicating with the ISA Server. The Hide The Taskbar Icon When Connected option will cause the tray icon to disappear when the connection to the ISA Server is successful. When there is a problem with the connection, the icon will appear again.
The Web Proxy client
Web browsers that are CERN-compliant can be configured as Web Proxy clients. Since virtually all Web browsers produced in the last several years are CERN-compliant, it’s unlikely that you’ll find one that is not. These browsers can be configured to communicate with the Web Proxy service on the ISA Server. There are several advantages to configuring the browser as a Web Proxy client:
- Web Proxy clients are able to take advantage of hierarchical routing to a Web Proxy array.
- The Web Proxy client can take advantage of array fault tolerance.
- Web Proxy clients send authentication information to the Web Proxy service.
- HTTP performance is much faster when the browser is configured as a Web Proxy client.
One of the main advantages of the Web Proxy client is that it can be configured to download an Autoconfiguration script, which allows the clients to resolve the location of a Web page within an array.
ISA Server supports a distributed caching model using a Web caching protocol known as Caching Array Routing Protocol (CARP). Members of a CARP array split the total URL space among themselves so that any URL that might be requested is automatically assigned, in advance, to a particular member of the array. If the Web browser is configured as a Web Proxy client, it will be able to resolve the URL to an array member and send the request directly to that member. If the browser is not configured as a Web Proxy client, the requests will have to be resolved within the array, and then the Web pages are returned to the client after the request is resolved.
An Autoconfiguration script allows the Web Proxy client to take advantage of fault tolerance for Web Proxy arrays. The script contains information about active members in the array. If one of the array members should go offline, the Web Proxy client will have a list of other array members it can contact to send its requests.
When you configure the browser to be a Web Proxy client, you can have authentication by user or group for Web access and run the machine as a SecureNAT or Firewall Client. If you do not configure the Web browser as a Web Proxy client on SecureNAT and Firewall Client machines, requests for Web access that require authentication may fail.
Why would requests fail? These requests go through the HTTP Redirector Application Filter. The SecureNAT client does not send authentication information, so this does not present an issue for it, but the Firewall Client does send authentication information to the ISA Server. However, when the HTTP Redirector Application Filter forwards the request to the Web Proxy service, the authentication information is lost.
Use Web Proxy clients
Whether you configure the ISA Server client as a Firewall or SecureNAT client, you should always configure the browsers as Web Proxy clients. There are many advantages and no disadvantages to doing so. There is no operating system limitation because CERN-compliant browsers are made for all platforms.
Web performance is greatly improved when you configure the browsers to be Web Proxy clients because they communicate directly with the Web Proxy service. If you do not configure the browsers, the requests are sent to the Firewall service on the ISA Server, which then sends the request through the HTTP Redirector Application Filter. This takes additional processor cycles and is not as efficient as sending the request directly to the Web Proxy service.
Configuring the Web Proxy client
The way you configure the browser to be a Web Proxy client depends on what browser you use. In this example, we’ll configure IE 5.x. The configuration interface will be similar for other versions of Internet Explorer.
- Open the browser, click the Tools menu, and click the Internet Options command.
- In the Internet Options dialog box, click on the Connections tab. Now click the LAN Settings button.
- On the Local Area Network (LAN) Settings dialog box (Figure G), configure the browser to be a Web Proxy client.
|Set your browser to be a Web Proxy client in the Local Area Network (LAN) Settings dialog box.|
The Automatically Detect Settings option allows the Web browser to obtain configuration information by querying a DNS or DHCP server that has been configured to provide this information. The option Use Automatic Configuration Script allows you to put in a URL that the browser can contact to obtain the Autoconfiguration script for an array. The URL format is:
By default, the ISA Server listens for Web Proxy client requests on port 8080 on the internal interface. You can change this default listening port on the ISA Server.
If you wish to manually configure the Web browser, place a checkmark next to Use A Proxy Server and then type the URL and port number in the text boxes.
The option Bypass Proxy Server For Local Addresses allows the Web Proxy client to use its own DNS server to resolve requests for internal addresses. Normally, any requests that contain “dots” are treated as requests for external resources, and the ISA Server performs name resolution. However, you may wish to use addresses with “dots” to access internal network resources and have internal DNS servers perform name resolution. To do this, you can configure entries in the Local Domain Table (LDT) on the ISA Server or you can configure addresses in the Web browser.
To configure local addresses, click the Advanced button. You will see the Proxy Settings dialog box, shown in Figure H.
|Add your Proxy Server’s address to the advanced Proxy Settings dialog box.|
Type in the address of the server. Note that you can only configure the local addresses as determined by the leftmost component of the Fully Qualified Domain Name. While you can use wildcards, such as www.*.com, or 192.*.*, you cannot configure your entire domain from this interface. You will have to configure the LDT on the ISA Server to accomplish that task.
In this Daily Drill Down, you learned about ISA Server client installation and configuration. You saw that there are three types of clients supported by ISA Server: the SecureNAT client, the Firewall Client, and the Web Proxy client. We discussed the advantages and disadvantages of each type of client and how to install and configure each client. Taking this information, you will be able to get ISA Server clients up and running on your network and connect them to your ISA Server.