ISA Server uses Web publishing rules to handle issues associated with publishing Web content to the Internet, without compromising Internal network security. Web publishing rules determine how ISA Server intercepts incoming requests for HTTP objects on an internal Web server and how ISA Server responds on behalf of the Web server. Requests are forwarded downstream to an internal Web server, located behind the ISA Server computer. If possible, the request is serviced from the ISA Server cache. Web publishing rules are rich in features, including the following:

• Mapping requests to specific internal paths. You can limit the portions of your servers that can be accessed.
  
• Restricting access to specific paths and content types.
  
• Requiring user authentication. User authentication can be delegated by ISA Server, eliminating the need to reauthenticate at the Web server.
  
• Providing link translation. Links in Web content to internal servers are handled seamlessly.
  
• Providing Secure Sockets Layer (SSL) bridging. You can select to encrypt traffic between the ISA Server computer and the Web server.
  

For information on configuring Web publishing rules, see "Authentication in ISA Server 2006" at the Microsoft TechNet Web site.

ISA Server uses server publishing to process incoming requests to internal servers, such as File Transfer Protocol (FTP) servers, computers running Microsoft SQL Server™, and others. Requests are forwarded downstream to an internal server, located behind the ISA Server computer.

Server publishing allows virtually any computer on your Internal network to publish to the Internet. Security is not compromised because all incoming requests and outgoing responses pass through ISA Server. When a server is published by an ISA Server computer, the IP addresses that are published are actually the IP addresses of the ISA Server computer. Users who request objects assume that they are communicating with the ISA Server computer—whose name or IP address they specify when requesting the object—while they are actually requesting the information from the publishing server. This is true when the network on which the published server is located has a network address translation (NAT) relationship from the network on which the clients accessing the published server are located. When you configure a route network relationship, the clients use the actual IP address of the published server to access it.

Note:
Server publishing is not supported when ISA Server is configured with a single network adapter. In this configuration, ISA Server recognizes only the Internal network. There is no separation of Internal and External networks, and ISA Server cannot provide the NAT functionality required in a server publishing scenario.

An ISA Server rule element is an object that you use to define ISA Server rules. The specific rule elements used for Web publishing and server publishing rules depend on the type of rule you are creating. For example, Web publishing rules require a Web listener network object, while server publishing rules do not.

You can see the rule elements that are available to you by expanding the ISA Server computer node, clicking Firewall Policy, and selecting the Toolbox tab in the task pane. There are five types of rule elements:

• Protocols. This rule element type contains protocols that you can use to limit the applicability of rules.
  
• Users. In this rule element type, you can create a user set to which a rule will be explicitly applied, or which can be excluded from a rule. By creating a user set and making use of it in an ISA Server rule, you can create a rule that applies only to that set of users.
  
• Content types. This rule element type provides common content types to which you may want to apply a rule.
  
• Schedules. In this rule element type, you can designate hours of the week during which the rule applies.
  
• Network objects. In this rule element type, you can create sets of computers to which a rule will apply, or which will be excluded from a rule. For example, a subnet rule element represents a subnet within a network. You can create a rule that applies only to a subnet, or a rule that applies to a whole network exclusive of the subnet.
  

Publishing rules are processed together with all the firewall policy rules. They are processed in order, for each incoming Web request. When the rule matches a request, the request is routed and cached accordingly. If no rule matches the request, ISA Server processes the default access rule and discards the request.

An effective way to monitor which rules deny or allow specific traffic is to enable logging for each rule. However, the logging increases the load on the ISA Server computer, and can detrimentally impact performance. One way to work around this performance concern, while still maintaining security, is to identify which rules are being logged. Then, if a large amount of data is being logged from a specific protocol or source, you can create a new rule, which applies to that type of traffic, for which requests are not logged. For example, suppose your policy does not allow Dynamic Host Configuration Protocol (DHCP) requests, and as a result, you see many DHCP requests that are being denied. You can create a new access rule that denies DHCP requests, but does not log the requests.

By disabling logging for a specific rule, you effectively reduce the load on the ISA Server computer if it is under attack. However, note that if you disable logging on the default deny rule, ISA Server cannot detect port scan attacks.

Deny rules can be used to block access to a specific location on a published server.

When a client requests access to a published Web site, ISA Server checks firewall policy rules. The request will be accepted only if a rule specifically allows the client access to the content. If a publishing rule specifically denies the request, access is denied and the request is discarded.

Regardless of the type of Web publishing rule you are creating, the rule properties and the settings you will enter in the Web publishing wizards are similar. When you create Web publishing rules, you specify the following:

• Action. You specify whether a request is allowed or denied.
  
• Publishing type. You specify if the rule publishes a single Web site, multiple sites, or a server farm. Note that when publishing multiple sites, a rule is created for each site.
  
• Server connection. You specify the type of connection ISA Server makes with the published server (HTTP or HTTPS).
  
• Name (or IP address) of the Web server. You can limit whether the rule applies to all Web sites on the server, or to a specific Web site.
  
• Web site details. You specify both the internal site name and the public name that users type to reach the site on the internal server.
  
• Web listener. You specify the IP address or addresses on the ISA Server computer that listens for requests from clients.
  
• Authentication delegation. You specify the method used by ISA Server to authenticate client credentials with the published Web server.
  
• Users. You specify if access is allowed for all users, or restricted to specific users, such as authenticated users.
  
• After you create the publishing rule, you can modify its properties to define additional settings, such as:
  
• Path mapping. Before forwarding a request, ISA Server can map the external path to a corresponding internal path.
  
• Bridging. With bridging, you configure how HTTP and HTTPS requests are forwarded to the published server.
  
• Source. You specify the network objects that can access the published Web server. Note that the network objects that you specify must also be included in the Web listener specified for this Web publishing rule.
  
• Link translation. With link translation, you configure how ISA Server scans internal Web pages for links and updates them with the external name and path. For more information, see "Link Translation Concepts in ISA Server 2006" at the Microsoft TechNet Web site.
  

You can further filter requests made to the Web server, by configuring HTTP filtering. For more information about the HTTP filter, see "HTTP Filtering" at the Microsoft TechNet Web site.

Important:
We recommend that you do not enable directory browsing on the Web server that is published by ISA Server. Also, the Web server cannot require Digest authentication or Basic authentication. If it does, the internal name or IP address of the Web server may be exposed on the Internet.

Web Listeners

By default, all incoming Web requests must be received by a Web listener. A Web listener may be used in multiple Web publishing rules. When you create a Web publishing rule, you must specify a Web listener to be used when creating the rule. The Web listener properties determine the following:

• The type of connection the Web listener will establish with clients (HTTPS or HTTP). If you choose HTTPS, , an appropriate SSL certificate must first be installed on the ISA Server computer. You must select a server certificate to be used by the Web listener, so that the ISA Server computer can authenticate itself to the client.
  
• Which IP addresses on the specified networks will listen for Web requests.
  
• Which server certificates to use with which IP address (for secure connections).
  
• Client authentication methods.
  
• Single sign on (SSO) settings.
  
• After the Web listener is created, you can modify its properties to define additional settings, such as listener port, the number of concurrent connections that are allowed, and HTTP-to-HTTPS redirection.
  

Selecting Web listener networks (IP addresses)

The Web listener network, or networks, that you select depend on the networks from which clients will connect to the published Web server. For example, if the Web site you are publishing allows client requests from the Internet (External network), you should select the External network for the Web listener. By selecting the External network, you are selecting the IP addresses on the ISA Server computer that are associated with the External network adapter. If you do not limit the IP addresses, all the IP addresses associated with the selected network adapter will be included in the listener configuration. You can also select to listen on specific IP addresses for a network.

If you choose SSL, you will select a server certificate to be used by the Web listener, so that the ISA Server computer can authenticate itself to the client. You can also associate a digital certificate with a specific IP address, so that a single network adapter can have several certificates associated with specific, different IP addresses. Assigning a different certificate to each IP address enables you to publish several sites over HTTPS using the same Web listener, without using a wildcard certificate. For example, you can publish mail.contoso.com using a certificate with that name on one IP address, and team.contoso.com using a certificate with that name on a different IP address.

Specifying the listener port

By default, ISA Server listens on port 80 for HTTP requests. However, if connecting clients are expected to use a different port, you should change the port number accordingly. You can also enable the Web listener to listen for SSL requests. (The default is port 443.)

Defining client authentication methods

You can configure the Web listener properties to define authentication methods for Web requests. For more information about authentication, see "Authentication in ISA Server 2006" at the Microsoft TechNet Web site.

Specifying single sign on

When users access two different Web sites, such as an Outlook Web Access site and a SharePoint site, users should not have to provide the same credentials again when they click a link to open another site.

The ISA Server 2006 single sign on (SSO) feature reuses user credentials for another published server, eliminating the need to reenter credentials a second or third time. This enhances the user experience, because users click a link that opens another Web application without having to provide their credentials.

SSO is available when HTML forms-based authentication is the selected client authentication method.

Note:
SSO between different applications requires persistent cookies, which are disabled by default.

Original Host Headers

When ISA Server 2006 receives an incoming Web request, it determines whether the request is allowed, and then routes the request to the appropriate location on the Web server as defined in the Web publishing rule. If the rule is configured to forward the original host header, ISA Server passes the host header (for example, Host: example.microsoft.com) included in the client request to the published server.

If the rule stipulates that the original host header should not be forwarded, ISA Server substitutes the original host header in the request with the name of the server specified in the Web publishing rule. As a result, all requests that are routed to a particular Web server are sent to the same (default) Web site on that Web server.

Important:
For alternate access mapping to work properly, your SharePoint publishing rule must be configured to forward the original host header. This is the default configuration when using the SharePoint Publishing Wizard.

SSL Packet Inspection

Publishing Server Farms

ISA Server 2006 can publish a group of servers hosting the same data, also known as a server farm.

Server farms are rule elements, and can be defined either while creating a rule, or through the ISA Server Toolbox. ISA Server verifies on regular intervals that the servers that are members of the server farm are functioning. The server farm properties determine the following:

• Servers included in the farm
  
• Connectivity verification method that ISA Server will use to verify that the servers are functioning
  

When you protect your server farm with ISA Server, you distribute client requests between the Web servers while maintaining client affinity. We recommend that the servers in the server farm be located on a separate network from the users, to ensure that ISA Server can properly determine when the servers are available and not available.

Server farm load balancing mechanism

In many scenarios, for load balancing to be effective, affinity must be maintained between the client and the Web server that receives and responds to the client's request. Otherwise, a series of requests from the client and responses from the server farm will be handled by different Web servers, ignoring the context of the requests. For example, Outlook Web Access is an application that requires client affinity, because the Outlook Web Access server maintains a context for the connected client.

The need for affinity is also demonstrated in a Web shopping scenario, where a client sets up a shopping cart on a Web server. If affinity is not maintained, at some point in the client's session, the client's requests may be directed to another Web server that is unaware of the shopping cart.

When you apply a rule to a server farm, you can also configure whether the load balancing mechanism should be cookie based or source-IP based.

We recommend that you use session affinity when possible, because it provides more reliable client affinity when a Web server is restarted. This is sometimes referred to as client stickiness. It also works better in a situation where you are draining a Web server. Session affinity should be used for load balancing Outlook Web Access or Windows SharePoint Services access, both of which use Microsoft Internet Explorer®, and therefore support HTTP cookies.

IP address-based affinity has an advantage over session affinity in that it supports clients that are not fully compliant with HTTP 1.1 (clients that do not support HTTP cookies), such as some mobile devices. IP address-based affinity must also be used in a scenario where you are load balancing remote procedure call (RPC) over HTTP Outlook access. Outlook does not work with HTTP cookies, and therefore cannot use session affinity.

Important:
If you are publishing a server farm with ISA Server located behind another firewall, you must either use session affinity, or use IP address affinity and verify that the front-end firewall is configured to pass the original client's IP address to ISA Server.

Server farm connectivity verifiers

When you create a server farm, ISA Server creates a connectivity verifier for each Web server. Note that if your Web servers use a port other than port 80, specify that port on the server farm properties Connectivity Verification tab. You can view connectivity verifier status for the server farm in the Monitoring node, on the Connectivity Verifiers tab.

Draining a server farm

ISA Server provides a Drain option allowing you to specify that a server in the farm should temporarily stop accepting new connections. When you are ready for the server to begin accepting connections again, the Resume option is available.

Note that Drain and Resume are only active after you click the Apply button on the Apply Changes bar. When you drain a server, it stops accepting new connections. However, existing connections are not dropped.

Outlook Web Access provides Web browser access to e-mail, scheduling (including group scheduling), contacts, tasks, and collaborative information stored in Exchange Storage System folders. Outlook Web Access is used by remote, home, and roving users.

RPC over HTTP enables users to access e-mail with Microsoft Office Outlook 2003 over the Internet. Exchange Server 2003, together with Outlook 2003 and Microsoft Windows Server® 2003, support the use of RPC over HTTP to access servers that are running Exchange Server. By using RPC over HTTP, users no longer have to use a virtual private network (VPN) connection to connect to Exchange mailboxes. Users who are running Outlook 2003 on client computers can connect to an Exchange server in a corporate environment from the Internet.

An Exchange Web client access publishing rule is a Web publishing rule that contains default settings appropriate to Exchange Web client access. When you publish Outlook Web Access servers and RPC over HTTP through ISA Server, you are protecting the Outlook Web Access server and the RPC over HTTP proxy server from direct external access because the name and IP address are not accessible to the user. The user accesses the ISA Server computer, which then forwards the request to the Outlook Web Access server or RPC over HTTP proxy server according to the conditions of your mail server publishing rule.

Further, when you publish Outlook Web Access, ISA Server enables you to configure forms-based authentication, enforce required authentication methods, enable two-factor authentication, control e-mail attachment availability, and provide centralized logging.

The New Exchange Server Publishing Wizard also enables you to publish Outlook Mobile Access and Exchange ActiveSync®. Outlook Mobile Access provides users with access to Outlook from mobile devices. Using Exchange ActiveSync, you can synchronize with high levels of security, directly to your Exchange mailboxes from Microsoft Windows Mobile®-based devices, such as Pocket PC, Pocket PC Phone Edition, and Smartphones. The wizard also supports Exchange Server 2007 with Microsoft Outlook 2007 clients.

ISA Server 2006 works with Windows SharePoint Services and SharePoint Portal Server 2003, to enhance security.

Using the combined collaboration features of Windows SharePoint Services and SharePoint Portal Server 2003, users in your organization can easily create, manage, and build their own collaborative Web sites and make them available throughout the organization.

When you publish SharePoint sites to the Internet, you provide employees, who are not in the office, access to the information that they need to complete their jobs, no matter where they are located, without compromising security.

When you publish a SharePoint site through ISA Server, you protect the SharePoint site from direct external access because the name and IP address of the SharePoint site are not accessible to the user. The user accesses the ISA Server computer, which then forwards the request to the published SharePoint site according to the conditions of your SharePoint publishing rule.

When you publish a SharePoint site, ISA Server enables you to configure forms-based authentication, enforce a required authentication method, enable two-factor authentication, control attachment availability, and control centralized logging.

Server publishing rules map incoming client requests to the appropriate internal server. ISA Server performs the following steps during server publishing:

1. A client computer on the Internet requests an object from an IP address known as the publishing server. The IP address is actually associated with the ISA Server computer. It is the IP address of the external network adapter belonging to the ISA Server computer.
   
2. The ISA Server computer processes the request, mapping the IP address to an internal IP address of an internal server.
   
3. The internal server returns the object to the ISA Server computer, which passes it to the requesting client.
   

There are two types of server publishing rules that you can create:

• Mail server publishing rules. Used to publish mail servers using SMTP, RPC, POP, IMAP, and NNTP protocols.
  
• Server publishing rules. Used to publish services on an internal server.
  

When you create a server publishing rule, you specify the following:

• Mail access and services (Mail Server Publishing Wizard only). Mail access can be client access or server-to-server access. After you select the mail access type, you specify the services you are publishing. If you select to publish more than one service, a rule will be created for each service.
  
• Protocol used by the published server (standard server publishing rules only). ISA Server provides built-in inbound protocol definitions for server publishing.
  
• Server IP address. This is the IP address of the server you are publishing.
  
• Listener IP address. This is the network IP address on the ISA Server computer that will listen for requests intended for the published server.
  

After you create the publishing rule, you can modify its properties to define additional settings, such as:

• Application filtering on a per-rule basis. Per-rule filtering is available for server publishing rules from the Exchange RPC filter, and for FTP server publishing rules.
  
• Overriding default ports. When you use ISA Server to publish a server, by default, the firewall listens for incoming requests on the standard port of the respective protocol and passes incoming connections to the same standard port on the publishing server. For example, when you publish an FTP server, ISA Server listens for incoming requests on port 21, the port associated with the FTP protocol, and passes incoming connections to port 21 on the published server. You can override the standard port by specifying different ports in the publishing rule.
  

  Note:
  When you publish an RPC interface where there is a route network relationship between networks, port overriding is ignored. The publishing rule will use the original IP address and port.

Access rules determine how clients on a source network access resources on a destination network. You can configure access rules to apply to all IP traffic, to a specific set of protocol definitions, or to all IP traffic except selected protocols. When a client requests an object using a specific protocol, ISA Server checks the access rules. A request is processed only if an access rule specifically allows the client to communicate using the specific protocol and also allows access to the requested object.

When you configure a firewall policy for ISA Server, generally follow these guidelines:

• Use access rules to control how clients on the Internal network or on the VPN Clients network access data on the External network.
  
• Use publishing rules to control how clients on the External network access resources on the perimeter or Internal networks.
  

In summary, for all outgoing traffic, use access rules. For incoming traffic, use publishing rules.

These guidelines are generally true when you configure a network address translation (NAT) relationship between the networks. NAT relationships necessarily require that you think of one network as the source network, with the other network as the destination network. With a NAT relationship, you can more easily follow the previously listed guidelines.

When a route relationship is configured between networks, either a server publishing or access rule can be used. Specifically, when the following conditions are true, access rules and server publishing rules have identical functionality:

• A route relationship exists between the source and destination IP addresses.
  
• No port translation (forwarding) is needed.
  
• The protocol has no application filter.
  
• Network Load Balancing (NLB) is not used, or the number of possible clients is negligible.
  

The following table compares some functional differences between access rules and server publishing rules.