ISA Firewall Publishing OWA and RPC/HTTP with a Single IP Address: Part 3 – Single Exchange Server with Separate DC Scenario/LDAP Authentication

If you missed the other articles, check them out at:

In the first two parts of this multipart article series on how to publish the OWA and RPC/HTTP sites on a single Exchange Server that is not co-located on a DC, we went over some of the basic principles of Web Publishing and configured the certificate infrastructure to support the solution. We also installed and configured the RPC/HTTP proxy so that it would work in this scenario.

Discuss this article

In this article we’ll drill down on the Web Publishing Rule that publishes both the OWA and RPC/HTTP sites. Pay close attention to all the steps in this article! While I’ve put a lot of work into getting screen shots for each step, you should read the text for each step thoroughly so that you understand the purpose of each step. This understanding will help you generalize the information you learn in this article and apply that knowledge to your own customized environment, which will likely vary from the lab setup we have here.

Create the OWA and RPC/HTTP Web Publishing Rule

Now that the preliminaries are done, we can get to the meat of the configuration: creating the OWA and RPC/HTTP Web Publishing Rule. In this first exercise, we’ll create a single Web Publishing Rule that allows inbound access to both the OWA and the RPC/HTTP services. This allows us to demonstrate that you can use a single IP address to publish both of these services, something you couldn’t do with the 2004 ISA Firewall.

This works in the 2006 ISA Firewall because the new ISA Firewall can evaluate the user-agent header in the request, and if the ISA Firewall doesn’t recognize the user-agent as a browser, it will fall back to basic authentication. The fall back to basic authentication is required because non-browser clients are not able to process the form correctly.

Perform the following steps to create the OWA and RPC/HTTP Web Publishing Rule:

  1. In the ISA Firewall console, click the Firewall Policy node in the left pane of the console and then click the Tasks tab in the Task Pane. Click the Publish Exchange Web Client Access link.
  2. On the Welcome to the New Exchange Publishing Rule Wizard page, enter a name for the rule in the Exchange Publishing rule name text box. In this example, we name the rule OWA and RPC/HTTP. Click Next.

Figure 1

  1. On the Select Services page, select Exchange Server 2003 in the Exchange version drop down list. Put a checkmark in the Outlook Web Access and Outlook RPC/HTTP(s) checkboxes. Click Next.

Figure 2

  1. On the Publishing Type page, select the Publish a single Web site or load balancer option.

    The other option, Publish a server farm of load balanced Web servers would be used if you have a Web farm of front-end Exchange Servers. In that case, the ISA Firewall obviates the need for expensive “hardware” load balancers and enables the ISA Firewall to perform load balancing dynamically without requiring NLB being enabled on either the ISA Firewall array or on the Web farm.

    Click Next.

Figure 3

  1. On the Server Connection Security page, select the Use SSL to connect to the published Web server or server farm option. This allows the ISA Firewall to create a second secure connection, from its internal interface to the OWA Web site. This provides an end-to-end secure connection, while at the same time allowing the ISA Firewall to perform application layer inspection on the contents of the SSL tunnel.

    The Use non-secured connections to connect the published Web server or server farm option allows unsecured, free text traffic to move between the ISA Firewall’s internal interface and the OWA site. This free-text traffic is easily intercepted by anyone with a network analyzer. While some ISA Firewall administrators like this option because of the “SSL offload” feature it provides, the performance gains must be balanced with the real and profound negative security implications of this option.

    Click Next.

Figure 4

  1. On the Internal Publishing Details page, enter the common/subject name on the OWA Web site’s Web site certificate into the Internal site name text box. It’s critical that you enter the common/subject name into this text box. If you fail to do so, you’ll see an Internal Server Error 500 message when you try to connect to the OWA site.

    Put a checkmark in the Use a computer name or IP address to connect to the published server. This option is a new feature included in the ISA 2006 Firewall. With the 2004 ISA Firewall, the name in the Internal site name text box was used both for name resolution of the OWA Web site and the name used in the SSL CONNECT. This created some potential problems that required you to create a HOSTS file entry for the name on the OWA Web site certificate’s common/subject name. With this new option, we no longer need to create a HOSTS file entry on the ISA Firewall to support our Exchange Web publishing rules.

    In the Computer name or IP address text box, enter the actual name or IP address of the Exchange Server. In our current example, the IP address of the Exchange Server is, so we’ll enter that into the text box. We could also use the name, since the ISA Firewall is configured to use the internal DNS server for name resolution.

    Click Next.

Figure 5

  1. On the Public Name Details page, select the This domain name (type below) option from the Accept requests for drop down list.

    In the Public name text box, enter the name of the Web site certificate bound to the Web listener used in the Web Publishing Rule. In this example, we’ll be using the same Web site certificate as the one bound to the OWA Web site, which has the common/subject name Enter into the Public name text box.

    I should note here that you are not required to use the same name from end to end. For example, you could use two different certificates with one bound to the OWA Web site itself and another one bound to the ISA Firewall’s Web listener. I don’t see any practical reason for doing this, because there’s never a need to do so. I know that some ISA Firewall admins are concerned about using the same common/subject names on the certificates when they use commercial certificates on the ISA Firewall. This is not a problem. In this case, you use a commercial certificate on the ISA Firewall and you create your own certificate, with the same common/subject name and bind it to the OWA site.

    Click Next.

Figure 6

  1. On the Select Web Listener page you assign a Web Listener to the Web Publishing Rule. In this example, there are no Web listeners created yet, so we’ll have to create a new listener. Click the New button to begin the process.

Figure 7

  1. 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 SSL Listener and click Next.

Figure 8

  1. On the Client Connection Security page, select the Require SSL secured connection with clients option. This enforces a secure SSL connection between the external OWA or RPC/HTTP client and the ISA Firewall’s external interface.

    The Do not require SSL secured connection with clients option allows the external clients to create unsecured connections to the ISA Firewall. This is an unsecure configuration and should never be enabled in an Exchange publishing scenario.

    Click Next.

Figure 9

  1. On the Web Listener IP Addresses page, put a checkmark in the External checkbox. This allows this Web Listener to accept incoming connections for all IP addresses bound to the external interface of the ISA Firewall. We rarely, if ever, want to allow a Web Listener to listen on all IP addresses on the external interface, so we’ll click the Select IP Addresses button to get some control over this situation.

Discuss this article

Figure 10

  1. In the External Network Listener IP Selection dialog box, select the Specified IP addresses on the ISA Server computer in the selected network option. Double click the IP address bound to the external interface of the ISA Firewall shown in the Available IP Addresses list. The IP address is moved to the Selected IP Addresses list.

    Note that in this specific example that we really don’t need to select a specific IP address, since there is only one IP address bound to the external interface of the ISA Firewall. However, later in this document we’ll explore some more advanced Exchange Publishing Scenarios where we’ll bind additional IP addresses to the external interface of the ISA Firewall.

    Click OK.

Figure 11

  1. Click Next on the Web Listener IP Address page.
  2. On the Listener SSL Certificates page, select the Assign a certificate for each IP address option. This is a new feature included in the ISA 2006 Firewall, where you can bind multiple certificates to a single listener and have that listener accept connections on multiple IP addresses.

    Note that you cannot bind multiple certificates to a single IP address. This is not a limitation of the ISA Firewall, but a problem with how SSL works and current client-side implementations. There is work in progress now to update the SSL protocol and clients and servers, so that in the future this will be possible, but at this time, it’s not.

    Click the Select Certificate button to bind a specific certificate to this IP address.

Figure 12

  1. In the Select Certificate dialog box you’ll see a list of valid certificates installed on the ISA Firewall machine. Notice that by default, the Show only valid certificates checkbox is checked. If you don’t see your certificate in the Select a certificate from the list of available certificates list, then uncheck that checkbox to see if your certificate is listed. If so, this indicates that there was a problem with the certificate that you need to fix. The Certificate Installation Details section gives you details about the selected certificate, and can help you troubleshoot problems with certificates that the ISA Firewall doesn’t consider valid.

    Select the certificate and click the Select button.

Figure 13

  1. On the Listener SSL Certificates page you’ll now see that the Web site certificate is bound to the IP address Click Next.

Figure 14

  1. On the Authentication Settings page, confirm that the HTML Form Authentication option is selected from the Select how clients will provide credentials to ISA Server drop down list.

    From the Select how ISA Server will validate client credentials list of options, select the LDAP (Active Directory) option.

    Click Next.

Figure 15

  1. On the Single Sign On Settings page, put a checkmark in the Enable SSO for Web sites published with this Web listener option. The ISA Firewall provides single sign-on functionality that allows users to move safely from one application to another, without having to reauthenticate. For example, an authenticated user can move securely and seamlessly from Outlook Web Access to a SharePoint site by clicking a link in an e-mail message, without reauthenticating.

    Single sign-on is available for rules that share a Web listener. For example, if you want single sign on to be available between a SharePoint site and Outlook Web Access, the two rules that publish the SharePoint site and Outlook Web Access must use the same listener. The listener must be configured to use HTML form authentication, and single sign-on must be enabled on the listener.

    When you enable single sign-on you provide a domain across which single sign on will apply. For example, you can provide the domain, and then configure single sign on for and You cannot configure single sign on between two sites with different DNS suffixes, such as and

    While we won’t be testing SSO in this document, we’ll go ahead and enter into the SSO domain name text box.

    Click Next.

Figure 16

  1. Review the settings on the Completing the New Web Listener Wizard page and click Finish.

Figure 17

  1. The name of the Web Listener and some of the Listener’s properties now appear on the Select Web Listener page. Click Next.

Figure 18

  1. On the Authentication Delegation page you configure how you want the ISA Firewall to delegate credentials to the published Exchange Server. In this scenario where we are publishing OWA and RPC/HTTP using a single IP address, we need to use Basic authentication delegation. In other scenarios, where we have the option to create multiple listeners on different IP addresses, we could use other types of authentication delegation, such as User Certificate authentication and Kerberos Constrained Delegation. We’ll talk about User Certificate Authentication and Kerberos Constrained Delegation later in this document.

    Select the Basic authentication option from the Select the method used by ISA Server to authenticate to the published Web server drop down list.

    Click Next.

Figure 19

  1. On the User Sets page, the default setting is All Authenticated Users. This allows all users you successfully authenticate with the ISA Firewall to have their connection requests forwarded to the Exchange Server. You also have the option to limit access to certain groups, so that even if a user can successfully authenticate, the user must be part of a specific group in order to be authorized to access the Exchange Server. Later in this paper we’ll explore how to limit access to certain groups.

    In this example we’ll accept the default settings and click Next.

Figure 20

  1. Click Finish on the Completing the New Exchange Publishing Rule Wizard page.

Figure 21

  1. Click Apply to save the changes and update the firewall policy. Click OK in the Apply New Configuration dialog box.

At this point the ISA Firewall is configured to accept incoming connections from both OWA and Outlook 2003 RPC/HTTP clients.

Discuss this article


In this article we created the Web Publishing Rule that publishes the OWA and RPC/HTTP Web sites. We went over the details of each step in the configuration and explained the rationale for our choices and each of the available options along the way. In the next article in this series we’ll configure the Outlook 2003 RPC/HTTP client so that it will be able to connect to the Exchange Server using the full Outlook client. See you then! –Tom.

If you missed the other articles, check them out at:

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top