Server Publishing

Server publishing rules allow you to publish almost any type of server protocol. As noted earlier, server publishing rules essentially perform a reverse NAT that allows the ISA server to accept packets on a certain IP address and port number and forward them to the same port number to an IP address on the internal network. While server publishing rules do not allow the ISA server to examine the data portion of the communication on their own, "smart" application filters can be applied to protect communications forwarded by server publishing rules.

In this section, look at how to publish the following services:

• Terminal Services

• Terminal Services Advanced Client (TSAC) Sites

• FTP Servers

• HTTP and HTTPS Servers

• VNC Servers

• pcAnywhere Servers

Publishing Terminal Services on the Internal Network

Publishing a Terminal server on the internal network is relatively straightforward. All you need is a protocol definition with Primary Connection set for Inbound TCP 3389, and a server publishing rule that uses this protocol definition. The only thing that can interfere with Terminal Server publishing rules is port contention. The best way to eliminate the Terminal Services port contention is to disable Terminal Services on the ISA server. However, most of us want to run Terminal Services on the ISA server to ease server administration, so we'll go over how to run Terminal Services on the ISA server and publish an internal network Terminal server at the same time later in this chapter.

Let's begin with how to publish Terminal Services on an internal network server when Terminal Services is not running on the ISA server. Perform the following steps to publish a Terminal server:

1. Open the ISA Management console. Expand your server name and then expand the Policy Elements node.

2. Right-click on the Protocol Definitions node, point to New, and click Definition.

3. On the Welcome to the New Protocol Definition Wizard page, type RDP Server for the Protocol Definition name and click Next.

4. On the Primary Connection Information page, type 3389 for the Port number and change the Direction to Inbound. Click Next.

5. The Remote Desktop Protocol (RDP) does not use secondary connections, so select No and click Next.

6. Click Finish on the Complete the New Protocol Definition Wizard page.

7. Expand the Publishing node in the left pane of the ISA Management console. Right-click on Server Publishing Rules, point to New, and click Rule.

8. On the Welcome to the New Server Publishing Rule Wizard page, type Terminal Server 1 in the Server publishing rule name text box and click Next.

9. On the Address Mapping page, enter the IP address of the Terminal Server on the internal network in the IP address of internal server text box. Click Browse and select the IP address on the external interface of the ISA server you want to listen for Terminal Services requests. Click Next.

10. On the Protocol Settings page, select the RDP Server protocol definition. Note that protocol definitions with a primary connection as inbound are shown here. No protocol definitions with a primary connection as outbound will show up here. Click Next.

11. On the Client Type page, decide whether you want to allow all external hosts to connect to the Terminal server, or if you want to limit access to hosts contained in a client address set. You should limit the number of hosts that can connect to the Terminal server via the RDP server publishing rule. Note that you must enable packet filtering in order to apply a client address set to control what computers can access the server publishing rule. Packet filtering is enabled by default, but you might need to double check to ensure that it's still enabled. Select the Client address sets specified below option and click Next (Figure 27.5).

    
    Figure 27.5: Selecting the Client Address Sets Option on the Client Type Page

12. On the Add Client Sets page, click Add. Select the client address set you created for Terminal Services clients and click Add. The client address set will appear in the Include these sets frame. Click OK (Figure 27.6).

    
    Figure 27.6: Selecting the Client Address Set

13. Click Next on the Client Sets page.

14. Click Finish on the Complete the New Server Publishing Rule Wizard page.

Now go to a machine configured as an external network client and connect to the Terminal server by using the external IP address on the ISA server used by the RDP publishing rule. After establishing the connection, check the name of the server you connected to by right-clicking on the My Computer icon and then clicking the Properties command. Click the Network Identification tab. If you see the name of the ISA server instead of the internal network server, you forgot to disable Terminal Services on the ISA server! Disable Terminal Services on the ISA server, restart the computer, and try again.

Publishing Terminal Services on an Alternate Port

You have to be careful about publishing Terminal Services. If intruders are able to connect to a Terminal server, they'll have a powerful launch point for subsequent attacks. You've already seen how you can limit access to a few selected Terminal Services clients on the Internet by applying a client address set to the RDP server publishing rule. Using client address sets is a good start, but there's more that you can do to secure your Terminal Services publishing rule.

Since TCP port 3389 is a well-known port, and Terminal Services is an attractive service to attack, you might want to impede Internet criminals by changing the port number used by Terminal Services. You can change the listening port number to any unused port number on the ISA server's external interface, and then publish the Terminal Server on that alternate port. In order to do so, you'll have to make a Registry change at the Terminal Server and then change the port number that the Terminal Services client uses to call the Terminal Server.

If you use the new Remote Desktop Client software to connect to a Terminal Server, you don't need to make any changes on the client side. All you need to do is include the port number in the address you're calling. For example, if you want to call a published Terminal Server at 1.1.1.1 and that Terminal Server is listening on TCP port 58927, just enter the address 1.1.1.1:58927 on the Remote Desktop Client and it will make the connection. It's not quite this easy with the original Windows 2000 or Windows NT 4.0 Terminal Services client software.

Note

You can obtain the Remote Desktop Client software for various operating systems at the following URLs:

• Windows www.microsoft.com/windowsxp/pro/downloads/rdclinetdl.asp

• Macintosh www.microsoft.com/mac/download/misc/rdc.asp

• Linux and UNIX www.rdesktop.org

Perform the following steps to change the listening port for the Windows NT 4.0 Terminal Services Edition Terminal Server and the Windows 2000 Terminal Server. These steps should be performed on the Terminal Server you're publishing on the internal network. However, you can also change the listening port for the Terminal Server on the ISA server using the same procedure:

1. Click Start and then click Run. Type regedt32 in the Open text box and click OK.

2. Navigate to the following key: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\TerminalServer\WinStations\RDP-Tcp

3. Find the PortNumber value in the right pane and double-click it.

4. In the DWORD Editor dialog box, select the Decimal option. Change the port number to something else. In this example, we'll change it to 64646. Click OK.

5. Restart the Terminal Server computer.

Perform the following steps to create the new RDP server protocol definition:

1. Open the ISA Management console. Expand your server name and then expand the Policy Elements node.

2. Right-click on the Protocol Definitions node, point to New, and click Definition.

3. On the Welcome to the New Protocol Definition Wizard page, type RDP Server 64646 for the Protocol Definition name and click Next.

4. On the Primary Connection Information page, type 64646 for the Port number and change the Direction to Inbound. Click Next.

5. RDP does not use secondary connections, so select No and click Next.

6. Click Finish on the Complete the New Protocol Definition Wizard page.

Perform the following steps to create the server publishing rule to publish the Terminal Server on the alternate port:

1. Expand the Publishing node in the left pane of the ISA Management console. Right-click on Server Publishing Rules, point to New, and click Rule.

2. On the Welcome to the New Server Publishing Rule Wizard page, type Terminal Server 2 in the Server publishing rule name text box and click Next.

3. On the Address Mapping page, type in the IP address of the Terminal Server on the internal network in the IP address of internal server text box. Click Browse and select the IP address on the external interface of the ISA server that you want it to listen on for Terminal Services requests. Click Next.

4. On the Protocol Settings page, select the RDP Server 64646 protocol definition. Click Next.

5. On the Client Type page, select the appropriate client type. In this example, we'll select Any request, but you should use a client address set in your production environment.

6. Click Finish on the Complete the New Server Publishing Rule Wizard page.

The last step is to configure the Terminal Services client to use the alternate port number:

1. Click Start | Programs. Point to Terminal Services Client and click Client Connection Manager.

2. In the Client Connection Manager, click File | New Connection. Go through the steps in the wizard to create a connection object for your published Terminal Server. Remember to use the IP address or FQDN that resolves to the external IP address on the ISA server that's publishing the Terminal Server.

3. Click on the icon for the connection in the Client Connection Manager window, and then click File | Export. Give the connection a name and save it on your desktop.

4. Right-click the Terminal Services client connection object on the desktop and click the Open With command. Select Notepad from the list of applications. If you are using a Win9x client, you'll have to open Notepad and open the connection object within Notepad.

5. In Notepad, find the Server Port= entry and change it to the port number you're using to publish your Terminal Server. Save the file and close Notepad.

6. Drag the icon on the desktop onto the Client Connection Manager window. A Client Connection Manager dialog box will appear and ask if you want to replace the connection object with the new one. Click Yes. A Client Connection Manager dialog box appears and asks if you want to replace the connection settings for all duplicates. Click No.

7. Double-click on the connection object in the Client Connection Manager window. Log on and confirm that you're connected to the correct server. Go to the ISA Server computer and run netstat –na. You'll see an active connection to the alternate RDP server port used in the new server publishing rule.

Publishing Terminal Services on the ISA Server

Publishing services on the ISA server is always problematic. Your goal should be to run as few services as possible on the ISA Server computer. However, running Terminal Services on the ISA server is acceptable because you can create secure connections to the Terminal Server, and Terminal Services provides the best way to remotely manage an ISA server. We consider Terminal Services as secure as an SSL Web-based remote management solution.

You almost always have two options when publishing services on the ISA server itself. The easiest method is to create a packet filter so that external network clients can connect directly to the services via the external interface. The other way is to use a server publishing rule. The latter option can be used if you can configure the service to listen only on an IP address or set of addresses on the internal interface.

Note

Although you can always "publish" services that are on the ISA server itself by creating packet filters, the packet filter approach prevents you from using server publishing rules to publish services on the internal network using the same socket. Remember that a socket is the combination of an IP address, a protocol (TCP or UDP), and a port number. For example, if you create a packet filter to publish the Terminal server on the ISA server on 1.1.1.1 TCP port 3389, you will not be able to use 1.1.1.1 TCP port 3389 to publish a Terminal server on the internal network.

The Windows Terminal Server listens on all interfaces by default. This is similar to how the IIS socket-pooling feature works. Like the IIS socket pooling feature, you can configure it so that Terminal Services does not listen on all interfaces. Although you can choose what interface Terminal Services listens on, you cannot choose a specific IP address on the interface. If there are multiple IP addresses bound to the interface, Terminal Services will listen on all of them. This is an important consideration when you bind multiple addresses to the internal or external interface of the ISA server.

Publishing Terminal Services on the ISA Server Using Packet Filters

Let's look at how to publish Terminal Services using simple ISA Server packet filters:

1. Click Start | Programs Administrative Tools | Terminal Services Configuration.

2. In the Terminal Services Configuration console, click on the Connections node in the left pane of the console. In the right pane of the console, Double-click on the RDP-Tcp entry.

3. Click on the Network Adapter tab. Click the Down arrow in the Network adapter drop-down list box. Notice that the default is All network adapters configured with this protocol. You can also choose a specific adapter. The adapters are listed by the adapter manufacturer's name rather than the name you give to the interface in the Network and Dial-up Connections window. When publishing the Terminal Server on the ISA server using packet filters, you can allow the Terminal Server to listen on all interfaces. By doing it this way, you won't have to loop back through the external interface to access the Terminal Server from an internal network client. However, if you plan to publish the Terminal Server by using server publishing rules, you'll need to configure Terminal Services to listen only on the internal interface (Figure 27.7).

   
   Figure 27.7: Configuring Terminal Services to Listen on the Internal Interface

4. Open the ISA Management console. Expand your server name, and then expand the Access Policy node.

5. Right-click on the IP Packet Filters node, point to New | Filter.

6. On the Welcome to the New IP Packet Filter Wizard page, type RDP (in) in the IP packet filter name text box and click Next.

7. On the Filter Mode page, select the Allow packet transmission option and click Next.

8. On the Filter Type page, select the Custom option and click Next.

9. On the Filter Settings page, choose TCP for the IP protocol. Choose Inbound for the Direction. Choose Fixed port for the Local port and make the Port number value 3389. For the Remote port, select All ports (Figure 27.8). Click Next.

   
   Figure 27.8: Configuring the RDP Packet Filter

10. On the Local Computer page, select the option that best fits your situation. The Default IP addresses for each external interface on the ISA Server computer sets the filter to listen on the external interface's primary IP address. If you have multiple IP addresses bound to the external interface, you can choose the This ISA Server's external IP address option and type in the IP address to which you want the filter to apply. Make a selection and click Next.

11. On the Remote Computers page, select the All remote computers option and click Next.

12. Click Finish on the Completing the New IP Packet Wizard page.

Now try to connect to the Terminal Server from an external network client. You'll be able to connect directly to the external interface of the ISA server.

Note

You might be concerned about allowing a direct connection using a packet filter. As a result, you might believe that you will achieve a higher level of security by using a server publishing rule. However, this is misleading. Remember that server publishing rules do not expose the application-layer data to the Firewall service, unlike when using Web publishing rules. Since there are no application filters that will examine the RDP connections, a server publishing rule doesn't necessarily provide a higher level of security

Some of you might be concerned about allowing a direct connection using a packet filter. You might believe that you will achieve a higher level of security by using a server publishing rule—which is incorrect. Remember that server publishing rules do not expose the application-layer data to the Firewall service, unlike when using Web publishing rules. Since there are no application filters that will examine the RDP connections, a server publishing rule doesn't necessarily provide a higher level of security

The primary advantage of using a server publishing rule to publish Terminal Services on the ISA server is that it allows you to apply a client address set to control inbound access to the rule. While this doesn't protect the data stream, it's important that you limit who can connect to the Terminal server. For this reason, we recommend using server publishing rules to publish the Terminal server on the ISA server.

Publishing Terminal Services on Both the ISA Server and Internal Network

Many ISA Server administrators need to publish the Terminal Server on the ISA Server machine and allow access to Terminal Servers on the internal network. There are several methods that you can use to allow access to the Terminal Server on the ISA server and to machines on the internal network:

• Use server publishing rules to publish all Terminal Servers.

• Use packet filters to publish the Terminal Server on the ISA server, and server publishing rules to publish the servers on the internal network.

• Publish the Terminal Server on the ISA server using server publishing rules or packet filters, and then access the other Terminal Servers on the internal network by running the Terminal Services client inside the Terminal Services session on the ISA server.

Any of these techniques will work. If you have a single IP address bound to the external interface of the ISA server, then you can create only one server publishing rule or packet filter. Other Terminal Services sessions will have to use alternate port numbers, using the methods described earlier in this chapter.

For example, suppose you have two Terminal Servers on the internal network and you are also running Terminal Services on the ISA server. You want to be able to access all of these Terminal Servers from the Internet. If you need Terminal Services access for only administrative purposes, you can publish the Terminal Server on the ISA server with the default port number (TCP 3389) and then use alternate port numbers for the other servers on the internal network.

No matter what method you choose, keep in mind that the limiting factor is port contention. You can publish as many Terminal Servers as you like, as long as you don't create a port contention condition on the external interface of the ISA server.

Publishing TSAC Sites

The Terminal Services Advanced Client (TSAC) provides a way for your users to access a Terminal Server using a Web browser interface. The Web interface allows you to connect to a Terminal Server without already having the Terminal Services or Remote Desktop Client already installed on the client machine. This allows users who haven't installed the client software to access the Terminal Server.

The TSAC software must first be installed on a Web server on the internal network. You can install the software on any Web server on your internal or external network (DMZ). There is no relationship between the physical location of the Web server hosting the TSAC site and the Terminal Server or servers to which users connect. After users connect to the TSAC Web site, they are offered the opportunity to install the TSAC ActiveX control. After installing the ActiveX control, the user enters the name of the Terminal Server to which he or she wants to connect.

Note

This brings up a common area of confusion for ISA Server administrators. When users enter the name of the Terminal Server in the TSAC logon form, they must enter a name or IP address that is valid on the external network. The Terminal Services client connection is established via the IP address on the external interface of the ISA server used by the RDP server publishing rule publishing the Terminal Server. Users and administrators often enter the internal name of the Terminal Server and discover that the connection fails. You must use a name or IP address that resolves to the public IP address on the external interface of the ISA server that matches the address used in the RDP server publishing rule.

Do the following to publish a TSAC site:

1. Install the TSAC software on the Web server.

2. Publish the TSAC Web server.

3. Publish the Terminal Server(s).

4. Connect to the TSAC Web site and then connect to the Terminal Server.

Installing the TSAC Software on the Web Server

Perform the following steps to install the TSAC Web software on a server on the internal network:

1. Open Internet Explorer and go to www.microsoft.com/windowsxp/pro/ downloads/rdwebconn.asp. Select the appropriate language for your site and click GO.

2. On the File Download page, select the Save this program to disk option, and click OK.

3. Save the tswebsetup file to the desktop, and click Save in the Save As dialog box.

4. Click Open in the Download Complete dialog box.

5. On the Remote Desktop Web Connection Setup dialog box, click Yes to install the package.

6. Read the license information and then click Yes to agree to the license.

7. A dialog box appears showing the default path in the wwwroot folder where the TSAC Web connection files are stored. You can change the path here. Click OK to continue.

8. An information dialog box appears asking if you want to read the release notes. Click Yes to read the notes. You'll notice that this is the TSAC Web package that's included with Windows XP.

Publishing the TSAC Web Server

You publish the TSAC Web server in the same way you publish any other Web server. You can even publish the TSAC site as an SSL site to make the connection secure. You'll want to use SSL if you require authentication to access the TSAC Web site. If you do publish the TSAC Web site as an SSL site, we recommend that you use only basic authentication to allow the widest range of clients to access the site and have fewer compatibility issues. You don't have to worry about credentials being passed in clear-text over the Internet, because SSL encryption hides the username and passwords. In this example, we'll publish a TSAC site that allows access to domain admins over a plain HTTP connection. Later in this chapter, we'll review procedures for publishing SSL sites.

The TSAC site can be published using either Web or server publishing rules. In this example, we'll use Web publishing rules because they allow a higher level of security than server publishing rules do.

Perform the following steps to publish the TSAC site:

1. Open the ISA Management console. Expand your server name and then expand the Policy Elements node. Right-click on the Destination Sets node, point to New, and click Set.

2. In the New Destination Set dialog box (Figure 27.9), type TSAC Web in the Name text box. Type in a description—for example, Destination Set for the TSAC Web site—in the Description text box. Click Add.

   
   Figure 27.9: Creating the TSAC Destination Set

3. In the Add/Edit Destination dialog box, enter the FQDN that external network users will use to access the TSAC Web site (Figure 27.10). This FQDN must resolve to the IP address you are using for the Incoming Web Requests listener that will accept requests for the TSAC Web site. This is not the name of the server on the internal network. In the Path text box, enter /tsweb*. The Web Proxy service uses this path to redirect the request to the appropriate Web server on the internal network. The wildcard at the end of the path indicates that requests for the tsweb folder and all subfolders of the tsweb folder will be accessible via this set. Be aware that users will need to type in the full path, including /tsweb. ISA Server will not allow you to redirect from one path to another. Whatever path is included in the URL the external users send in the request must be available on the destination TSAC server on the internal network. Click OK.

   
   Figure 27.10: Entering the FQDN and Path for the Destination Set

4. Click OK in the New Destination Set dialog box.

As is the case for all publishing rules, you must be sure to include an entry in your public DNS that resolves the FQDN used in the destination set. In our current example, we would put an entry for tsweb.internal.net in our public DNS. You should also consider putting the same entry in your private DNS if you want the site accessible to internal and external network clients. If you do, make sure you have configured a split DNS infrastructure. You can get more information on configuring a split DNS infrastructure at www.isaserver.org/pages/ article.asp?id=995.

Now that the destination set is in place, you can create the Web publishing rule:

6. Open the ISA Management console and expand your server name. Expand the Publishing node and right-click on the Web Publishing Rules node. Point to New and click Rule.

7. On the Welcome to the New Web Publishing Rule Wizard page, type in the name of the rule in the Web Publishing rule name text box. In this example, we'll call the rule TSAC Web site. Click Next.

8. On the Destination Sets page (Figure 27.11), select the destination set you created for the TSAC Web site. Click Next.

   
   Figure 27.11: Selecting the TSAC Site Destination Set

9. On the Client Type page, select the client type appropriate for your organization. If you want everyone to access the site, select Any request. You can limit access to specific computers using a client address set by selecting Specific computer (client address sets) and assigning a client address set. This would be most useful if you wanted to restrict access to a particular partner, or limit access to a group of administrators. You can also control access to this site with user/group-based authentication by selecting the Specific users and groups option. Users will need to enter credentials and authenticate with the ISA server before they access the site when you select this option. The users do not authenticate with the TSAC Web server. This allows you to offload authentication processing from the Web server to the ISA server. In this example, we'll enforce security by limiting access to the rule by specific users and groups. Select the Specific users and groups option and click Next.

10. In the Users and Group dialog box (Figure 27.12), click Add. Select the user or group you want to have access to this Web publishing rule. In this example, we'll select the Domain Admins group. Click OK and then click Next in the Users and Groups dialog box.

    
    Figure 27.12: Configuring Authentication Requirements for the Web Publishing Rule

11. In the Rule Action dialog box, select the Redirect the request to this internal Web server (name or IP address) option. Then, type in the name of the server on the internal network. In this example, we will use the same name the user on the external network uses to access the server. This allows the same name to appear in the Web Proxy logs and makes analysis of the Web Proxy logs much easier, as the redirect is to the same name the user is accessing via the browser. If you use the same domain name for internal and external resources, you can create a split DNS infrastructure. If you do not want to, or cannot, create a split DNS infrastructure, you can use a HOSTS file on the ISA server and map the name you use for the redirect to the server on the internal network. For example, we will redirect the request to tsac.internal.net. This is the same name the external users use to access the server and in this example it resolves to 192.168.1.33 on the external interface of the ISA server. When the ISA server redirects the request, it will resolve tsac.internal.net to 10.0.0.2 because we put an entry in the HOSTS file on the ISA server to map tsac.internal.net to the internal IP address for the server. When you do it this way, you don't have to worry about sending the original host header to the server, because the host header won't be changed! Click Next to continue.

12. Click Finish on the final page of the wizard to complete the rule.

When users access the published TSAC Web site, they'll be asked for credentials.

Publishing the Terminal Server

The next step is to publish the Terminal Server. Remember that if you are running Terminal Services on the ISA server, you need to either disable Terminal Services, or configure the Terminal server to listen only on the internal interface. If you don't, you'll end up with port contention after creating the server publishing rule.

Perform the following steps to publish a Terminal Server:

1. Open the ISA Management console. Expand your server name and then expand the Policy Elements node.

2. Right-click on the Protocol Definitions node, point to New, and click Definition.

3. On the Welcome to the New Protocol Definition Wizard page, type RDP Server for the Protocol Definition name and click Next.

4. On the Primary Connection Information page, type 3389 for the Port number and change the Direction to Inbound. Click Next.

5. The RDP does not use secondary connections, so select No and click Next.

6. Click Finish on the Complete the New Protocol Definition Wizard page.

7. Expand the Publishing node in the left pane of the ISA Management console. Right-click on Server Publishing Rules, point to New, and click Rule.

8. On the Welcome to the New Server Publishing Rule Wizard page, type TSAC Terminal Server in the Server publishing rule name text box and click Next.

9. On the Address Mapping page, type in the IP address of the Terminal server on the internal network in the IP address of internal server text box. Click Browse and select the IP address on the external interface of the ISA server that you want it to listen on for Terminal Services requests. Note that the external IP address does not have to be the same as the one you used for your Incoming Web Requests listener, and the internal server does not have to be the same server as the Web server publishing the TSAC Web site. The TSAC Web site connection and the Terminal Services client connection are two completely different sessions. Click Next.

10. On the Protocol Settings page, select the RDP Server protocol definition. Note that protocol definitions with a primary connection set as inbound are shown here. No protocol definitions with a primary connection as outbound will show up. Click Next.

11. On the Client Type page, decide whether you want to allow all external hosts to connect to the Terminal Server, or if you want to limit access to hosts contained in a client address set. For security reasons, you should limit which hosts can connect to the Terminal Server via the RDP server publishing rule. Note that in order to control what computer can access the server publishing rule, you'll have to enable packet filtering. Packet filtering is enabled by default, but you should double check to ensure that it hasn't been disabled. Select the Client address sets specified below option and click Next.

12. On the Client Sets page, click Add. Select the client address set you created for the Terminal Services clients and click Add. If you haven't created a client address set for users who need access to the Terminal Server, you'll need to back out of the Server Publishing Rule Wizard and create the client address set. If the Terminal Server you're publishing will be accessed by users with dynamic addresses assigned to them, you will not be able to use client address sets for access control. The client address set will appear in the Include these sets frame. Click OK.

13. Click Next on the Client Sets page.

14. Click Finish on the Completing the New Server Publishing Rule Wizard page.

Connecting to the TSAC Web Site and the Terminal Server

You can now connect to the TSAC Site and Terminal Server using Internet Explorer. Go to an external network client and perform the following steps:

1. On the external network client, open Internet Explorer. Type the FQDN and path to the Terminal Services Web site. In our example, we'll type http://tsac.internal.net.

2. You will need to authenticate against the ISA server to access the TSAC Web site. We configured the Web publishing rule so that only authenticated users can access the TSAC Web site. Enter your credentials into the logon dialog box (Figure 27.13), and click OK.

   
   Figure 27.13: Entering Credentials to Access the TSAC Web Site

3. After you successfully authenticate, the TSAC Web page appears and then the Security Warning dialog box pops up asking if you want to install the Remote Desktop ActiveX Control (Figure 27.14). Note that if the Web browser is configured to block ActiveX controls, the TSAC client software will not work. Click Yes to install the client software.

   
   Figure 27.14: The Security Warning Dialog Box

4. The client software installs, but it won't give you any indication of when installation was complete. Give it a few seconds to finish installation, and then type in an FQDN that resolves to the IP address on the external interface of the ISA server you used in the TSAC Web server publishing rule. You can also enter the public IP address. If the external IP address you used in the server publishing rule is the same IP address used by the Incoming Web Requests listener for the Web publishing rule used to access the TSAC Web site, users can type in the same FQDN they used to access the Web site in the Server text box. Select the size of the display and click Connect (Figure 27.15).

   
   Figure 27.15: The Remote Desktop Web Connection Page

5. Once you connect, a Terminal Service session runs within the browser window. If you connected using the Full Screen option, you'll see something like what appears in Figure 27.16. Figure 27.17 shows the Terminal Services session as it appears in the browser window.

   
   Figure 27.16: The TSAC Terminal Services Session Running in Full Screen Mode

   
   Figure 27.17: The Terminal Services Session as It Appears in the Browser

Some things to keep in mind when publishing TSAC sites:

• You can publish multiple Terminal Servers and allow users to access all of them from the same TSAC Web page.

• If you want to publish multiple Terminal Servers, you will need a separate IP address for each. Each Terminal Services publishing rule uses one IP address.

• The Terminal Server does not need to be on the same machine as the TSAC Web site.

• The name or IP address the user enters on the TSAC Web page is the name or IP address used to connect to the external IP address on the ISA server used in the Terminal Server's server publishing rule(s).

• Make sure you avoid port contention on the external interface of the ISA server. Either disable Terminal Services on the ISA server or configure it to listen only on the internal interface.

Publishing TSAC Sites on an Alternate Port

As you learned earlier in this chapter, it might be a good security measure to publish the Terminal Server on an alternate port. In the same way, it might be a good security move to publish the Terminal Servers that users access via the TSAC Web site on alternate ports.

The problem is that if you publish the Terminal Server on an alternate port, you cannot enter the port number in the Server text box on the TSAC Web page. For example, you might think that if you enter tsac.internal.net:12345 into the Server text box, the RDP request would be directed to TCP port 12345. Unfortunately, this is not the case. The TSAC RDP client ActiveX control will sends requests to TCP port 3389, which is the default RDP server port number.

There is a hack you can use if you don't use the latest TSAC Web software. This requires you to copy the TSWeb files from a Windows XP computer that is pre-Windows XP Service Pack 1. After you copy those files to the Windows Terminal Server, you can then make a change to the connect.asp file in the TSWeb folder. This change allows the TSAC Web client ActiveX control to send requests to the alternate port number.

While this does work, you might run into major problems if you implement this solution. Microsoft issued a Security Alert regarding a buffer overflow problem with the old TSAC Web client ActiveX control. The fix was to install the patch noted in MS02-046 (www.microsoft.com/technet/treeview/default.asp?url=/technet/security/bulletin/MS02-046.asp). After installing the patch, users could no longer connect to the old TSAC Web site. You have to upgrade to the current TSAC Web site software to allow the post-fix clients to connect. After you upgrade the TSAC Web server files, your alternate port settings disappear and you cannot regain them.

Until this situation is changed, using an alternate port to connect to a Terminal Server via the TSAC Web site is a moot point. We'll keep you updated on this situation if it changes. Make sure to check www.isaserver.org/shinder on a regular basis to read up on ISA Server updates.

Publishing FTP Servers on the Internal Network

We get many questions at ISAServer.org regarding FTP server publishing. FTP server publishing is done the same way as other forms of server publishing. There is one important difference between publishing FTP servers and publishing another protocol, such as SMTP. That is that in order to fully support the FTP protocol, the FTP server publishing rules must be able to leverage the FTP protocol definitions created by the ISA server's FTP access application filter.

SMTP is a simple protocol that only requires access to a single TCP port. PORT mode FTP, however, is a complex protocol, where the FTP server must be able to create new outbound connections to the FTP client. Information about the new connection must be tracked by the firewall, and the only way the ISA server can track these secondary connections is with the help of the FTP access application filter.

The FTP access application filter monitors communication between the publishing FTP server and the FTP client on the Internet. When the FTP client on the Internet sends a PORT command to the publishing FTP server, the ISA server intercepts this information and manages opening and closing the appropriate ports. However, in order to do its job correctly, the ISA server needs to use the FTP server protocol definitions created by the application filter. This protocol definition "hooks into" the FTP access application filter and allows the rule to leverage the intelligence built into the filter.

Perform the following steps to publish an FTP server on the internal network:

1. Open the ISA Management console. Expand your server name and then expand the Publishing node. Right-click the Server Publishing node, point to New, and click Rule.

2. On the Welcome to the New Server Publishing Rule Wizard page, type in a name for the rule in the Server publishing rule name text box. Click Next.

3. On the Address Mapping page (Figure 27.18), type in the IP address of the internal network FTP server in the IP address of the internal server text box. Type the IP address on the external interface of the ISA server that you want to listen for the FTP requests in the External IP address on ISA Server text box. Click Next.

   
   Figure 27.18: The Address Mapping Page

4. On the Protocol Settings page, select the FTP Server protocol in the Apply the rule to this protocol drop-down list box. Click Next.

5. On the Client Type page, select either Any request or Specific computers depending on your requirement. Click Next.

6. Click Finish on the Complete the New Server Publishing Rule Wizard.

7. The FTP server needs access to all sites because it needs to make a new outbound connection to the FTP clients sending the inbound request. Create a client address set that contains the IP address of the FTP server, and then create a site and content rule that allows the FTP server access to all sites and content.

8. Make sure the FTP server is configured as a SecureNAT client. The most common reason for the publishing rule to fail is that the administrator forgot to configure the server as a SecureNAT client.

You will be able to connect to the FTP server after you complete the FTP server publishing rule. The publishing server supports both PORT and PASV mode connections because the FTP Server protocol definition plugs into the FTP access application filter. Go to the Protocol Definitions node in the ISA Management console and you'll see that the FTP Server protocol definition is defined by an Application Filter. If you disable the FTP Access application filter, these FTP protocol definitions won't work.

It's difficult to make a mistake when publishing FTP sites. However, there do appear to be problems with publishing FTP sites on secondary IP addresses on the external interface of the ISA server. For example, if you have two IP addresses bound to the external interface of the ISA server, and you publish an FTP site on the internal network using a secondary IP address bound to the external interface, the publishing rule might not work.

However, this problem was corrected with ISA Server Service Pack 1, and you should not have this issue after installing the service pack. If you have problems publishing FTP sites on secondary addresses, make sure that ISA Server Service Pack 1 is installed. If it isn't, reinstall the service pack.

Note

Although not directly connected to FTP server publishing, there is a problem with PASV mode FTP access from internal network clients when you have multiple IP addresses bound to the external interface of the ISA server. There is an issue with PASV FTP downloads when using Internet Explorer from SecureNAT clients, when the ISA server has multiple addresses bound to the external interface. The workaround for this problem is to disable IP routing in the ISA Server Management console and enable the Routing and Remote Access Service (RRAS). This issue should be addressed with ISA Server Service Pack 2.

Publishing FTP Servers on Alternate Ports

Publishing an FTP server on the default port (TCP 21) is easy because the FTP access application filter does the footwork for you. However, when you want to publish an FTP site on an alternate port, the FTP access application filter isn't going to help you at all. You need to use the Firewall client on the publishing FTP server to make it work. The publishing server needs to be a Firewall client so that the Firewall client software can work with the firewall service to manage the connections. When the FTP access application filter manages the connections, the client can be a SecureNAT client. The problem is that the FTP access application filter only supports standard FTP port numbers.

Do the following to publish an FTP server on an alternate port:

1. Disable the FTP access application filter.

2. Change the listening port on the internal FTP server.

3. Install the Firewall client on the FTP server.

4. Place a wspcfg.ini file in the appropriate folder.

5. Use the credtool.exe file to provide credentials to the Firewall service.

6. Create an "All Open" protocol rule and site and content rule that can be used by the account.

The only reason we can see for publishing FTP sites on alternate ports is for "security through obscurity." This keeps out the weakest of hackers, but a simple port scan by a more sophisticated hacker will allow him to access your FTP site through the alternate port. Another reason to publish an FTP site on an alternate port is to violate the terms of service on your Internet account that prevents you from publishing servers.

Disable the FTP Access Application Filter

First, disable the FTP access application filter:

1. Open the ISA Management console, expand your server or array name, and then expand the Extensions node in the left pane of the console.

2. Click on the Application Filters node in the left pane of the console.

3. In the right pane of the console, right-click the Ftp Access Filter entry and click Disable. Choose the option to restart the Firewall Service and click OK.

It might take a few moments for the Firewall service to restart. That's not a problem because you have a few more things to do before publishing starts to work.

Change the FTP Site's Listening Port

The next step is to change the port number the FTP site listens on.

1. On the FTP server, open the Internet Information Services console from the Administrative Tools menu.

2. Expand your server name and right-click on Default FTP Site. Click the Properties command.

3. On the FTP Site tab (Figure 27.19), type the alternate port number you want to use for the site in the TCP Port text box. In this example, we'll use port number 12345. Click Apply and then click OK.

   
   Figure 27.19: Change the FTP Site Listening Port

4. Stop and restart the FTP service by clicking on the Stop and Start control buttons on the Internet Information Services button bar.

At this point, the FTP server listens on TCP port 12345. You can confirm this by opening a command prompt on the FTP server and doing a netstat –na | find ":12345".

Install the Firewall Client

Proxy Server 2.0 used the Winsock Proxy client. Since ISA Server is new, they decided to rename the Winsock Proxy client and call it the Firewall client. The Winsock Proxy client and the Firewall client are interchangeable, and you can use either to access both an ISA server and a Proxy Server 2.0 machine.

1. Log on as an Administrator at the FTP server.

2. Click Start and then click the Run command.

3. At the Run dialog box, type \\<ISAServerName>\mspclnt\setup.exe. Be sure to enter the appropriate name for your ISA server. Click OK.

4. Follow the instructions to install the Firewall client.

5. After installing the Firewall client, restart the FTP server.

You don't have to restart the FTP server after the Firewall client software is installed, but we always feel better when we do.

Place a wspcfg.ini File in the Appropriate Folder

You must create a wspcfg.ini file if you want to bind the appropriate ports on the external interface of the ISA server. Creating Firewall client configuration files is somewhat of a black art. If you have a hard time understanding the entries in these Firewall client configuration files, check out Jim Harrison's article on the subject. Jim has gone a long way at providing insight into exactly how these Firewall client configuration files work. You can find Jim's fantastic article on this subject at www.isaserver.org/pages/article.asp?id=236.

1. Open the Windows Explorer and navigate to \WINNT\System32\inetsrv folder.

2. Right-click on an empty area in the right pane of the Explorer, point to New, and click Text Document.

3. Double-click on the New Text Document.txt file.

4. Type into Notepad the text appearing in Figure 27.20. Replace the 12345 entry with the alternate port number you want to use.

   
   Figure 27.20: Creating the wspcfg.ini File

5. Save the file with the name wspcfg.ini as seen in Figure 27.21. It's important that you put the quotes around the name. If you don't, Notepad will append the ".txt" file extension to the filename. Click Save.

   
   Figure 27.21: Saving the wspcfg.ini File

Use the credtool.exe Utility to Send Credentials

If you're using outbound access controls based on user/group membership, you need a way to send credentials to the ISA Server Firewall Service. This is an issue because a server is usually not going to have a logged-on user. You need a way for the FTP service (inetinfo.exe) to send credentials to the ISA server without a logged-on user. You could use client address sets to do this, but the credtool method is a bit cleaner, since you're going to have to create an "All Open" protocol rule to make this work.

First, create an account with a complex password that can be used by the FTP server to authenticate against the ISA server. After you create the account using the Active Directory Users and Computer console, open a command prompt and enter the following information:

C:>\Program Files\Microsoft Firewall Client\credtool.exe -w -n inetinfo     -c ftpservice INTERNAL mypassword

Make sure you replace ftpservice with the name of an account you created for the FTP service to use. Replace the INTERNAL entry with the NetBIOS name of your Active Directory domain. Replace mypassword with the password you gave to the FTP service's domain account. If you entered everything correctly, you should see something like what you see in Figure 27.22.

Figure 27.22: Using the CREDTOOL

Create an "All Open" Protocol Rule

The FTP service's user account must have access to all protocols and all sites and content. For the site and content rule, you can use the built-in default. However, if you disable or change the default rule, make sure the account you created for the FTP service on the publishing server has access to all sites and content. This is just part of how the FTP protocol works. This allows outbound access to all outbound port numbers to the FTP service when creating secondary connections.

1. Open the ISA Management console, expand your server or array name, and expand the Access Policy node.

2. Right-click on Protocol Rules, point to New, and click Rule.

3. On the first page of the wizard, type in the name of the rule—we usually call it All Open. Click Next.

4. Set the Rule Action as Allow and click Next.

5. Set the Protocols for All IP traffic and click Next.

6. Set the Schedule for Always and click Next.

7. For the client type, select the Specific users and groups and click Next.

8. In the Users and Groups page, click Add.

9. Select your domain name in the Look in drop-down list box. Then, double-click on the username in the list box (Figure 27.23). Click OK, and then click Next.

   
   Figure 27.23: Adding the User Account

10. Click Finish on the last page of the wizard.

That's it! Restart the FTP server and let's have some fun.

Testing the Configuration

After restarting the FTP server, go to the ISA server, open a command prompt, and run a netstat –na | find ":12345". You should see something like Figure 27.24.

Figure 27.24: The FTP Server Listening on the Alternate Port

Now we know that the FTP server was able to bind TCP 12345 on the ISA server. It looks like it has bound that port on all interfaces. This is the socket pooling issue raising its head again. This isn't a problem, since the FTP server is a unihomed server. Note that this does not pose a problem, because we're not creating a server publishing rule. If we needed to create a server publishing rule, we would end up with a port contention problem.

Go to an external network client and open an FTP session using the Windows 2000 command-line ftp application. You should be able to connect using PORT mode and get a directory listing (Figure 27.25).

Figure 27.25: Testing the FTP Server

How about some big fun? Configure Internet Explorer to use PASV mode. In IE 6.0, you have to configure the browser's Advanced Properties to use PASV mode (Figure 27.26).

Figure 27.26: Configure Internet Explorer 6.0 to Use PASV Mode

Now enter the FTP site information into the address bar (Figure 27.27), and you should be able to access the site using PASV.

Figure 27.27: Connecting to the FTP Using PASV Mode

Tips on Configuring FTP Publishing

Publishing an FTP server on an alternate port might sound easy. It is in a way, but nothing comes both fast and easy in this business. When testing your configuration, you might want to reset the communication between the FTP server and the ISA server if you find you're having problems. You don't need to restart the FTP server to reset the Firewall client connection. Try this:

1. Stop the Firewall service.

2. Restart the Firewall service.

3. Stop the FTP service on the FTP server.

4. Restart the FTP service on the FTP server.

Confirm that the FTP server is communicating with the ISA server by using the ISA Management console's Sessions node (Figure 27.28).

Figure 27.28: Confirming the FTP Server's Link with the ISA Server

You should see SYSTEM as the account name and the name of the computer in the Firewall Session entry. Note that the User Name isn't correct. The User Name is listed as SYSTEM instead of the actual user name you configured in the CREDTOOL. However, when you see that SYSTEM is connected to the ISA server, the FTP server publishing rule using the Firewall client and the wspcfg.ini file is working.

Publishing FTP Servers Co-Located on the ISA Server

Cash-strapped organizations often need to run server services on the ISA server itself. As you know, this isn't the optimal way to make services available to Internet users because you expose the ISA Server machine to exploits carried out against services running on the ISA Server computer. However, if you have just a single server to do all the work, then you must put your public services on the ISA server.

FTP is probably the least secure of all Internet protocols, and it's the server that we would least like to put on the ISA server. However, if you want to run an FTP server on the ISA server, you can publish it as you do any other service on the ISA server, by using packet filters or server publishing rules.

Packet filters open the required port directly to the Internet, while server publishing rules allow you to leverage the FTP access application filter to publish the FTP site. Let's go over the packet filter method first, and then discuss the server publishing method.

Method One: Creating Packet Filters

Packet filtering should always be enabled. The only time where packet filtering might be disabled is when the ISA server is acting as a unihomed Web caching server on the internal network, or when the ISA server is on the edge of a departmental LAN that connects to a trusted corporate backbone. Packet filtering is the cornerstone of ISA Server's firewall security. If you have an interface directly exposed to the Internet, you must have packet filtering enabled.

You can create packet filters to allow external network users access to an FTP server located on the ISA server itself. This method doesn't require server publishing rules. The packet filters open ports required for PORT and PASV mode FTP clients.

To create the packet filters:

1. Open the ISA Management console. Expand your server and then expand Access Policies. Right-click IP Packet Filters, click New, and then click Filter.

2. In the Welcome page of the wizard, name the filter FTP Port 21 and click Next.

3. On the Filter Mode page, select the Allow packet transmission option and click Next.

4. On the Filter Type page, select the Custom option and click Next.

5. On the Filter Settings page, match the settings as shown in Figure 27.29. The IP Protocol is set for TCP. The Direction is Inbound. The Local Port is Fixed Port, and the Port number is 21. The Remote Port is All ports. Click Next.

   
   Figure 27.29: Configuring FTP Packet Filters

6. On the Local Computer page, select either the Default IP addresses for each external interface on the ISA Server computer option, or the This ISA Server's external IP address option, depending on whether you have more than one IP address bound to the external interface of the ISA server. Click Next.

7. On the Remote Computers page, select the All remote computers option if you want all computers to be able to access the FTP server, or select the Only this remote computer option if you want only a single external computer to access the FTP server. Click Next.

8. Confirm your settings on the final page of the wizard. If everything looks good, click Finish.

9. Repeat the process. However, for step 1 call it FTP Port 20, and for step 5, you should make the selections as shown in Figure 27.30. The Direction is Outbound and the Local Port is 20.

   
   Figure 27.30: Configuring the FTP Server Packet Filter

These packet filters only support PORT mode FTP clients. The reason is that PASV mode requires that the FTP client be able to connect to any ephemeral port on the ISA server. This would obviate your packet-filtering security mechanism. PASV mode FTP servers managed with packet filters are a special problem and they should be located only on DMZ segments, where the low security based on packet filtering is acceptable.

To see how what happens with PASV mode packet filters, perform the following steps to create packet filters to support PASV mode clients:

1. Open the ISA Management console, expand your server name, and expand the Access Policies node. Right-click on IP Packet Filters, point to New, and click Filter.

2. On the Welcome to the New IP Packet Filter Wizard page, type in PASV Command Channel in the IP packet filter name text box. Click Next.

3. On the Filter Mode page, select Allow packet transmission and check Next.

4. On the Filter Type page, click the Custom option and click Next.

5. On the Filter Settings page, the IP Protocol is set for TCP. The Direction is Inbound. The Local Port is Fixed Port and the Port number is 21. The Remote Port is All ports. Click Next.

6. On the Local Computer page, select the appropriate entry. In this example, we'll select Default IP addresses for each external interface on the ISA Server computer, and click Next.

7. On the Remote Computers page, select All remote computers and click Next.

8. Review your settings and click Finish on the Completing the New IP Packet Filter Wizard page. This completes the packet filter for the FTP command channel.

9. You now need a packet filter to support the data connection. PASV mode clients must establish a second connection to the FTP server on a high port number, and the FTP client must be able to receive the data on a high port. Right-click on the IP Packet Filters node, point to New, and click Filter.

10. On the Welcome to the New IP Packet Filter Wizard page, type PASV Data Channel in the IP packet filter name text box and click Next.

11. On the Filter Mode page, select the Allow packet transmission option and click Next.

12. On the Filter Type page, select the Custom option and click Next.

13. On the Filter Settings page (Figure 27.31), make the IP protocol TCP. The Direction is Inbound. The Local port is set for Dynamic and the Remote port is set to All ports. Click Next.

    
    Figure 27.31: The PASV Mode Data Channel Packet Filter

14. On the Local Computer page, select the Default IP addresses option and click Next.

15. On the Remote Computers page, select the All remote computers option and click Next.

16. Review your settings and click Finish on the New IP Packet Filter Wizard page.

The PASV mode data channel filter leaves the ISA server wide open. You're allowing inbound access to all high-number ports and allowing the ISA server to accept those requests to high-number ports from all port numbers. This is what we're referring to when we say that the FTP protocol is inherently unsecure. If you must run an FTP server on the ISA server, you should limit access to PORT mode FTP clients only.

Method Two: Server and Web Publishing Rules

The second method you can use to publish an FTP server is server publishing or Web publishing rules. The nice thing about doing it this way is that you can have PASV mode clients connect to the FTP server; the FTP access application filter takes care of connection management. Using a server publishing rule that leverages the FTP access application filter allows you to avoid creating wide-open packet filters that put your ISA server at significant risk.

Step 1: Disable Socket Pooling for the FTP Service

First, you need to disable FTP service socket pooling. The FTP service listens on all IP addresses when socket pooling is enabled, even if you configured the service to listen on a single IP address in the Internet Information Service console. While socket pooling is a good thing on a unihomed server on the internal network, it's a very bad thing on a multihomed firewall.

Perform these steps to disable socket pooling for the FTP service:

1. Open a command prompt and navigate to the \Inetpub\Adminscripts\ folder.

2. Type net stop msftpsvc and press Enter.

3. Type in the following command and press Enter:

   cscript adsutil.vbs set msftpsvc /disablesocketpooling true

   You should see what appears in Figure 27.32.

   
   Figure 27.32: Disabling FTP Service Socket Pooling

4. At the command prompt, type net start msftpsvc and press Enter.

5. Now let's run netstat –na again. You should see what appears in Figure 27.33.

   
   Figure 27.33: The FTP Service Listens on a Dedicated Address

6. Notice that TCP port 21 is now listening on 10.0.0.1 and not on 0.0.0.0. No more socket pooling for Port 21! We're almost ready to publish the FTP service using a server publishing rule and pointing to the internal IP address of the ISA server (which in this case is 10.0.0.1).

Step 2: Configure the FTP Service to Listen Only on the Internal Interface

The default setting for the FTP service is to listen on all IP addresses, even after socket pooling is disabled. You need to go into the Internet Information Services console and configure the service to listen on the internal IP address only. You use this interface in your server publishing rule.

1. Open the Internet Information Services console from the Administrative Tools menu.

2. Right-click on the default FTP Site and click Properties.

3. In the Default FTP Site Properties dialog box, you will see what appears in Figure 27.34. Actually, you won't see what appears until you click the Down arrow in the TCP Port drop-down list box. Note that there are two IP addresses on this particular computer, one for the internal and one for the external interface. We'll select 10.0.0.1 to have the FTP service listen on that IP address only. After making the selection, click Apply and then click OK.

   
   Figure 27.34: The FTP Service Listens on a Dedicated Address

4. After making these changes, stop the FTP service and restart it.

Step 3: Disabling the FTP Port Attack Setting

Some FTP server implementations allow a PORT command to open a connection between the FTP server and an arbitrary port on another machine. This allows the attacker to establish connections to arbitrary ports on machines other than the actual source machine. By default, IIS 5.0 prevents this from happening and blocks connections from machines other than the client that initiated the connection. However, since the ISA server needs to act on behalf of the source host, we have to disable this mechanism. Disabling this IIS mechanism does not open the server to attack, because the ISA server publishing rule protects the server.

For more information on the "bounce" attack, check out www.cert.org/advisories/CA-1997-27.html. The link at the CERT site also contains more detailed information on how IIS blocks this type of attack.

We need to disable the Port Attack protection provided by the IIS to make the FTP server publishing rule work. Perform the following steps to disable the Port Attack setting:

1. Open Regedt32 and drill down to the following key (Figure 27.35):

   
   Figure 27.35: Disabling the EnablePortAttack Entry

   HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Msftpsvc\Parameters\

   Note that the default setting is 0.

2. Change the EnablePortAttack value to 1.

3. Close Regedt32 and restart the FTP service.

Step 4: Create the Publishing Rule

The last step is creating the server publishing rule. You can use either the Web Publishing Wizard or the Server Publishing Wizard. The advantage of the Web Publishing Wizard is that you can publish multiple FTP servers using a single IP address on the external interface of the ISA server. If you use the Server Publishing Wizard, you can only publish a single FTP server (using TCP port 21) per IP address. We'll look at how to use the Web Publishing Wizard to securely publish an FTP site later in this chapter.

In this example, we'll use the Server Publishing Wizard.

1. Open the ISA Management console, expand your server, and then expand the Publishing node. Right-click on Server Publishing Rules, point to New, and then click Rule.

2. On the Welcome page, type a name for the FTP server publishing rule and then click Next.

3. On the Address Mapping page, type in the IP address of the internal interface of the ISA server in the IP address of internal server text box, and the IP address of the external interface in the External IP address on ISA Server text box, as shown in Figure 27.36. Then, click Next.

   
   Figure 27.36: The Address Mapping Page

4. On the Protocol Settings page, select the FTP Server protocol. Click Next.

5. On the Client Type page, select either the Any request or the Specific computers option, depending on whether you want to limit access to a specific set of computers. In this example, we'll choose the Any request option. Click Next.

6. On the last page of the wizard, confirm your settings and click Finish.

Your FTP server is now ready to accept connections. If things don't work, check the status of the FTP access application filter. This filter is enabled by default. However, you might have disabled it and forgot to re-enable it. If it is disabled, enable it. The FTP access application filter is required to publish an FTP server.

Note

There is an interesting limitation you'll notice when publishing an FTP server on the ISA server. Server publishing rules are often used instead of Web publishing rules in order to preserve the original IP address of the client making the request in the FTP log. When you publish the FTP server located on the ISA server using server publishing rules, you'll always see the source IP address as 127.0.0.1. There is no way to change this behavior. If you need the source IP address in the FTP service logs, you'll have to use packet filters to publish the FTP server.

Using Web Publishing Rules to Allow Secure FTP Access

One limitation to FTP service publishing is that you must use basic authentication. There is no option to allow integrated or certificate authentication with the FTP site. Another limitation is that you can't secure the information contained in the data stream. The information transferred from the FTP server to the FTP client is sent in the clear. While there is an implementation of FTP referred to as "secure FTP," it requires third-party software and is very difficult to make work across a firewall.

You can get around the FTP server's security limitations by using Web publishing rules to publish FTP servers. ISA Server allows you to publish FTP servers on the internal network using Web publishing rules and protocol redirection. The incoming requests are made to the Web Proxy service as HTTP requests, and are then forwarded to the published server as FTP requests. The Web Proxy service receives the information from the FTP server and returns the data via HTTP to the requesting host.

The Incoming Web Requests listener accepts basic, integrated, and digest authentication. You can also require SSL for the connection between the client and the ISA server. When the external network client makes the request to the FTP server via HTTP, you can require integrated authentication and use SSL to protect the data moving between the client and server. Alternatively, you can use basic authentication and increase compatibility. You remain secure as long as the basic authentication credentials are protected by an SSL tunnel.

You need to address the following issues when using Web publishing rules to securely publish an FTP server on the internal network,:

• Configure the Incoming Web Requests listener to support your preferred authentication method

• Configure the Incoming Web Requests listener to support SSL connections

• Create the destination set for the FTP server

• Create the Web publishing rule

Configuring the Incoming Web Requests Listener

Web publishing rules depend on an Incoming Web Requests listener. The Web Proxy service accepts incoming requests for Web publishing rules on the port on the external interface of the ISA server used by the Incoming Web Requests listener. The default setting for the Incoming Web Requests listener is TCP port 80.

The first thing you need to do is configure the Incoming Web Requests listener to support the type of authentication you require, and enable the SSL port on the listener.

Perform the following steps to configure the Incoming Web Requests listener:

1. Open the ISA Management console and right-click on your server name. Click the Properties command.

2. In the server Properties dialog box, click on the Incoming Web Requests tab. Select the Configure listeners individually per IP address option. Click Add.

3. In the Add/Edit Listeners dialog box (Figure 27.37), select your server name in the Server drop-down list box. Select an external IP address in the IP Address drop-down list box. Type a name for the listener in the Display Name text box. In the Authentication frame, you have a choice of authentication protocols. Put a check mark in the check box for the protocol you want to support. If you choose to support basic or digest authentication, make sure you click the Select domain button and enter the default domain. This greatly simplifies things for your users who might not know what domain they belong to. Just make sure that the default domain is your user domain and your users will never need to enter a domain name. If your user domain is a trusted domain, then check out Microsoft KB article Q319367 "How to Automatically Authenticate Users Against Trusted Domains." You also enter the certificate information used by this listener if you want to enable SSL on this specific listener. Each Incoming Web Requests listener supports one certificate. We cover details of SSL communications later in this chapter. Click OK.

   
   Figure 27.37: Configuring Authentication Methods on the Web Requests Listener

4. On the Server Properties dialog box, click on the Incoming Web Requests tab (Figure 27.38) and put a check mark in the Enable SSL listeners check box. This causes the Incoming Web Requests listener to start listening for SSL requests on TCP port 443.Note that you might run into an issue with port contention if the W3SVC is enabled on the ISA server and you have assigned a certificate to the default Web site and configured it to use TCP port 443 to accept SSL connections. To prevent socket pooling for these SSL connections, you will need to disable socket pooling for "securebindings." We cover this issue later in this chapter. Click Apply. You'll see the ISA Server Warning dialog box. Select the option that works best for you, and click OK.

   
   Figure 27.38: Configuring an SSL Listener

Creating the Destination Set for the FTP Site

As is true for all Web publishing rules, you need to create a destination set to use in the Web publishing rule. Perform the following steps to create the destination set:

1. Open the ISA Management console, expand your server name, and then expand the Policy Elements node. Right-click on Destination Sets, point to New, and click Set.

2. In the New Destination Set dialog box, type in a name for the set in the Name text box. Type in a description for the set and then click Add.

3. Select the Destination option button and type in the FQDN external users type into their browser to access the FTP site. Keep in mind that external users access the FTP site using HTTP, so they will not use an FTP client application to access the FTP site. You do not need to enter a path. Click OK.

4. Click OK in the New Destination Set dialog box.

Publishing the FTP Site with a Web Publishing Rule

The Web publishing rule uses the destination set you configured for the FTP site. We will first go through the Web Publishing Wizard to create the rule, and then we'll go through the Rule's Properties dialog box to fine-tune the redirection.

1. In the ISA Management console, expand your server name and then expand the Publishing node. Right-click on Web Publishing Rules, point to New, and click Rule.

2. On the Welcome to the New Web Publishing Rule Wizard page, type in the name for the rule. In this example, we'll call it FTP Server. Click Next.

3. On the Destination Sets page, select the Specified Destination Set option from the drop-down list box. Select the name of the destination set you created for the FTP server publishing rule in the Name drop-down list box. Click Next.

4. On the Client Type page, select the option that applies to the clients you want to support. In this example, we want to securely publish the FTP site, so we'll select the Specific users and group option. Click Next.

5. On the Users and Group page, click Add. In the Select Users or Groups dialog box, select the users or groups that you want to allow access to the site. Click OK. Click Next in the Users and Groups dialog box.

6. On the Rule Action page (Figure 27.39), select the Redirect the request to this internal Web server (name or IP address) option. Type in the IP address of the internal Web server. If you want to improve the relevance of your log file's information, you should create an entry in your internal DNS or on a HOSTS file on the ISA server. This entry resolves the name external users use to access the site to the IP address of the internal FTP server. For example, if external users type in ftp.internal.net to access the external IP address of the ISA server, create a HOSTS file entry on the ISA server that matches ftp.internal.net to the FTP server's internal IP address. Note that in this dialog box you have the option to redirect the request to an alternate port. This is very handy if you're publishing multiple FTP servers on the same machine, and you want to use the same IP address on the internal network for all your FTP sites. Just assign each FTP site on the internal server a different port number. Click Next.

   
   Figure 27.39: Configuring the Redirect on the Rule Action Page

7. Review your settings and click Finish on the Completing the New Web Publishing Rule Wizard page.

8. Double-click on the Web publishing rule you just created. Click on the Bridging tab in the rule's Properties dialog box. In the Redirect HTTP requests as frame, select the FTP requests option. This will allow the ISA server to redirect the HTTP requests it receives that matches the destination set used by this rule to be forwarded as FTP requests to the internal network FTP server. Click Apply and then click OK.

Now, go to an external network client, open Internet Explorer, and type in the URL to access your published FTP site. You'll be welcomed by a dialog box where you can enter your credentials (Figure 27.40).

Figure 27.40: Logging on to the FTP Site

Enter your credentials, click OK, and you get into the FTP site (Figure 27.41). Not the most exciting FTP site to hit the Internet, but it does demonstrate that you can access the FTP site files via HTTP. Note that the Web Proxy service supports only FTP downloads. You will not be able to upload files to the FTP site when you publish the site using a Web publishing rule.

Figure 27.41: The Published FTP Site

Later in this chapter, we'll go over how to attach a certificate to the Incoming Web Requests listener and secure the data stream using SSL.

Publishing HTTP and HTTPS (SSL) Servers with Server Publishing Rules

One of the main failings of Web publishing rules is that the source IP address is changed to the IP address of the internal interface of the ISA server when the Web Proxy service forwards the request to the publishing server on the internal network. This causes a problem if you need the requesting host's original IP address recorded in Web or FTP server's log files. You can solve this problem by using server publishing rules instead of Web publishing rules.

You can publish Web servers with server publishing rules. While you won't have the features provided by the Web Proxy service, you can still publish TCP port 80 like any other port. You can also publish SSL sites on the internal network using server publishing rules.

When you use server publishing rules, you can only publish a service one time per IP address. If you choose to publish Web sites using server publishing rules, you will need an IP address on the external interface for each site. The same rule applies to SSL sites.

The procedure for using server publishing rules to publish Web sites includes:

• Configuring the Incoming Web Requests listener to prevent port contention

• Creating an HTTP server protocol definition (an HTTPS server protocol definition is included with the default ISA Server installation)

• Creating the server publishing rule to publish the Web site

Configuring the Incoming Web Requests Listener to Prevent Port Contention

You can use a server publishing rule to publish Web servers on the internal network via TCP port 80, but you have to avoid port contention on the external interface. Running the IIS W3SVC on the ISA server can cause port contention on the external interface if you don't disable socket pooling. The Incoming Web Requests listener can also cause port contention if it's listening on the same port number and IP address you want to use for a server publishing rule.

Take a look at the Incoming Web Requests listener interface (Figure 27.42). You have two choices: Use the same listener configuration for all IP addresses and Configure listener individually per IP address. If you choose Use the same listener configuration for all IP addresses, the Incoming Web Requests listener listens on TCP port 80 on all addresses bound to the external interface of the ISA server.

Figure 27.42: The Incoming Web Requests Listener Interface

Select the Use the same listener configuration for all IP addresses option, and then run netstat –na | find ":80" at the command prompt. You'll see something like what appears in Figure 27.43. Notice that 192.168.1.33, 192.168.1.34, and 192.168.1.35 are all listening on TCP port 80. These three IP addresses represent the IP addresses bound to the external interface of the ISA server. Socket pooling has been disabled; that's why you don't see the machine listening on 0.0.0.0 port 80.

Figure 27.43: TCP Port 80 Listening on All External IP Addresses

There's no problem allowing the listener to listen on all IP address bounds to the external interface if you're not using server publishing rules to publish Web sites. However, if you want to use server publishing rules to publish Web sites, you'll need to choose the Configure listeners individually per IP address option. When you choose this option, only the IP addresses you explicitly configure as listeners will listen on TCP 80 on the external interface. All other IP addresses will be available for publishing TCP port 80 using server publishing rules.

You will run into problems if you have only a single IP address bound to the external interface of the ISA server. If the Incoming Web Requests listener is enabled, it will use the only IP address on the external interface of the ISA server to listen on TCP port 80. You won't be able to create a server publishing rule for a Web site because if you do, you'll end up with port contention.

One option you have is to change the port number that the Incoming Web Requests listener uses. If you change the listener port to TCP port 8888, then TCP port 80 will be free to use for the server publishing rule. The drawback to this approach is that external network users will need to be told what port number you're using for the listener so that they can enter it in their requests.

Another option is to disable all listeners. If you select the Configure listeners individually per IP address option and remove all listeners using the Remove button (or just don't add any, since by default there are no listeners), then the Incoming Web Request listener won't listen on any IP addresses.

No matter what decision you make, remember that the goal is to prevent port contention on the external interface of the ISA server.

Create an HTTP Server Protocol Definition

ISA Server comes preloaded with many protocol definitions that you can use to create protocol rules. These definitions include those that allow inbound and outbound access. Protocol definitions that have their primary connection set as inbound can be used in server publishing rules. There is a built-in protocol definition for HTTPS server publishing, but there isn't one for HTTP server publishing. Microsoft didn't include this protocol definition because they expected you to use Web publishing rules to publish Web sites.

You need to create your own HTTP server protocol definition. Perform the following steps to create the HTTP server protocol definition:

1. Expand you server name and then expand the Policy Elements node. Right-click on Protocol Definitions, point to New, and click Definition.

2. On the Welcome to the New Protocol Definition Wizard page, type in the name of the protocol definition in the Protocol definition name text box. In this example, we'll call it HTTP (Server). Click Next.

3. On the Primary Connection Information page, type 80 in the Port number text box. Leave the Protocol type as TCP and change the Direction to Inbound. Click Next.

4. Select No on the Secondary Connections page, and click Next.

5. Review your selections and then click Finish on the Completing the New Protocol Definition Wizard page.

Create the HTTP Server Publishing Rule

You can now create the server publishing rule to publish the Web site now that the Incoming Web Requests listener is configured and you have a protocol definition to support Web publishing using a server publishing rule.

1. Open the ISA Management console, expand your server name, and then expand the Publishing node. Right-click on Server Publishing Rules, point to New, and click Rule.

2. On the Welcome to the New Server Publishing Rule Wizard page, type in the name of the rule in the Server publishing rule name text box. In this example, we'll call it Web Server. Click Next.

3. On the Address Mapping page, type in the IP address of the internal network server in the IP address of internal server text box. Click Browse and select the IP address on the external interface of the ISA server that you want to accept connection to the Web server. Click Next.

4. On the Protocol Settings page, select the HTTP (Server) protocol definition in the Apply the rule to this protocol drop-down list box. Click Next.

5. On the client type page, select the client type appropriate for your environment. In this example, we'll select the Any request option. Click Next.

6. Review your settings and click Finish on the Complete the New Server Publishing Rule Wizard page.

Now, go to an external network client and connect to the Web site. The server publishing rule should start working immediately. If it doesn't, try restarting the Firewall service. If doing so doesn't fix the problem, check the Event Viewer. The Event Viewer reports problems with server publishing rules.

The most common reason for a server publishing rule to fail is port contention on the external interface. Always double check that the IIS W3SVC isn't trying to use the same port, and that you have configured the Incoming Web Requests listener in a way to avoid port contention.

Publishing pcAnywhere on the Internal Network

You can publish pcAnywhere hosts on the internal network using server publishing rules. There are a lot of questions and problems with pcAnywhere publishing on the www.isaserver.org Web boards and mailing list. Most of the time, the problems are easy to correct. You just need to follow the instructions in this section.

The procedure for publishing a pcAnywhere host on the internal network includes:

• Creating protocol definitions used by pcAnywhere

• Creating publishing rules used by pcAnywhere

• Configuring the pcAnywhere client and server

Let's go through the process of publishing a pcAnywhere server on the internal network, and then we'll discuss areas where you might have problems and how to solve those problems. Keep in mind that when we speak of a "pcAnywhere server," we're talking about a machine that's set up to take calls. You'll be able to connect to the machine from the Internet when we successfully publish the pcAnywhere server.

Note

PCAnywhere allows remote control of a computer with a different means of authentication than Windows. Be aware that this can increase your security risks.

Creating the pcAnywhere Protocol Definitions

pcAnywhere versions 9.x and 10.x use the following protocols for server publishing:

• TCP port 5631 inbound

• UDP port 5631 receive send

• TCP port 5632 inbound

• UDP port 5632 receive send

These protocol definitions all have their primary connections set to inbound. Note that the UDP protocols use "receive" to indicate a primary inbound connection.

Perform the following steps to create the pcAnywhere server protocol definitions:

1. Open the ISA Management console, expand your server name, and then expand the Policy Elements node. Right-click on the Protocol Definitions node, point to New, and click Definition.

2. On the Welcome to the New Protocol Definition page, type pcAnywhere 1 in the Protocol definition name text box. Click Next.

3. On the Primary Connection Information page, type 5631 in the Port number text box. Set the Protocol type to TCP and the Direction as Inbound. Click Next.

4. On the Secondary Connections page, select No and click Next.

5. On the last page of the wizard, review your settings and click Finish.

6. Repeat steps 1 through 5. Name the rule pcAnywhere 2. On the Primary Connection Information page, type 5631 in the Port number text box. Set the Protocol Type to UDP and the Direction as Receive/Send.

7. Repeat steps 1 through 5. Name the rule pcAnywhere 3. On the Primary Connection Information page, type 5632 in the Port number text box. Set the Protocol Type to TCP and the Direction as Inbound.

8. Repeat steps 1 through 5. Name the rule pcAnywhere 4. On the Primary Connection Information page, type 5632 in the Port number text box. Set the Protocol Type to UDP and the Direction as Receive/Send.

Creating the pcAnywhere Server Publishing Rules

You can now use the pcAnywhere protocol definitions to create the pcAnywhere server publishing rules. You will need four rules, one for each pcAnywhere protocol Definition.

Perform the following steps to create the pcAnywhere server publishing rules:

1. Open the ISA Server Management console, expand your server name, and then expand the Publishing node. Right-click on the Server Publishing Rules node, point to New, and click Rule.

2. On the Welcome to the New Server Publishing Rule Wizard page, type pcAnywhere 1 in the Server publishing rule name text box. If you plan to publish multiple pcAnywhere servers on the internal network, you might want to append the name or IP address of the host on the internal network. Note that the pcAnywhere host on the internal network needs to have a static IP address. Server publishing rules do not support using computer names for redirecting requests to internal network servers. Click Next.

3. On the Address Mapping page, type in the IP address of the internal network pcAnywhere server in the IP address of internal server text box. Click Browse and select the IP address on the external interface of the ISA server that you want to accept calls for the pcAnywhere server on the internal network. Click Next.

4. On the Protocol Settings page, select the pcAnywhere 1 protocol definition in the Apply the rule to this protocol drop-down list box. Click Next.

5. On the Client Type page, select the option that best fits your environment. Keep in mind that if they successfully authenticate, external users will have full access to the pcAnywhere server on the internal network. You should consider using a client address set to control inbound access to this server publishing rule. Note that you can't limit access to server publishing rules using users and groups. Only Web publishing rules can leverage users and groups. In this example, we'll use the Any request option and click Next.

6. Review your settings and click Finish.

7. Repeat steps 1 through 6. Name the rule pcAnywhere 2. On the Protocol Settings page, select the pcAnywhere 2 protocol definition.

8. Repeat steps 1 through 6. Name the rule pcAnywhere 3. On the Protocol Settings page, select the pcAnywhere 3 protocol definition.

9. Repeat steps 1 through 6. Name the rule pcAnywhere 4. On the Protocol Settings page, select the pcAnywhere 4 protocol definition.

You should be able to connect to the internal network pcAnywhere server soon after creating the last server publishing rule. You can force the new rules to be active by restarting the Firewall service.

We've tested this configuration using both pcAnywhere and Windows authentication and they both work. You can also use compatibility mode and the default (accelerator enabled) mode. Performance is quite good, but it depends on the speed of the link. File transfer and chat functions also work between the external client and the internal network pcAnywhere server.

If you have problems connecting to the pcAnywhere server on the internal network, consider the following:

• Publishing pcAnywhere servers on the internal network requires you to configure the pcAnywhere host on the internal network. If the pcAnywhere host on the internal network isn't answering, make sure the machine on the internal network is set to host mode.

• Make sure you've configured the pcAnywhere server on the internal network as a SecureNAT client. This is the most common reason for server publishing rule failures.

• You need one IP address on the external interface of the ISA server for each pcAnywhere server on the internal network. You cannot publish multiple pcAnywhere servers on the internal network with a single IP address on the external interface of the ISA server.

• Recheck your pcAnywhere protocol definitions. It's very easy to make a mistake when typing in the port numbers. Make sure the direction of each protocol definition is correctly configured.

• Recheck your pcAnywhere server publishing rules. You have to create four server publishing rules, and it's very easy to select the wrong protocol definition when configuring the server publishing rules.

If you have a problem with your pcAnywhere server publishing rules, check for these issues and you'll likely find the cause of the problem.