Web Publishing Rules are used to publish Web sites and services. Web Publishing is sometimes referred to as “reverse proxying.” When you publish a Web site, the ISA firewall’s Web Proxy filter always intercepts the request and then proxies the request to the Web site published by the Web Publishing Rule.

Web Publishing Rules sport the following features:

Let’s look at each of these features in more detail.

Like Web Publishing Rules, you can use Server Publishing Rules to provide access to servers and services on ISA firewall Protected Networks. The following features and capabilities characterize Server Publishing Rules:

Let’s look at each of these in a bit more detail.

On the Select Rule Action page, you have the option to Allow or Deny connections to the published Web server. Note that the default option on the Select Rule Action page is Allow. This is in contrast to the default action on the Access Rule Wizard, where the default action is Deny. Most Web Publishing Rules will allow access to Web sites and specific paths within those Web sites. However, you can create Web Publishing Rules that deny access to fine-tune Web Publishing Rules that allow access. Choose the Allow option and click Next. Figure 5.1 below shows the default option on the Select Rule Action page.

Figure 5.1. The Select Rule Action Page

On the Publishing Type page, you configure which websites ISA exposes, and how it exposes them. As you can see in figure 5.2, there are three available options in this dialog:

Figure 5.2. The Publishing Type Page

The first option was the only option available under ISA 2004. The second option is new to ISA 2006, and allows you to publish multiple web servers serving external content, balancing load between the websites, and (for websites which establish sessions with specific clients) can ensure clients continue using the same website (“affinity”). The third option allows the configuration of host’s header-based publishing in ISA 2006 during the web publishing wizard itself.

We will first continue through the web publishing wizard assuming we are publishing one website (i.e. with the first option selected), before discussing the other two forms of web publishing.

The Server Connection Security page is also new to ISA 2006, and provides an interface to existing functionality (the ability to publish an SSL or non_SSL website), but in a more prominent place. ISA 2006 provides us with entirely new options for specifying an SSL certificate while we create the rule itself.

The two options in this screen should be fairly self-explanatory, and are depicted in Figure 5.3.

Figure 5.3. The Server Connection Security Page

As we are publishing an HTTP site to begin with, we pick Use non-secured connections to connect the published Web server or server farm here. The ISA firewall will automatically pick the correct ports to use, but you may also go into properties for the publishing rule and edit which port it connects to under the Bridging tab after creating the rule. We will cover this later.

The two Internal Publishing Details pages replace the Define Website to Publish dialog in ISA 2004. On these pages you provide information about the Web site on the ISA firewall Protected Network. As you’ll see in Figure 5.4, you have the following options on the first page:

Figure 5.4. The Internal Publishing Details (Internal Site Name) Page

The Internal Site Name is the FQDN that clients on the ISA Protected Network use to connect to the website directly. In the example, we’re using the URL https://webfarm.infra.example.com, an internal intranet site used clients on a corporate LAN. We will be publishing this externally via the ISA firewall as https://extranet.example.com. In the example, we will be publishing an internal site to the internet using a different URL on the Internet to one the Protected Network, referred to as split DNS – we’ll discuss the virtues of this later.

In some instances, you may be publishing a site externally using the same URL on the internet as on the ISA firewall Protected Network. To work around this, you may enter the IP address or a host name for the web server you’re publishing in the Computer name or IP address text box. If you use a FQDN, make sure that the ISA firewall is able to resolve that name to the Web server’s IP address on the corporate network and not the IP address on the external interface of the ISA firewall. This is a very common error among ISA firewall administrators. You can ensure that the name is properly resolved to the private address of the Web server by creating a split DNS infrastructure or by using a HOSTS file entry on the ISA firewall.

One of the primary advantages of using a FQDN in the Computer name or IP address field is that the Web site name shows up in the URL field in the ISA firewall’s Web Proxy log. If you use an IP address, only the IP address of the published server will appear in this field and make log analysis more difficult to perform efficiently.

The second Internal Publishing Details page presents you with the following options, displayed in Figure 5.5:

Figure 5.5. The Internal Publishing Details (Path Name) Page

In the Path text box, you enter the paths you want accessible on the published Web server. If you simply want to make an entire web server available, then (as in the example) you can use the /* wildcard.

If, however, you want to make available only a specific subset of your internal web server available (for instance, /public/*, but not any other content at the root of the web server (/*), or the /private/* subdirectory), you can simply enter this path in the Path box. This option can work as a substitute for, or in addition to access controls on the Web Server itself.

Although this wizard page only allows you to enter a single path, we’ll see later that we can enter the Properties dialog box of the Web Publishing Rule and create additional paths and even path redirections.

The Web Site box isn’t a text box, so you can’t enter anything in it. Instead, it shows you the URL that will be accessible on the published Web site (the Internal Site Name textbox from the previous screen with the Path suffixed).

In this example, we entered webfarm.infra.example.com for the Internal Site Name textbox and chose to forward the host header as per the Internal Site Name field.

The Forward the original host header instead of the actual one specified in the Internal site name field on the previous page option is an interesting option which may be unclear without a detailed understanding of HTTP.

What means in practice is that instead of the host header value in the Computer name or IP address text box being sent to the published server, the actual host header in the request sent by the external user is forwarded to the published Web server. This is an important issue if you are hosting multiple Web sites on a single Web server and differentiate the Web sites by using different host headers for each one.

You can see the effects of forwarding, or not forwarding, the original host headers in Figures 5.6, 5.7, and 5.8. In Figure 5.6 below, you see the host headers as seen on the external interface of the ISA firewall from a client connection request for www.msfirewall.org. The HTTP: Host = www.msfirewall.org host header appears in the network monitor trace.

Figure 5.6. HTTP Headers Seen on the External Interface of the ISA Firewall

Figure 5.7. HTTP Headers Seen on the Published Web Server when Original Host Header is not Forwarded

Figure 5.8. HTTP Headers Seen on the Published Web Server when Forwarding the Original Host Header

When the Web Publishing Rule is configured to not forward the original Host header, and an IP address (or an alternate name) is used in the Computer name or IP address text box, you will see on the Network Monitor trace, in Figure 5.7, taken on the published Web server that the Host header entry is HTTP: Host =10.0.0.2, which isn’t the Host header contained in the original client address. It’s the entry we put in the Computer name or IP address text box. Figure 5.7 below shows an example of HTTP headers seen on the Published Web Server when the original Host header is not forwarded.

However, when we enable Forward the original host header instead of the actual one (specified above), Figure 5.8 shows what appears on the published Web server. In this case, the Network Monitor trace shows that the host header seen on the Web server is HTTP: Host = www.msfirewall.org. See Figure 5.8 below for headers seen on the published Web server when the original Host header is forwarded.

On the Public Name Details page, you enter information about what FQDNs or IP addresses users will use to connect to the published Web site via this Web Publishing Rule. You have the following options on this page:

The Accept requests for drop-down list provides you with two choices: Any domain name and This domain name (type below). If you choose Any domain name, any requests for a domain name or IP address are accepted by the Web listener for this rule. This is strongly discouraged for security reasons, as not requiring an HTTP hosts header corresponding to the name of the site will allow requests to be made to the web listener by IP address alone, by users (or scripts) who do not have a legitimate request. This increases your exposure to automated worms or scans.

For example, some prevalent worms will send requests to the TCP port 80 or to bogus domain names (such as www.worm.com) to the IP address used by the Web listener for this rule. If you select Any domain name, then the Web listener will accept these as valid requests and continue processing them. This is in spite of the fact that you are not hosting any resources for the bogus domain name the worm or the malicious user uses to access the IP address the Web listener is using on the external interface of the ISA firewall.

A better option, and the one we recommend that you always use for your Web Publishing Rules, is This domain name (type below). When you choose this option, you enter the exact domain name that must be included in the users request to the Web listener. If you want to accept requests only for the www.msfirewall.org domain, then incoming requests for http://1.1.1.1 or http://www.worm.com will be dropped because they do not match the domain name you want this rule to apply to. The one minor disadvantage this configuration option carries is that in the event that you wish to connect to the site directly by IP address (if DNS is down, or has not yet been configured, for instance), you cannot do this straight from the browser, and will have to edit the hosts file on your workstation instead.

When you select This domain name (type below), you must enter the domain name you want this rule to accept in the Public name text box. In this example, we entered the FQDN extranet.example.com. The Public Name Details Wizard page allows you to enter only a single domain name, but you can add more domain names after the wizard is completed. However, we highly recommend that you use a single domain name per Web publishing rule.

The Path (optional) text box allows you to restrict the path(s) that users can access via this Web Publishing Rules. You might want to allow users access to only specific directories on your Web site and not to the entire site. Although you can only enter a single path on the Public Name Details page (Figure 5.9 below), you can enter additional paths after the wizard is completed, in the Properties dialog box for this rule.

Figure 5.9. The Public Name Details page

You assign a Web listener to the Web Publishing Rule on the Select Web Listener page. A Web listener is a Network Object you use in Web Publishing Rules. The Web listener “listens” on an interface or IP address that you choose for incoming connections to the port you define. For example, for our Web publishing rule that allows HTTP public access to the extranet.example.com site, we will create a Web listener that listens on the external interface of the ISA firewall using the IP address that external users resolve extranet.example.com to.

You have two options on the Select Web Listener page if there are listeners already configured on the ISA firewall:

Edit allows you to configure existing Web listeners, and New allows you to create a new Web listener. Figure 5.10 illustrates this dialog with a pre-existing listener in place. In the following section we will step through the process required to create the web listener pictured, and will start by clicking New.

Figure 5.10. The Select Web Listener Page

On the Welcome to the New Web Listener Wizard page, enter a name for the Web listener in the Web listener name text box. In this example, we’ll name the Web listener HTTP Listener (.160) (since we have multiple IP addresses bound to ISA’s external interface, this identifies the last octet in the IP address to help disambiguate between Web Listeners). Click Next.

On the Client Connection Security page, as with the connection from ISA to the Published Web Site, we have the option to choose whether our connection uses HTTP or HTTPS. In this instance, however, the choice affects how traffic from internet-based clients to the ISA Server are made. We pick Do not Require SSL secured connections with clients and hit Next.

The Web listener accepts incoming connections automatically on the default ports - TCP port 80 in the case of HTTP, and 443 in the case of HTTPS. You can change this port to any port you like, as long as it does not collide with a socket already in use on the ISA firewall. The wizard provides no means to do this, and you must change this after creating the Web Listener. We will cover this further on in the chapter.

On the Web Listener IP Addresses page, select the Networks and IP addresses on those Networks that you want the listener to listen on. In ISA 2006, we can also choose to enable compression for web listeners.

Recall that each interface on the ISA firewall represents a Network, and all IP addresses reachable from that interface are considered part of that Network. The Web listener can listen on any Network defined on the ISA firewall.

In this example, we want to accept incoming connections from Internet users, so we’ll select the External network by putting a checkmark in its checkbox. At this point, the Web listener will accept connection requests to all IP addresses bound to the external interface of the ISA firewall. We recommend that if you have multiple IP addresses bound to an interface that you configure the Web listener to use only one of those addresses. This provides you greater flexibility because you can customize the properties of each listener. If you allow the listener to listen on all IP addresses on the interface, then a single set of listener properties will be assigned to it.

In ISA 2006, we also gain the ability here to enable or disable http gzip compression for this web listener. Previously in versions of ISA 2004 pre-SP2, this could not be done without losing some of ISA’s application-layer inspection capabilities.

Click Select IP Addresses on the Web Listener IP Addresses page, as shown in Figure 5.11, to progress to the Network Listener IP Selection page. On this page (Figure 5.12) you have three options:

Figure 5.11. The IP Addresses page

Figure 5.12. The External Network Listener IP Selection dialog box

All IP addresses on the ISA Server computer that are in the selected network is the default and is the same as checking the checkbox on the previous page without making any customizations. This option allows the listener to listen on all addresses bound to the interface representing the Network(s) you select. When you select more than one Network, the Web listener will listen on IP addresses bound to each of the Networks you select.

Default IP Addresses for network adapters in this network allows the listener to accept connections to the primary IP address bound to the Network interface. The primary address is the first address on the list of addresses bound to the Network interface. This is also the interface that is used for connections leaving that interface.

Specified IP addresses on the ISA Server computer in the selected network allows you to select the specific IP addresses you want the listener to use. The available IP addresses for the Network appear in the Available IP addresses section. You select the IP address you want the Web listener to use, and click Add; it then appears in the Selected IP Addresses section.

The example in Figure 5.12 demonstrates the Network centric nature of the ISA firewall - the Available IP Addresses list will display all IP addresses that correspond to the selected network, irrespective of which network adapters they are bound to. The default External Network includes all IP addresses that are not defined as part of a Network, which may include DMZ addresses if they are not configured within ISA as a separate network.

We can see in Figure 5.12 that there are a number of contiguous IP addresses bound to the external interface of the ISA firewall – but we have only picked one of the addresses for this particular publishing rule. Click OK. Then click Next on the IP Addresses page.

The next screen within the Web Listener wizard ISA presents us with is the Authentication Settings page in Figure 5.13 is another new wizard page.

Figure 5.13. The Authentication Settings page

We will be enabling HTML Form Authentication, validated against Windows (Active Directory). HTML Form, or Forms-Based Authentication in ISA 2006 provides a large number of possible back-ends and authentication types, and from the client to the ISA firewall is implemented using HTML forms and cookies, which – unlike with HTTP authentication - allow the administrator to configure timeouts after which the user must authenticate.

Table 5.1 describes each of the authentication methods available for Web listeners and a short description of the important characteristics of each method.

The authentication option you select applies only if you limit access to the Web Publishing Rule to a user or group. If you allow All Users access to the Web Publishing Rule, then the authentication option is ignored. These authentication options apply only to authentication performed by the ISA firewall itself, not to authentication that may be required by the published Web site. We will discuss authentication against the target webserver and Authentication Delegation later.

Some authentication methods (HTTP Digest and Integrated Authentication, and SSL Client Certificate Authentication) require that the ISA firewall be a member of a domain. This is not a significant issue unless you have a back-to-back firewall configuration where the front-end firewall is an ISA firewall (the back-end firewall can be any kind of firewall you like, including ISA firewalls). If the ISA firewall is on the front-end and you want to authenticate users at the front-end server, LDAP Authentication (or Radius Authentication) should be used. LDAP Authentication is a new feature in ISA 2006, and allows you to authenticate from the ISA firewall to one (or more than one) domain without being a member of that domain. Note that if you are using a back to back ISA Firewall configuration, no authentication should take place on the front-end ISA Firewall and the back-end ISA Firewall, which is a domain member, should do the authentication.

When the ISA firewall is on the back-end, we always recommend that you make the firewall a member of the Active Directory domain so that you can leverage the many security advantages inherent in domain membership. However, if there are political reasons why the back-end ISA firewall cannot be made a member of the domain, you can still leverage LDAP and RADIUS authentication in the scenario, too, although realize that by doing so, you reduce the overall security posture of the ISA Firewall.

In ISA 2006, the screens prompting for Radius/Radius OTP Server Settings and LDAP Server Settings (if you pick any of these options as the backend authentication provider) are prompted for after the Single Sign-On Settings, and these screens will be covered later.

If we hit Next on the Authentication Settings dialog, we come to the Single Sign on Settings dialog, pictured in Figure 5.18. Also new to ISA 2006, the Single Sign On feature allows ISA to sign on to multiple websites after the user has authenticated to one. This allows simple, one-login access to sites such as Outlook Web Access (OWA), Office Communications Server Communicator Web Access (CWA), Sharepoint Portal Server, or any number of other web applications. This greatly simplifies the user experience and increases efficiency & security.

The Single Sign on Settings dialog presents you with only one choice – the SSO Domain Name. This is an important option, as the Domain Name is used in the domain attribute of the cookie provided to the client when it logs into the published site via Forms-Based Authentication. In our case, we set this to .example.com

Figure 5.14. The Single Sign On Settings Page

As mentioned earlier, after the Single Sign On Settings page, if we have selected the LDAP, Radius, or Radius (OTP) backend authentication providers for our web listener authentication, we will now be prompted for further details of these settings if we have not previously configured LDAP authentication on other web listeners.

In the following section, we will explore the additional pages within the wizard having selected either of these options will present us with.

Figure 5.15. The LDAP Settings Page

The LDAP Servers Page prompts you to enter details for your Infrastructure’s LDAP Servers as well as which Active Directory domain name should be used for authentication. The LDAP Servers configured when you setup your first LDAP-enabled web listener are referred to as the Default Set – if you require different LDAP servers for different web listeners, you can define many sets of LDAP servers, and change the name of the default set, in properties for your web listener.

By default, this dialog does not check the Connect LDAP servers over secure connection option – without this selected, the queries sent by the ISA firewall to your domain controllers will be unencrypted LDAP queries sent to TCP Port 389 on the target LDAP Server. This option must be enabled in order to enable the ‘Change Password’ function when publishing Outlook Web Access. When enabled, connections are encrypted LDAPS connections, made over TCP Port 636.

If you do enable the Connect LDAP servers over secure connection, you will need to ensure that you have a certificate installed in the Personal, Local Machine Certificate store for each domain controller. The simplest way to do this is using certificate auto enrolment with an Enterprise CA, but you could also do this with a Standalone (or third party) Certificate Authority (or even commercial certificates).

Without appropriately configured certificates installed, and the root certificate which issued those certificates stored in the ISA Server Local Computer Account’s Trusted Root Certificate Store, connections to the target LDAP Server will fail.

If the option Connect LDAP servers over secure connection is not checked, you should ensure that your LDAP traffic is encrypted by IPSec or otherwise protected.

The Use global catalog option is optional, and if your LDAP servers are Global Catalog servers nullifies the requirement to provide an Active Directory Domain Name. This option, however, will prevent Password Management from functioning properly. Without Connect LDAP servers over secure connection enabled, queries to LDAP Servers with the Use global catalog option enabled will be made to TCP Port 3268. With this option enabled, connections are made on TCP Port 3269.

In order to enable Password Management for OWA FBA, you will also need to specify a username and password that the ISA Firewall can use to bind to the LDAP server and access information inaccessible to an anonymous user. This setting does not appear in the wizard, and must be enabled in the main GUI. This topic will be covered later on in the chapter.

Finally, LDAP support is only for Microsoft Active Directory domain controller. The ISA Firewall does not support other types of LDAP servers.

If we enable RADIUS or RADIUS (OTP) authentication from ISA, we will be prompted when creating our web listener to specify the servers to which we want to authenticate. ISA will authenticate to any standard RADIUS Server, including Microsoft’s (confusingly abbreviated) IAS Radius Server.

As mentioned earlier, RADIUS enables you to pre-authenticate users at the ISA firewall before authenticating to the target web server, without requiring ISA to be a member of the same domain as the target web server (or indeed any domain).

Figure 5.16. The RADIUS Servers Page

Hitting the Add button in this dialog presents us with Figure 5.17, the Add Radius Server dialog. This allows us to add the configuration settings for one Radius Server, and gives us the following options:

Figure 5.17. The Add Radius Server Page

The Server name field allows us to specify a DNS-resolvable name or IP address for the radius server we need to use. Unlike LDAP, Radius does not use certificates for authentication or encryption, and therefore there is no requirement for the Server name to be a FQDN matching the Computer Account Certificate, and IP addresses can be used.

The Description field allows you to provide an annotation for your entry. The Shared Secret setting is used to hash passwords sent via RADIUS, and should be of adequate length and complexity to make brute force attacks impractical.

By default, RADIUS uses UDP port 1812 for authentication traffic, and the Authentication Port field allows you to specify the port that should be used. Microsoft IAS Server, in line with many other third party radius packages, uses the standard port. The Time-out setting allows you to control how long ISA will wait before moving to the next radius server in the set.

The Always use Message Authenticator option adds an extra layer of security to the RADIUS protocol, allowing the target RADIUS server to verify the source of the RADIUS traffic by including data encrypted using the shared secret specified earlier. This option should be enabled if your RADIUS Server supports it. Microsoft IAS Server on Windows 2003 supports this option, and then corresponding server-side option to be enabled in IAS is the Client must always send the signature attribute in the request option.

At this point, we hit the end of the Web Listener Wizard, and can click Next and Finish to proceed. At this point, we can see our new web listener listed in the Select Web Listener page illustrated in Figure 5.10. If we wish to edit advanced properties of the web listener before finishing the web publishing wizard, we can do this here by hitting the Edit button with the Web Listener selected. This will be covered later.

If you use SecurID to authenticate your website, you are not prompted for further settings during the completion of the Web Publishing Rule Wizard, and there are few options in the ISA GUI for RSA ACE server settings, or other details that are obviously required in order to configure the ISA Server to authenticate against the ACE Server.

In order to complete the setup of the ISA firewall, you will need to appropriately configure the RSA ACE Server, and install the sdconf.rec file provided by the ACE Server onto the ISA firewall, and place it in the %systemroot%system32 directory.

Full configuration of SecurID and ACE are outside our scope, as SecurID is a complex technology, but there is a useful RSA Test Authentication Utility which you can use to check your RSA Configuration and ensure that ISA is able to authenticate to your ACE Servers downloadable from http://www.microsoft.com/downloads/details.aspx?FamilyID=7b0ca409-55d0-4d33-bb3f-1ba4376d5737&DisplayLang=en.

The next page we are presented with is the Authentication Delegation page. This screen is also new to ISA, and controls how our ISA server authenticates to the server published to clients. The Authentication Delegation page is illustrated in Figure 5.18.

Figure 5.18. The Authentication Delegation Page

The Select the method ... dropdown in this dialog allows you to dictate how authentication to the target web server takes place, and ISA 2006 introduces a variety of options for Authentication Delegation to the published web server, including Kerberos Constrained Delegation, both as part of the Negotiate and Kerberos constrained delegation options.

The following methods can be used for this second stage of the login process, from the ISA Server to the published Web Server:

We select Negotiate (Kerberos/NTLM), and then hit Next to proceed to the last page in the Web Publishing Wizard.

On the User Sets page (Figure 5.19), configure whether authentication is required to access the Web server published by this Web Publishing Rule. The default setting for http:// rules is All Users, which means that authentication is not required to access the Web server published by this Web Publishing Rule. Click Add if you want to require authentication. You will be presented with the Add Users dialog box where you can select the User Set representing the users you want the rule to apply to.

Figure 5.19. The User Sets page

Note that the All Users option only means that authentication is not required when the Web listener is not configured to require authentication. To configure the Web Publishing Rule to allow the user of anonymous credentials, use the All Users user set. Figure 5.19 below shows the options for the User Sets page.

We will discuss User Sets, how to create them, and how to use them in Chapter 4. Click Next on the User Sets page, and then click Finish on the Completing the New Web Publishing Rule Wizard page.

SSL Bridging is an ISA firewall feature that allows the ISA firewall to perform stateful application-layer inspection on SSL connections made to Web-published Web servers on an ISA firewall Protected Network. This unique feature allows the ISA firewall to provide a level of stateful application-layer inspection uncommon amongst other firewalls in its class.

SSL bridging prevents intruders from hiding exploits within an encrypted SSL tunnel. Conventional stateful-filtering firewalls (such as most “hardware” firewalls on the market today) cannot perform stateful application-layer inspection on SSL connections moving through them. These hardware stateful-filtering firewalls see an incoming SSL connection, check the firewall’s Access Control List, and if there is an ACL instructing the stateful packet filter-based firewall to forward the connection to a server on the corporate network, the connection is forwarded to the published server without any inspection for potential application-layer exploits.

The ISA firewall supports two methods of SSL bridging:

SSL-to-SSL bridging provides a secure SSL connection from end to end. SSL-to-HTTP bridging ensures a secure connection between the Web client and the ISA firewall, and then allows a clear text connection between the ISA firewall and the published Web server.

In order to appreciate how the ISA firewall works with SSL in protecting your Web server, let’s look at the life cycle of a communication between the Web client on the Internet and the Web site on the ISA firewall Protected network:

SSL-to-SSL Bridging and Web Site Certificate Configuration

One of the most common reasons that ISA firewall admins give up on SSL, and SSL-to-SSL bridging is the problems they may experience in getting the SSL connections to work correctly. The most common reason for this is a configuration error that involves the relationship between the certificate configuration and the Web Publishing Rule used to publish the Web site.

Figure 5.20 provides details of the SSL-to-SSL bridged connection to a public Outlook Web Access Web site.

Figure 5.20. SSL-to-SSL bridging

1. The Web client sends the request https://www.internal.net/exchange/ to the external interface of the ISA Server firewall publishing the OWA 2003 Web site

2. The ISA firewall checks its Web Publishing Rules to see if there is a Web Publishing Rule containing a Destination Set with the FQDN www.internal.net and the path /exchange. If there is a Web Publishing Rule matching this FQDN and path, the connection will be handled based on the forwarding instructions included in the Web Publishing Rule. However, before the ISA firewall can evaluate the URL, the SSL session must be established. The common name on the certificate the ISA firewall uses to impersonate the OWA Web site must be the same as the FQDN used by the Web client to connect to the site. In this example, the common name on the certificate the ISA firewall uses to impersonate the OWA Web site must be www.internal.net so that it matches the FQDN the external OWA client uses in its request.

3. The ISA firewall decrypts the packets, examines them, and then attempts to create a new SSL connection between itself and the internal OWA Web site. Just like when the external OWA client connects to the external interface of the ISA Server firewall, the ISA Server firewall’s Web Proxy service acts as a client to the OWA 2003 Web site on the internal network. The request the Web Proxy service sends to the OWA 2003 site on the internal network must match the common name on the certificate on the OWA Web site. That is why we must configure the request to be forwarded to www.internal.net when we configure the Web Publishing Rule. We’ll go over this important fact again when we discuss the configuration of the Web Publishing Rule.

4. The packets are forwarded to the Web site after the SSL session is established between the ISA firewall and the Web server on the internal network.

ISA Firewall Note

All machines participating in the SSL sessions (the Web client, the ISA firewall, and the Web site) must have the CA certificate of the root Certificate Authority in its Trusted Root Certification Authorities certificate store.

Things break when the common name on the server certificate doesn’t match the name used by the client request. There are two places where things can break in the SSL-to-SSL bridging scenario:

• If the common name on the certificate used by the ISA Server firewall to impersonate the Web site doesn’t match the name (FQDN) used by the Web client on the Internet

• If the common name on the certificate on the Web site doesn’t match the name (FQDN) used by the ISA firewall service to forward the request; the name in the ISA firewall’s request to the published Web server is determined by the entry on the To tab in the Web Publishing Rule.

Keep these facts in mind as we work through our SSL-to-SSL bridging Web Publishing Rule later.

ISA Firewall Alert

You will encounter the dreaded Internal Server Error 500 if there is a mismatch between the name in the request and the name on the certificate.

The ISA firewall must be able to impersonate the published Web server so that it identifies itself to the remote Web client as the published Web server. The mechanism behind this impersonation is a common name on the Web site certificate. We must install the Web site certificate on the ISA firewall to accomplish this task.

The first step is to export the Web site certificate from the secure Web server’s Web site. The IIS console has an easy-to-use Certificate Wizard where you can export the Web site certificate. When you export the Web site certificate, make sure that you include the private key. One of the most common reasons for failure in secure Web Publishing Rules is that the Web site certificate was not exported with its private key.

The Web site certificate is then imported into the ISA firewall’s machine certificate store. Once the Web site certificate is imported into the ISA firewall’s machine certificate store, it will be available to bind to a Web listener. You’ll know that the certificate wasn’t properly imported if you’re unable to bind the certificate to a Web listener.

Perform the following steps to import the Web site certificate into the ISA firewall’s machine certificate store:

Now that the Web site certificate is imported into the machine’s certificate store, it’ll be available to bind to the Web listener used in the SSL Web Publishing Rule.

The ISA firewall can be configured to present a user certificate to Web sites that require user certificates before connecting to the site. These user certificates are also referred to as client certificates. The published Web site can be configured to require that the client certificate be presented before a connection is allowed. Client certificates can be mapped to user accounts. This allows for user certificate authentication. However, you can require user certificates and then provide log on credentials via alternate authentication methods.

You can request a user certificate for the ISA firewall’s Firewall Service and then configure the Web Publishing Rule to present this certificate when Web sites request a client certificate. The first step is to request a certificate for the ISA firewall’s Firewall Service account.

In the following example we will use the certificates MMC to import a certificate for the ISA firewall’s Firewall service account. We cannot use the Certificates MMC to request a certificate for the account, but we can import a user certificate using the Web enrollment site.

In order to request a certificate for the ISA firewall from the Web enrollment site, we must first create a user account for the ISA firewall. Create a user account name isafirewall in the Active Directory prior to performing the following procedures.

Perform the following steps to request a certificate for the Firewall service account:

Now we’ll import the certificate into the Firewall service account:

The certificate is now associated with the Firewall service account. You might want to disable the System Policy Rule we created earlier so that you don’t inadvertently use the browser on the ISA firewall. Remember, you should avoid using the browser, and all other client applications, on the firewall.

Now that our certificates are in place, we can create the SSL secure Web Publishing Rule. There are two main differences between this process in ISA 2006, namely:

We will cover these differences, as well as re-exploring the Internal Publishing Details pages and Public name details pages, which have added implications for us when publishing SSL websites.

In ISA 2004, we had the choice as to whether to tunnel or bridge SSL Web Publishing Rules. ISA 2006 does not give you this choice, preferring instead to default to bridging SSL published websites.

This provides us with a wizard which has been tweaked to provide us only with the securer option - SSL Bridging provides a secure end-to-end encrypted SSL connection while at the same time allowing the ISA firewall to perform both stateful packet inspection (like any conventional “hardware” firewall) and stateful application-layer inspection.

SSL Tunneling with ISA 2004 bypassed the ISA firewall’s stateful application-layer inspection functionality and reduced the overall level of security for the publishing rule that is provided by a conventional stateful packet inspection “hardware” firewall. The omission of this form of publishing rule from the wizard should not prove a problem for many people, as there were very few reasons to use this option save for unusual situations such as those in which you publish applications that are not compliant with HTTP 1.1 Web Proxies. If you must publish an SSL website in tunneled mode, you must now do this via the Server Publishing Wizard.

One exception to this best practice is when you have a back to back ISA Firewall configuration. In this case, the front-end ISA Firewall should use SSL tunneling to the back-end ISA Firewall. The SSL connection is then terminated on the back-end ISA Firewall and SSL to SSL bridging can be done there.

Unlike ISA 2004, ISA 2006 does not give us separate SSL and non-SSL publishing wizards; instead, the same wizard presents us with choices as to whether to use SSL or not. We have choices regarding this in two main places:

ISA 2004 presented these choices to us in a subtly different way, allowing us to pick one of three options on the Bridging Mode page of the SSL Publishing Wizard:

These three options are still possible in ISA 2006, but are the resultant effect of the combination of the Server Connection Security and Client Connection Security pages.

We’ll cover these two distinctions in the Web Publishing Rule Wizard for the differing types of rule, and then go over how to accomplish with ISA 2006 what could be accomplished on the Bridging Mode page.

In our original Web Publishing Rule, we published a site on the ISA Protected Network, http://webfarm.infra.example.com as http://extranet.example.com to clients on the internet. In this example, we’ll go over the changes to the process were we to decide, instead, to publish https://webfarm.infra.example.com as https://extranet.example.com, either instead of, or in addition to, the http:// rules. Recall our recommendation that additional Web Listeners be configured to publish the same sites as http:// and https://, rather than a single Web Listener configured to handle both.

The Client Connection Security Page

The Client Connection Security page in the New Web Listener wizard allows us to choose which ports, and using which protocol the web listener listens on – HTTP on port 80, or HTTPS on port 443.

After selecting Require SSL Secured Connections with clients on this page, we proceed as with a non-SSL rule to the Web Listener IP Addresses page, to select which networks and IP addresses the web listener should accept requests from. The next page we are presented with, however, is an SSL rule-specific page, the Listener SSL Certificates wizard page, illustrated in Figure 5.21.

Figure 5.21. The Listener SSL Certificates dialog box

The Listener SSL Certificates dialog is new to ISA 2006, and provides simplified certificate management during the wizard itself. This wizard dialog allows you to specify either a single certificate for the web listener, or an individual certificate for each IP address selected in the publishing rule.

ISA Firewall Alert

You cannot configure SSL on the listener unless you have a machine certificate stored in the ISA firewall’s machine certificate store.

If we click the Select Certificate button, we open the Select Certificate dialog box, displayed in figure 5.22 which shows us which certificates are available for the listener, and in the lower Certificate Installation Details whether or not the selected certificate is valid for our purposes and correctly installed. The dialog defaults to displaying only valid certificates as shown in Figure 5.22.

Figure 5.22. The Select Certificate Dialog

If we deselect the Show only valid certificates option and select an invalid certificate (in this instance, a root certificate with corresponding private key, since as this is not a production ISA Server, it is also functioning as a Standalone Certificate Authority)

Figure 5.23. The Select Certificate dialog

As you can see, the Certificate Installation Details pane clearly indicates that the selected certificate is Incorrectly installed, and does not have an installed Private key.

This dialog greatly simplifies the certificate assignment process by giving you a clear indication as to whether or not your certificate is installed in the correct location and is of the correct type – Figure 5.24 shows the Certificate Installation Details for a certificate which is correctly installed (and has a private key), but which is inappropriate for a web listener:

Figure 5.24. The Select Certificate dialog with invalid certificates selected

Hitting Select in the Select Certificate dialog once we have the correct certificate selected in the Certificate Installation Details pane, we can hit Next on the Listener SSL Certificates page, and proceed to the Authentication Settings Web Listener Wizard page which we have already covered.

The General Tab allows us to change the Name and Description of the Web Listener. It is not pictured.

The Networks Tab allows us to change which networks the Web Listener is configured for, and which IP addresses within that network the Web Listener should use which are bound to the corresponding Interfaces in ISA Server.

By hitting the Address button, we can open the External Network Listener IP Selection dialog, pictured in Figure 5.12, allowing us to change the IP addresses to which the Web Listener binds.

The Connections tab of the Web Listener Properties dialog allows you to change which port the HTTP Listener is configured to accept connections on, as well as configure the same web listener to service HTTP and HTTPS requests. We recommend that you configure your HTTP and SSL listeners separately.

Figure 5.25. The Connections Tab

The HTTP to HTTPS Redirection allows you to force clients who browse to the URL of the web listener using http:// to be redirected to the https:// URL. This option requires that you enable both port 80 and 443 in the web listener under Client Connection Type.

When this option is enabled, the ISA Firewall will send an HTTP/1.x 302 Object Moved response back to clients who hit the http:// URL, causing the client browser to redirect to URL specified in the Location HTTP Header.

HTTP/1.x 302 Object Moved
Date: Fri, 21 Sep 2007 16:58:17 GMT
Connection: Keep-Alive
Content-Length: 0
Location: https://extranet.example.com/

If we click on the Advanced button, we reach the Connections – Advanced dialog, which allows us to configure the maximum number of clients which can be connected to the web listener at one time, and the connection timeout.

The Certificates Tab allows us to reconfigure the certificate options specified during the creation of the Web Listener, choosing either a Single certificate for this web listener or by choosing to Assign a certificate for each IP address.

By clicking the Advanced button on the Certificates Tab displayed in Figure 5.26, you can gain access to the one Advanced Certificate option, Certificate per server on all IP addresses.

Figure 5.26. Certificates Tab

If you use a hardware load balancer and require a separate certificate per server, even on addresses allocated to an NLB Interface, this option can be enabled to manage certificates on a server-by-server basis, rather than at the Array Level.

The Authentication Tab allows you to configure the form of Client Authentication Method used by the Web Listener, configure which Authentication Validation Method to use, and Configure Validation Servers if using an authentication method that utilizes hardcoded validation servers, such as LDAP or RADIUS authentication.

The Authentication – Advanced function can be reached by hitting the Advanced button on the Authentication tab.

With only HTTP enabled on the web listener, the Advanced Authentication Options dialog appears as in Figure 5.27, and has only one tab, the Authentication Preferences tab. With HTTPS also enabled, two additional tabs appear, the Client Certificate Trust list and Client Certificate Restrictions tabs, pictured in Figure 5.28 and 5.29.

Figure 5.27. Advanced Authentication Options – Authentication Preferences

Figure 5.28. Advanced Authentication Options – Client Certificate Trust List

Figure 5.29. Advanced Authentication Options – Client Certificate Restrictions

If you do not need to accept anonymous requests for this HTTP Listener, you can check the Require all users to authenticate option. As mentioned earlier in the chapter, ISA does not by default allow HTTP traffic to be used for authentication, and as such, the Allow client authentication over HTTP option comes disabled by default. In order to allow authentication over HTTP as we have earlier, this option should be enabled as displayed in Figure 5.26.

Client Credentials Caching and Authentication Domain can be configured to meet your requirements, whilst other options on this screen will be explored in the SSL Web Publishing section.

The Client Certificate Trust List tab affects how ISA handles User (client) certificates presented if we have SSL enabled, and accept client certificate authentication. By default, ISA has this setting configured to Accept any client certificate trusted by the ISA Server computer.

The list of Certificate Authorities ISA comes pre-populated with come from the Local Machine Trusted Root Certificates Store, and are shipped with Windows (and updated periodically with optional Windows Updates). The list includes Certificate Authorities such as Verisign and Equifax who have applied to have their certificates included with Windows, and who have passed a third-party audit.

So long as they adhere to the processes and procedures of the CA, anyone can buy a User certificate from many of these Trusted CAs, so if we enable User Certificate authentication with ISA, we automatically open the floodgates to allow any users of any of these Trusted Root CAs to authenticate to our ISA firewall. This may or may not be what we want to happen – if it isn’t, and we run our own CA from which we would like users to have certificates issued, we can select the Only accept client certificates trusted by the Root Certification Authorities selected below option, and select our CA, as pictured in Figure 5.28.

The Client Certificate Restrictions tab allows you to supply a filter to be applied to certificates used to authenticate to the ISA Server Web Listener. This provides more granular control over certificates than the Client Certificate Trust List can provide.

The restrictions that can be specified apply to one of the following four fields within the certificate itself:

The Issuer field in the certificate indicates the CA which issued the certificate, for instance the Issuer field for the certificate used for https://www.microsoft.com is:

CN = Microsoft Secure Server Authority
DC = Redmond
DC = corp
DC = Microsoft
DC = com

The Subject field in the certificate indicates to whom the certificate is issued. As with the Issuer field, this takes the form of a comma-separated Distinguished Name, and contains the CN, or Canonical Name of the certificate, which is identical to the FQDN of the site the certificate is used for, if the certificate is used for Web Publishing.

CN = www.microsoft.com
OU = mscom
O = Microsoft
L = Redmond
ST = washington
C = US

The Enhanced Key Usage (or Extended Key Usage) section of the certificate defines what purposes the certificate has. Within the context of a client certificate, this might, for instance, include the Smart Card Logon object identifier 1.3.6.1.4.1.311.20.2.2 – restricting the client certificates usable to authenticate to the ISA Server to those which are stored on smartcards.

The X.509 Certificate specification includes provision for extensions to the specification made using the Extensions field. In popular these include the Keyusage and AlternativeNames extensions.

As we have demonstrated, although the Client Certificate Restrictions dialog is well tucked-away and appears simple, due to the complex nature of certificates, the potential for restricting User Certificates is extremely powerful. We have not covered the full breadth of configuration options this dialog presents us with, but the documentation for your PKI implementation should supply more information on how certificates can be used, and how you may wish to begin to use this feature.

Although if all you wish to do is restrict the clients which can authenticate to domain or corporate clients, the Client Certificate Trust List may be perfectly adequate, if you wish to use Smartcard-enabled clients or specify more granular restrictions, Client Certificate Restrictions provides you with many options.

The Forms tab, which is pictured in Figure 5.30, allows configuration of Forms-Based Authentication, if this is in use on the Web Listener.

Figure 5.30. The Forms Tab

Form Customization allows users of Microsoft ISA Server to provide custom branding for the Forms-Based Authentication Interface, and configure language settings. The specifics of customizing the FBA Web Interface will not be covered here. Password Management can be enabled where authentication is performed against LDAP or integrated Active Directory back-ends, and when enabled, allows the user to pick an I want to change my password after logging on option whilst logging on via FBA.

The Advanced button on this tab allows us to open the Advanced Form Options dialog box, pictured in Figure 5.31. This dialog allows us to configure options pertaining to the cookies and timeouts used by Forms-Based Authentication.

Figure 5.31. The Forms – Advanced Dialog

The Cookie Name settings allows you to configure your ISA firewall to provide specifically named cookies, as well as configuring whether or not Persistent cookies are used. Persistent cookies are cookies which remain in the user’s browser after the browser is closed; using the default settings, Never use persistent cookies, cookies for Forms-Based Authentication are cleared when the browser is closed.

The Ignore browser’s IP address for cookie validation option dictates whether or not the ISA firewall will allow users to authenticate using the same cookie using more than one IP address. If you have users who may use connections with IP addresses which change, such as mobile users or users behind proxy server arrays, it is recommended that you leave this option enabled, or users will be forced to re-authenticate.

The Client Security Settings pane allows you to configure timeout settings for FBA clients who select either public or private as their location, as well as how the Timeout is applied – as an idle time (ie. Time elapsing between actions performed by the user within the user interface) or session time (ie. Time elapsing after logon).

You may wish to pick maximum session duration to force users to re-authenticate after a fixed time period for increased security. This option should be considered carefully, as it may inconvenience users.

The non-browser clients option applies these timeout settings to non-browser clients, such as RPC-over-HTTP/Outlook Anywhere or Activesync clients.

The Single Sign-On tab allows you to change settings for SSO specified during the Listener Setup Process. Principally, this means the SSO Domains which dictate which domains the SSO cookie inserted by the Web Listener into the user’s browser post –authentication is valid for.

As mentioned earlier, this should be as specific as possible – ie. .example.com in our example, not.com. Note also that SSO works only within the context of a single web listener – not cross-web-listener.

On this tab, you can change the name of the Web Publishing Rule by entering a name in the Name text box. You can also enter a description for the rule in the Description (optional) text box. You can enable or disable the Web Publishing Rule in the Enable checkbox, as shown in Figure 5.32.

Figure 5.32. The General tab

On the Action tab (Figure 5.33) you either Allow or Deny access to the site configured in the Web Publishing Rule.

Figure 5.33. The Action Tab

If you choose to Deny requests, you can redirect denied requests to a URL of your choice. This can be used for, for instance, exempting particular parts of a published site from being accessible via untrusted networks, or as a quick workaround for a particular security hole at a higher level than the ISA firewall is able to protect against, such as a vulnerability in a web application.

This can be accomplished simply by creating an identical publishing rule above the pre-existing publishing rule, but with paths matching only the portions of the site which should be denied, with an Action of Deny, and with the Redirect HTTP Requests to this Web Page field populated with a target to redirect to. This might be the root of your site, or a ‘denied’ page. Include the full URL as displayed in the ‘Address’ bar of the browser.

You also have the option to Log requests matching this rule. If you find that your log files are getting too large and the site being accessed by the rule isn’t of any particular interest to you, then you might consider not logging requests handled by this rule. However, we do not recommend that you disable logging for any publishing rules because most of these rules represent connections from untrusted Networks.

Click Apply on the Action tab, shown in Figure 5.33, to save the changes you make on this tab.

On the From tab, configure locations where you want the Web Publishing Rule to accept connections for the Published Site. The default location is Anywhere, which means that any host that can reach the IP address or addresses used for the Web listener can access this Web Publishing Rule.

You can limit access to this Web Publishing Rule by clicking Anywhere and then clicking Remove. After removing the Anywhere entry, click Add. In the Add Network Entities dialog box, click the folder that contains the Network Object you want to allow access to the Web Publishing Rule.

There is also the option to fine-tune access to the rule by setting exceptions in the Exceptions frame. For example, you might want to allow access to the Web Publishing Rule to all Networks except for hosts on the Network where the published server is located. This is generally a good idea because you do not want corporate network hosts looping back through the ISA firewall to connect to resources located on the corporate network.

Click Apply on the From page, Figure 5.34 below, after making your changes.

Figure 5.34. The From tab

The To tab is one of the most important tabs in the Properties dialog box. The reason for this is that the entry you put in the Server text box defines the host name in the URL that Web Publishing Rule sends to the published Web site. The entry you put in the Server text box replaces the host header that was included in the original client request sent to the ISA firewall. If you don’t want the ISA firewall to replace the entry in the host header with the entry in the Server text box, then put a checkmark in the Forward the original host header instead of the actual one (specified above) checkbox.

Another important option on the To tab is the ability to specify how the ISA firewall proxies the requests to the server listed in the Server text box. You have two options:

Requests appear to come from the ISA Server computer is useful when you don’t want to make the published Web server a SecureNAT client. One of the primary disadvantages of the SecureNAT client configuration is that the entire routing infrastructure must be aware that the ISA firewall should be the gateway to IP addresses clients of the web publishing rule come from. If this is an internet-facing publishing rule, this essentially requires making the ISA Firewall the default gateway, or configuring a very messy routing table on the published Web Servers.

Many organizations have an established routing infrastructure, and they don’t want to make the ISA firewall the route of last resort for all hosts on the network. You can get around this problem by allowing the ISA firewall to replace the remote host’s IP address with its own. When the published server returns its response, it only needs to know the route to the local interface on the ISA firewall. It doesn’t need a route to the Internet and doesn’t need to make the ISA firewall its default gateway.

Requests appear to come from the original client allows the ISA firewall to preserve the IP address of the remote host sending the request for published Web site resources. There are several advantages to this approach – in small environments, log-reporting software on the Web server itself frequently prompts this configuration, as you will be able to report on the actual IP addresses of the hosts connecting to the Web site. If you don’t select this option, it will appear in the Web site’s log files that all connections are coming from the ISA firewall’s IP address.

In larger environments, load balancing software such as Microsoft Network Load Balancing frequently handles ‘affinity’ (ie. Which webserver services which request) based on IP address – if all requests to webservers come from just one of the ISA firewall’s IP addresses (or a small number of addresses), all requests made through a particular publishing ISA firewall will bind to a particular web server. While it is possible to work around this problem (using ISA 2006’s own new-found understanding of load balancing of target web servers and cookie-based affinity, for instance), this is a problem which it is easier for many organizations to solve using the Requests appear to come from the original client option, with ISA in the routing chain.

One issue with this approach is that if you enable reverse proxy for the published Web site, you will notice a number of requests sourcing from the ISA firewall itself, and you might misinterpret this as the ISA firewall failing to preserve the IP address of the requesting host. This is not true, and there is no bug or problem with this ISA firewall software in this regard. The issue is that when performing reverse proxy, the ISA firewall serves the responses from its cache. However, the ISA firewall, in its role as reverse Proxy server, needs to check on the status of the objects on the Web site, and this status check generates requests from the ISA firewall’s address to the published Web site, which subsequently appears in the Web site’s logs.

For this reason and more, we prefer to perform Web site activity analysis on the ISA firewall’s Web Proxy service logs instead of the Web site logs themselves. There are exceptions to this rule, but for sites that are public sites only and not accessed by internal users, the Web Proxy logs on the ISA firewall provide the most rich and most accurate information.

Options for the To tab are shown in Figure 5.35 below.

Figure 5.35. The To Tab

On the Traffic tab, you’ll see a list of protocols allowed by this Web Publishing Rule. The protocols are not configurable on this tab. Instead, the allowed protocols are determined by the protocol support set on the Web listener configured for this publishing rule.

Notify HTTP users to use HTTPS instead will be disabled if you do not have HTTP and HTTPS enabled on the web listener. A similar, but separate, setting can be enabled on the Web Listener itself – using the HTTP to HTTPS Redirection option on the Connections tab, covered earlier in the chapter. If you enable this option on the Web Listener, the Notify HTTP users to use HTTPS instead option will also be disabled.

When the Notify HTTP users to use HTTPS instead option is available, it allows the ISA firewall to return an error page to the user accessing the Web site through the Web Publishing Rule showing that HTTPS, instead of HTTP, should be used – the error message seen by clients is depicted in Figure 5.36.

Figure 5.36. The Notify HTTP users to use HTTPS instead client experience

It’s a common error for users to enter HTTP, instead of HTTPS, when accessing secure Web sites. Fortunately, it takes less than three seconds to resubmit the request by adding an “s” to the protocol in the request. Forcing users to enter the correct protocol also encourages users to use correct Internet hygiene.

Whether you choose to redirect users from HTTP to HTTPS, or display an error and force them to alter the URL manually is up to you.

Require 128-bit encryption for HTTPS traffic allows you to control the level of encryption security for SSL connections to the published Web site. All modern Windows clients support 128-bit encryption right out of the box, but there are outdated Windows clients and non-Windows clients that do not support 128-bit encryption, and you might want to block connections from these relatively unsecure clients.

The Require SSL Client Certificate option is only enabled if the Web Listener for the publishing rule is not set to either No authentication or SSL Client Certificate Authentication. You can use this option to configure SSL User Certificate authentication in addition to other authentication methods – but the rule is only processed after the client authenticates via HTTP Basic or Forms-Based Authentication.

If you want to ensure that users have SSL User Certificates in order to connect at all, you should enable the Require SSL Client Certificate option, which can be found in the Advanced Authentication Options dialog in the Web Listener Authentication Tab.

Click Apply to save the changes you made on the traffic tab, as before.

Figure 5.37. The Traffic tab

On the Listener tab, you can view the characteristics of the listener currently in use by the Web Publishing Rule, and you can change the properties of the listener here, as well, by clicking Properties. You can also create a new Web listener by clicking New and then applying the new listener to this Web Publishing Rule.

If you have already created multiple Web listeners on this ISA firewall, you can change the listener used by the Web Publishing Rule by clicking the down arrow on the This rule applies to requests received on the following listener drop-down box.

Click Apply after you make changes on the Listener tab.

The Public Name tab allows you to view and configure the names that can be used to access the Web server published via this Web Publishing Rule. In the Web Publishing Rule we created in this example, we chose the name extranet.example.com for the public name that can be used to access the Web server. If a request comes in on the Web listener used by this Web Publishing Rule for a FQDN that is different from this one, this rule will ignore the connection request. Note that if this Web listener is used by other Web Publishing Rules, the incoming request will be compared to the Public Name entries in those other Web Publishing Rules. If no Web Publishing Rule includes a Public Name that matches that in the Host header of the incoming Web request, the connection will be dropped.

Also, note that a single Web Publishing Rule can be used for multiple host names. The key to success is to make sure that each of these host names resolves to the IP address or addresses that the Web listener bound to this rule is listening on. However, this also means that the same Paths, Bridging, Users, Schedule, and other settings would be applied to the connections coming in to the Web site. This might not always be the case, and this is why we recommend that you create separate Web Publishing Rules for each site that you publish.

You can Add a new Public name to the list by clicking Add, and you can Remove or Edit a selected public name by clicking Edit and Remove.

Click Apply when you have made your desired changes to the Public Name tab, as shown in Figure 5.38.

Figure 5.38. The Public Name Tab

The Paths tab allows you to control how requests to different paths included in the requests are handled by the Web Publishing Rule. You’ll notice in the path list that there are two columns: the External Path and the Internal Path column.

The External Path is the path in the request made by the user accessing the Web site through this Web Publishing Rule. For example, if a user enters the URL http://extranet.example.com/docs into the browser, then the external path is /docs. If a user enters the URL http://extranet.example.com/graphics into the browser, then the external path is /graphics.

The Internal path is the path that the ISA firewall will forward the request to based on the entry for the External path. For example, suppose we set the External Path as /docs and the Internal Path as /publicdocuments. When the user enters the URL http://extranet.example.com/docs into the browser, and the ISA firewall’s Web listener for this rule accepts the connection for the request, then the ISA firewall will forward the request to the site listed in the To tab to the path /publicdocuments. If the entry in the To tab is 10.0.0.2, then the ISA firewall forwards the request to the published Web server as http://10.0.0.2/publicdocuments.

Path redirection provides you a lot of flexibility in your Web publishing rules and allows you to simplify the paths external users use to access published resources without requiring you to change directory names on the published Web server.

If you want access to all the folders and files under a particular directory, enter the path using the /path/* format. If you want to allow access to a single file in a path, enter the path in the /path format. For example, if you want to allow access to all the files in the documents directory on the Web server, enter for the Internal path /documents/*. If you want to allow access to only the names.htm file in the documents directory, then enter the path as /documents/names.htm. An example of the Paths tab is shown below in Figure 5.39.

Figure 5.39. The Paths Tab

Click Add to add a new path. In the Path mapping dialog box, enter an internal path for Specify the folder on the Web site that you want to publish. To publish the entire Web site, leave this field blank text box. Next, select either the Same as published folder or The following folder option, as shown in Figure 5.40 below. If external users enter the same path, select the Same as published folder. If the users will enter a different path, select The following folder and enter the alternate path in the text box.

Figure 5.40. The Path Mapping Dialog Box

Figure 5.41. Redirecting to the Web Root Using a Path

Another thing you can do with path statements is redirect to different servers. For example, take the following URLs:

All three URLs point to the same FQDN and only differ in the path. You can create three Web Publishing Rules, each one using the same Public Name and each one including a different path configuration and a different server on the To tab. When a user makes a request using one of these three URLs, the request will be forwarded to the appropriate server based on the settings on the Public Name, Paths, and To tabs.

The Bridging tab, as shown in Figure 5.42, allows you to configure port or protocol redirection for the Web Publishing Rule. You have the following options:

Figure 5.42. The Bridging Tab

The Web Server option configures the Web Publishing Rule to forward HTTP or HTTPS requests. There is no protocol redirection with this option.

The Redirect requests to HTTP port option when checked allows you to redirect incoming HTTP requests for this Web Publishing Rule and Web listener to the published Web server using the port in the text box to the right of this option. The default port is TCP port 80. You can choose any other port you like for the redirect. This allows you to use alternate port numbers on the published Web sites while still accepting requests on the default HTTP port used by the Web listener (although you do not need to use the default HTTP port on the Web listener if you have configured the Web listener to listen on an alternate port).

Redirect requests to SSL port allows you to redirect requests to the specified SSL port. Note that you can select both the HTTP and SSL checkboxes. When this is the case, incoming traffic is routed through its corresponding protocol and port. For example, if the incoming request is HTTP, then the request is forwarded to the HTTP port. If the incoming request is SSL, the request is forwarded to the SSL port. You can change the SSL port the request is forwarded to, which is helpful if you have SSL sites published on alternate ports. Note that you will have to have certificates on the published Web Server configured appropriately for this scenario.

One of the most misunderstood options in the ISA firewall’s user interface is Use a certificate to authenticate to the SSL Web server. This option is not used by the ISA firewall to accept incoming SSL connections from users connecting to the published Web server. This option allows you to configure the ISA firewall to present a user certificate to the published Web site when the Web site requires user certificate authentication. The user certificate is bound to the Firewall service on the ISA firewall and enables the ISA firewall to present a user certificate for authentication to the Web site.

The FTP server option allows the Web Publishing Rule to perform protocol redirection. The incoming request can be either HTTP or HTTPS, and the connection is redirected as an FTP GET request to the published FTP site. Using SSL-to-FTP bridging is useful when providing remote access to FTP sites requiring authentication. Since FTP sites support only Basic authentication, you can protect user credentials by using an SSL link to the external interface of the ISA firewall. The Bridging tab is shown in Figure 5.43 below.

Figure 5.43. The Users Tab

The Users tab allows you to configure which users can access the published Web site via the Web Publishing Rule. Anyone can access the Web site through the ISA firewall when All Users are allowed access. However, this means that all users can get through the ISA firewall and have the unauthenticated requests forwarded to the published Web site. The Web site itself may require authentication. The user will still need to successfully authenticate with the Web site if the Web site requires authentication.

You can require authentication at the ISA firewall by removing the All Users group and adding any other user group via the Add button. The default groups included with the ISA firewall are All Users, All Authenticated Users, and System and Network Service. You can add your own firewall groups and fine-tune your authentication scheme. We’ll talk more about firewall groups and how to use them in Chapter 4 on Creating and Configuring Firewall Policy for Outbound Access. See how to configure the Users tab in Figure 5.43.

The ability to authenticate users at the ISA firewall provides a significant security advantage. Authenticating at the ISA firewall prevents unauthenticated connections from ever reaching the published Web server. Attackers and other malicious users and code can potentially leverage the unauthenticated connection to attack the published server. Authenticating at the firewall first removes the potential security risk.

Note that you can also require authentication at the Web site, so that users are required to authenticate at both the ISA firewall and at the Web site. In some circumstances, users will be presented with two log-on dialog boxes: the first authentication request is made by the ISA firewall, and the second authentication request is made by the published Web site.

You can avoid a dual authentication prompt by taking advantage of ISA’s Authentication Delegation. Since ISA 2006 greatly increases the firewall’s capabilities for delegation of authentication details, the ‘Delegation of Basic authentication’ setting provided on this tab in ISA 2004 has been replaced by the Authentication Delegation tab.

On the Schedule tab (Figure 5.44) you can configure schedules that control when users can connect to the published Web site. There are three default schedules:

Figure 5.44. The Schedule tab

You can also create your own custom schedules. We cover this issue in Chapter 4 on outbound access policies.

The ISA firewall’s Link Translation feature allows you to rewrite the URLs returned by the published Web servers. URL rewriting is useful when you publish Web sites that hard code links in Web pages they return to users, and those links are not reachable from external locations.

For example, suppose we visit a Web site using the URL http://extranet.example.com. The http://extranet.example.com home page contains hard-coded links in the form of http://server1/users and http://server1/computers. When the Internet user clicks on one of these links, the connection fails because the Internet user isn’t able to correctly resolve the name server1 to the IP address on the external interface of the ISA firewall.

The ISA firewall’s Link Translation feature allows you to rewrite the links containing server1 to extranet.example.com. When the Web server returns the home page of the extranet.example.com site, the external user no longer sees the URLs with server1 in them because the ISA firewall rewrote those URLs to include extranet.example.com instead of server1. The external user is now able to click on the links and access the content on the Web server. See Figure 5.45.

Figure 5.45. The Link Translation Tab

ISA 2006 introduces global and local mappings, allowing mappings to be applied at a higher level than the Web Publishing rule. Enterprise editions of ISA 2006 also include Cross array link translation. The newly introduced Mappings button allows us to view mappings defined at local and global level in the web browser.

We go into more detail in about the ISA firewall’s Link Translator in Chapter 4.

Authentication Delegation is entirely new to ISA 2006. As we discussed earlier, there are a range of options for authenticating to published Web Servers, whilst in ISA 2004, we only had delegation of basic authentication. To this end, ISA introduces a new tab for Authentication Delegation settings, pictured in Figure 5.46.

Figure 5.46. The Authentication Delegation Tab

As we can see, if the Negotiate (Kerberos/NTLM) or Kerberos constrained delegation options are picked, we are asked for a Service Principal Name. As we discussed earlier, authenticating via Kerberos requires the registration of the SPN against which the ISA Server’s computer account should be able to authenticate as users within Active Directory.

A Service Principal Name, or SPN, is made up of four components – Service Type, Instance Name, Port Number, and Service Name. These are presented within the SPN like so:

By default, computers have SPNs registered for their hostname and FQDN within Active Directory. These can be modified and viewed using the Delegation tab in the properties for the computer account, or using the setspn command line tool:

> setspn -l Machine1
Registered ServicePrincipalNames for
CN=Machine1, CN=Computers, DC=infra, DC=example, DC=com:
HOST/Machine1
HOST/Machine1.infra.example.com

Machines with kerberized services, such as LDAP, ADAM, or Exchange, will have additional SPNs. In order to allow our ISA Server, with a hostname of ISA01, authenticate via Kerberos Constrained Delegation to https://webfarm.infra.example.com, we would need to issue an setspn command as follows:

setspn  -a http/webfarm.infra.example.com.com ISA01
Registering ServicePrincipalNames for
CN=ISA01, CN=Computers, DC=infra, DC=infra, DC=com
  http/webfarm.infra.example.com ISA01
Updated object

Full coverage of the use of SPNs and AD for Kerberos Constrained Delegation is outside the scope of this book; for further documentation on the use of SPNs and Constrained Delegation, and the full implications of registering SPNs against machine accounts, see Tom Shinder’s article on how to publish sites using Kerberos Constrained Delegation at http://www.isaserver.org/tutorials/Configuring-ISA-Firewalls-ISA-2006-RC-Support-User-Certificate-Authentication-using-Constrained-Delegation-Part2.html

The Application Settings tab allows you to configure several options pertaining to Forms-Based Authentication, as follows:

The Use customized HTML forms instead of the default option allows you to customize the FBA login prompt. FBA Forms can be customized in order to apply your own branding to the login page, and display pre-authentication messages or disclaimers. ISA ships with two sets of customized forms, the ISA set (which are the default for web publishing rules), and the Exchange set (which are the default for exchange publishing rules).

Customizations to HTML forms can range in complexity from simple textual changes to full branding and tailoring to suit your requirements, and the full scope of form modification is outwith our scope. If you need to learn more about this, the ISA Server 2006 Technet site is a good starting point: http://www.microsoft.com/technet/isa/2006/html_forms.mspx.

The Published server logoff URL is an interesting option. Although if you publish Sharepoint or Outlook Web Access you will see a Logoff button, many applications which you may wish to publish via Forms-Based Authentication will not allow you to logoff in the same way as either of these two applications. The ISA firewall inserts a cookie into the user’s browser during the FBA logon process which is used to determine whether or not the user is logged in, the login functions of published applications will not remove this cookie, even if it does remove an application-specific logon cookie.

When the user browses back to the site then, the ISA firewall’s cookie continues to persist in the user’s browser. The cookie can be used to re-authenticate to the published site until it is cleared by the browser or by the ISA firewall. In order to work around this issue, the ISA firewall allows you to specify a URL which causes the ISA firewall itself to effect the logoff process, and invalidate the cookie so that it cannot be used to re-authenticate to the site. If your application uses a custom logoff URL, such as /page.aspx?=logoff, you can populate the Published server logoff URL with this value, and cause ISA to logoff at the same time as the logoff function within your application is triggered.

The Logon type provided to the Exchange server option allows you to enable, or disable, the private login type, which effects different settings for maximum login time.

You can fine-tune the Server Publishing Rule by opening the Server Publishing Rules Properties dialog box. Double-click the Server Publishing Rule to open the Properties dialog box. The first tab you’ll encounter is the General tab. Here you can change the name of the Server Publishing Rule and provide a description for the rule. You can also enable or disable the rule by changing the status of the Enable checkbox. The General tab is shown in Figure 5.48 below.

Figure 5.48. The General Tab

On the Action tab, set the rule for whether or not to log connections that apply to this rule. We recommend that you always log connections made via a Server Publishing Rule. However, if you have a reason why you do not want to log these connections (for example, privacy laws in your country do not allow logging this information), you can disable logging by removing the checkmark from the Log requests matching this rule checkbox shown in Figure 5.49 below.

Figure 5.49. The Action Tab

On the Traffic tab you can change the protocol used for the Server Publishing Rule by clicking the down arrow in the Allow network traffic using the following protocol drop-down list. You can create a new Protocol Definition for a Server Publishing Rule by clicking New, and you can view the details of the Protocol Definition used in the Server Publishing Rule by clicking Properties. You can also customize the source and destination ports allowed by the Server Publishing Rule using the Ports button. See options for the Traffic tab in Figure 5.50 below.

Figure 5.50. The Traffic Tab

You can control what hosts can connect to the published server using settings on the From tab. The default location allows hosts from Anywhere to connect to the published server via this rule. However, connections will only be allowed from hosts that can connect via Networks configured on the Networks tab. So, while hosts from Anywhere can connect to the published server, connections are still limited to those hosts who can connect via the interface(s) responsible for the Networks listed on the Networks tab.

You can get more granular access control over who can connect to the published server by removing the Anywhere option and allowing a more limited group of machines access to the published server. Click Anywhere, and then click Remove. Then click Add, and select a Network Object defining the group of machines you want to allow access to the published server.

You can further fine-tune access control by setting exceptions to the list of allowed hosts and adding them to the Exceptions list. Click Add in the Exceptions section. See Figure 5.51 for options on the From tab.

Figure 5.51. The From Tab

On the To tab, configure the IP address of the server published via this Server Publishing Rule. You can also control what client IP address is seen by the published server by your selection in the Request for the published server frame. You have two options:

Requests appear to come from the ISA Server computer allows the published server to see the source IP address of the incoming connection to the IP address on the network interface on the ISA firewall that is on the same Network as the published server. For example, if the published server is on the Internal network, and the ISA firewall’s interface on the Internal Network is 10.0.0.1, then the published server will see the source IP address of the incoming connection as 10.0.0.1.

This option is useful when you do not want to make the published server a SecureNAT client. The SecureNAT client is one where the machine is configured with a default gateway address that routes all Internet-bound connections through the ISA firewall. If you do not want to change the default gateway address on the published server, then use Requests appear to come from the ISA Server computer. The only requirement is, if the published server is on a different subnet from the ISA firewall, the published server needs to be able route to the IP address that the ISA firewall uses when it forwards the connection to the published server.

If you want the published server to see the actual client IP address, select Requests appear to come from the original client. This option requires that the published server be configured as a SecureNAT client. The reason why the machine must be configured as a SecureNAT client is that since the client IP address is from a non-local network, the published server must be configured such that traffic destined to the client’s IP address be routed via the ISA firewall. In most networks, this will mean that the server is required to have a default gateway that routes Internet-bound communications through the ISA firewall. Figure 5.52 illustrates the options on the To tab.

Figure 5.52. The To Tab

On the Networks tab, you can configure which Networks the ISA firewall can listen on to accept incoming connections to the published server. In this example, we set the Server Publishing Rule to accept incoming connections from hosts on the External Network (the default External Network includes all addresses that aren’t defined in any other Network on the ISA firewall).

You can configure the ISA firewall to listen on any Network. For example, you can configure the Server Publishing Rule to listen for connections on the VPN Clients Network. VPN clients can then connect to the published server via this Server Publishing Rule. The Networks tab is shown in Figure 5.53 below.

Figure 5.53. The Networks Tab

On the Schedule tab, you can set when connections can be made to the published server. There are three default schedules:

You can also create your own schedule using the New button. We’ll talk more about creating schedules in Chapter 4. Note that schedules control when users can connect to the published server, but they do not drop existing connections. The reason for this is that users who connected to the published server connected when connections are allowed, and they may have ongoing work that would be disturbed if the connection where arbitrarily halted by the schedule.

The Schedule tab is shown in Figure 5.54 below.

Figure 5.54. The Schedule Tab

You might have noticed when going over the list of Protocol Definitions used for Server Publishing Rules that there wasn’t a Protocol Definition for HTTP Server. There is a Protocol Definition for HTTPS servers, but not for HTTP. If you want to create a Server Publishing Rule for HTTP server publishing, you will need to create your own HTTP Server Protocol Definition.

We recommend that you always use Web Publishing Rules to publish Web sites, but there may be times when you want to publish a Web site that isn’t compliant with Web Proxy servers. In this case, you will need to use a Server Publishing Rule instead of a Web Publishing Rule.

Perform the following steps to create the Protocol Definition for HTTP Server publishing: <<TODO – Check in 2006 VM>>

Figure 5.56. The New HTTP Server Protocol Definition

<<TODO – Entire Mail Publishing Section>>

Select this option and click Next. On the Select Services page you have the following options:

The Outlook (RPC) option creates a Server Publishing Rule that allows inbound access for secure Exchange RPC connections. Secure Exchange RPC publishing allows Outlook 2000, 2002, and 2003 to “just work,” regardless of where the user is located. When combined with a well-designed split DNS infrastructure, users can roam between the corporate network and remote locations, open Outlook, and access their e-mail transparently without requiring reconfiguration of their e-mail application. Secure Exchange RPC is a very secure publishing protocol, and you can configure the Secure Exchange RPC Server Publishing Rule to force Outlook clients to encrypt their communications to the Exchange Server.

The POP3, IMAP4, and SMTP options allow you to publish both secure and non-secure versions of these protocols. Secure versions of these protocols use SSL to encrypt both user credentials and data. The ISA firewall will publish these protocols using Server Publishing Rules, but you must configure the Exchange Server with the appropriate Web site certificates to complete the configuration if you want to use the secure version of these protocols.

On the Select Server page, enter the IP address of the published server on the corporate network in the Select Server text box. Click Next.

On the IP Addresses page, select the Network representing the Interface that should accept connection requests for the published server. You can limit the IP address used to accept the incoming connection if you have multiple addresses bound to any of these interfaces by clicking the Address button. For more information on how to configure the settings on the IP Addresses page, see the discussion on this subject in the Server Publishing Rules section of this chapter. Click Next.

Click Finish on the Completing the New Mail Server Publishing Rule Wizard page. Click Apply to save the changes and update the firewall policy. Click OK in the Apply New Configuration dialog box.

You can enhance the security for your secure Exchange RPC publishing rule by forcing the Outlook clients to use a secure connection. Right-click the Exchange RPC Server rule, and click Configure Exchange RPC. Put a checkmark in the Enforce Encryption checkbox, click Apply and then click OK. See Figure 5.58 below.

Figure 5.58. The Configure Exchange RPC Policy Dialog Box