Publishing Outlook Web Access and Outlook RPC/HTTP with ISA Server 2006 Enterprise Edition (RC) Firewalls using Forms-based Authentication (Single Member Array without NLB) – Part 3: Deploying Certificates and Creating the Web Publishing Rules

By /

Publishing Outlook Web Access and Outlook RPC/HTTP with ISA Server 2006 Enterprise Edition (RC) Firewalls using Forms-based Authentication (Single Member Array without NLB) – Part 3 Deploying Certificates and Creating the Web Publishing Rules

Discuss this article on the Web Boards at: http://tinyurl.com/fvflv

If you missed the other parts in this article series please read:

In the first part of this series on how to publish OWA and RPC/HTTP sites using the ISA firewall, I discussed the network environment on which the series is based, some key networking and ISA firewall concepts and issues involved with using the new ISA firewall, ISA Server 2006. In the second part of the series, I went into great depth about important DNS considerations that you need to take into account before for deploy the solution.

In this article we’ll focus on the following:

  • Deploying certificates to the front-end Exchange Servers and the ISA firewall
  • Configuring DNS to support our split DNS infrastructure
  • Creating the Web Farm
  • Creating the OWA and RPC/HTTP Web Publishing Rules
  • Testing the OWA and RPC/HTTP Web Publishing Rules

One thing I won’t go over in this article series is how to configure the FE and BE Exchange Servers. In the past the configuration was somewhat complex and you had to go through a lot of hoops to make things work correctly. With the introduction of Microsoft Exchange 2003 SP2, Microsoft has done the heavy lifting for you and you don’t have to play with the Registry to make the front-end/back-end Exchange work right the first time.

Deploying Certificates to the Front-end Exchange Servers and the ISA firewall

The first step is to make sure that all certificates are deployed before configuring the ISA firewall’s Web Publishing Rules. We need to do the following:

  • Install a Web site certificate on each of the front-end Exchange Servers
  • Install a Web site certificate on the ISA firewall so that the ISA firewall can impersonate the front-end Exchange Servers

I am using a pure split DNS infrastructure in this series which makes things very easy. This enables me to use the same name from end to end. Using the same name from end to end enables the following:

  • The external user sends a request to https://owa.msfirewall.org/exchange and connects to the IP address on the external interface of the ISA firewall used by the Web listener that is used by the Web Publishing Rule that publishes the site.
  • The ISA firewall forwards (proxies) the request from itself to https://owa.msfirewall.org/exchange and connects to the actual IP address of the OWA site on the internal network. Actually, it’s a bit more complicated than this in our Web farm publishing scenario and I’ll point that out when we get to the point of creating the Web Publishing Rule.
  • Internal users on the corporate network send a request to the https://owa.msfirewall.org/exchange and that request resolves to an internal IP address on the ISA firewall and enables the ISA firewall to proxy the request to the front-end Exchange Servers. This “looping back” through the ISA firewall enables the internal users to accrue the same benefits provided by the ISA firewall’s Web Farm Publishing capabilities without having to resort to NLB on the front-end Exchange Server Web farm. While I am not a fan of looping back through the ISA firewall to access internal resources, this is a legitimate configuration for organizations who use a purpose-based deployment model where ISA firewalls or ISA firewall arrays are deployed for a specific purpose. For example, one array is dedicated to site to site and remote access VPN, another array is dedicated to outbound access control and another array is dedicated to Web and Server publishing.

I’ve covered certificate deployment in a number of other articles here on ISAserver.org and won’t go through the process in detail in this article. If you want more information on your options for CA deployments and how to obtain certificates for Exchange Web publishing scenarios, the best place to start is the ISA Server 2000 Exchange Deployment Kit. In my not so humble opinion, this is one of the best documentation projects of all time and I spent hundreds of hours putting it together. While aimed at ISA Server 2000, many of the principles are the same. You can find the ISA Server 2000 Exchange Deployment Kit at http://www.isaserver.org/img/upl/exchangekit/

I also did an ISA 2004 Exchange Deployment Kit that contains similar information, but might not go into the same level of detail on standing up a new PKI. However, it does take you through all the steps required for installing certificates on the Exchange Web servers and the ISA firewalls. You can find that at http://www.microsoft.com/technet/prodtechnol/isa/2004/deployment/default.mspx

The following summarizes what I did to deploy certificates in the scenario discussed in this article series:

  1. Install an enterprise CA on the domain controller. You don’t have to install the enterprise CA on a DC, it can be installed on a member server but I wanted to reduce the number of machines required for this lab. The advantage of using a Windows Server 2003 SP1 enterprise CA is that it will automatically populate each domain member’s machine certificate store with the CA certificate of the enterprise CA so that each domain member trusts certificates signed by that CA.
  2. After the enterprise CA was installed, I used the IIS Web Site Certificate Request Wizard on one of the FE Exchange Servers to request a Web site certificate. The common name on the Web site certificate is owa.msfirewall.org.
  3. I then exported this certificate, along with its private key, to a file. Then I copied the file to the other FE Exchange Server and to the ISA firewall
  4. After copying the file to the front-end Exchange Server and the ISA firewall, I imported the certificate with its private key into the Personal folder of the machine’s machine certificate store. This is crucial. You import it into the machine certificate store; you do not import the certificate into the user or service certificate store.

Make sure that all machines have the CA certificate from the enterprise CA installed on them. This should not be a problem for the Exchange Servers, but you might run into issues with the ISA firewall if you installed the ISA firewall software before joining the ISA firewall to the domain. The reason for this is that the RPC filter breaks the ISA firewall’s ability to automatically receive the enterprise CA’s certificate. In this case, you’ll need to manually import the CA certificate into the ISA firewall’s Trusted Root Certification Authorities machine certificate store.

If you find at the end of the configuration that certificates seem to be a problem, run the ISA firewall BPA. It does a great job at identifying certificate related issues and provided guidance on how to solve them.

Download the ISA firewall BPA at http://www.microsoft.com/downloads/details.aspx?familyid=d22ec2b9-4cd3-4bb6-91ec-0829e5f84063&displaylang=en

Configuring DNS to Support our Split DNS Infrastructure

By using the split DNS infrastructure we enable users to use the same names to reach the same resources regardless of location. In our current example, users will be able to reach https://owa.msfirewall.org/exchange from both the Internal and external network. The only difference is that the external users will connect to an external IP address on the ISA firewall and the internal users will connect to an internal IP address on the ISA firewall.

In order to support forms-based authentication and Web Farm Load Balancing for both internal and external users, we are going to have to depart from some of the conventions we used for ISA 2004 and get a bit more creative in our split DNS infrastructure.

We need to do two things:

  • Create a HOSTS file entry on the ISA firewall that resolves the name on the Web site certificate bound to the front-end Exchange Web site to the IP address of one of the array members. As you find out later, this is somewhat superfluous, since the Web farm Publishing feature enables us to get around this issue. However, I include this information for people who might not be using Web Farm publishing.
  • Configure the internal DNS to resolve the common name on the Web site certificate bound to the front-end Exchange Web site to the IP address used on the internal interface of the ISA firewall. This allows your internal clients to connect to the ISA firewall instead of directly to the front-end Exchange Servers. This is required if you want your internal clients to benefit from Web Farm Load Balancing.

The figure below reflects the configuration requirements.


Figure 1

This reminds me of something that I don’t think I’ve pointed out before but is worth mentioning. I highly recommend that when you select the naming infrastructure for your certificates, that you don’t use any actual machine names. This solves a lot of DNS related issues because you eliminate the problem of name collision in your DNS.

Discuss this article on the Web Boards at: http://tinyurl.com/fvflv

For example, suppose that one of the actual machine name of one of the front-end Exchange Server’s was OWA and that machine is a member of the msfirewall.org domain. Now suppose that the Web site certificate you want to use has the common/subject name owa.msfirewall.org. This would cause a big problem for us because the actual machine would need to have it’s DNS entry entered into the DNS database on the internal network. This would prevent us from configuring DNS to redirect connections from internal clients to the front-end array to the internal interface of the ISA firewall, with the end result being that internal clients would not be able to benefit from the ISA firewall’s FBA and Web Farm Publishing features.

Bottom Line:
Never use actual machine names for the Web Sites Certificates installed on the Exchange Web Servers and the ISA Firewall’s Web Listeners

Creating the Web Farm

ISA Server 2006 has a great new feature that enables you to publish “farms” of Web servers located behind the ISA firewall and it does this without requiring that you use NLB on the Web farm. The new ISA firewall’s Web Farm Publishing feature solves several problems we had with Web Farm publishing in ISA 2004:

  • When NLB was enabled on the Web farm and single affinity was enabled, all connections were forwarded to the same member of the farm. The reason for this was that the default setting on the Web Publishing Rules were to replace the client source IP address with the IP address of the ISA firewall (or ISA firewall array if NLB was enabled on an array). Since the NLB’d Web farm always saw the same source IP address, single affinity always directed the connection to the same server in the farm, which defeated the load balancing feature of NLB
  • A solution to this problem was to change the Web Publishing Rule so that the original client IP address was preserved. The problem with this solution was that you had to set the default gateway on the server farm members so that the ISA firewall array was in the response path to the Internet. Many organizations wanted to avoid this situation so as to prevent needless and senseless debates with the “network guys” who seem to endlessly try to harpoon our efforts at securing network assets.

The Web Farm Publishing solution checks for service health on each of the members of the farm. If a farm member is unavailable, then the ISA firewall removes it from the farm and does not forward connections to the downed member. When the ISA firewall detects that the farm member is back on line, the ISA firewall reactivates that member’s membership in the farm and starts to load balance connections to the server again. In an Exchange front-end scenario, users connected to one of the farm members are never aware of the downed server and are transparently redirected to another server in the farm.

Web Farm Publishing provides you the following advantages:

  • You never need to use NLB on the Web farm
  • It works well when NLB is enabled on the ISA firewall array, but does not require that NLB be enabled on the array
  • It provides load balancing and transparent failover and failback
  • You no longer need F5, Cisco Content Engine, or any other external load balancer, potentially saving you tens or hundreds of thousands of dollars (this feature alone should earn you a health bonus at the end of the year)
  • You don’t have to worry about affinity issues, because NLB is not used to load balance the connections. The ISA firewall can use a cookie based load balancing mechanism
  • You can drain a server before removing it from the Web farm, just like you do with NLB but without requiring NLB on the Web farm

In order to publish a Web farm, you have to create a Server Farm network element. You can do this in advance, or create one on the fly when you create the Web Publishing Rule. Since I’m talking about Web farms now, let’s go ahead and create a Server Farm network element.

NOTE:
The term “Server Farm” is a bit of a misnomer. In ISA firewall parlance, there are two types of publishing rules: Web Publishing Rules and Server Publishing Rules. Web Publishing Rules publish only Web servers and Server Publishing Rules can publish any protocol. The correct term for this network element would be “Web Farm” if we were to keep a consistent ISA firewall nomenclature.

Perform the following tasks to create the Server Farm network element:

  1. In the ISA firewall console, expand the array name and then click the Firewall Policy node in the left pane of the console. Click the Toolbox tab in the Task Pane. Click the Network Objects link in the Toolbox.
  2. In the Network Objects section, click the New menu and click Server Farm.
  3. Enter a name for the Web farm in the Server Farm name text box on the Welcome to the New Server Farm Wizard page and click Next.
  4. On the Servers page, click the Add button.


Figure 2

  1. On the Server Details page, click the Browse button to locate the first FE Exchange Server. Keep in mind that the servers available for browsing are those registered in the Active Directory. However, since the FE Exchange Servers must be in the Active Directory, they’ll be easy to find. Click OK.


Figure 3

  1. Repeat the steps to add other servers to the Web farm, then click Next.


Figure 4

  1. On the Server Farm Connectivity Monitoring page you configure how you want the ISA firewall to confirm the current health status of the servers in the Web farm. The default setting configures the ISA firewall to send either an HTTP or HTTPS GET request to the FQDN and path you configure in the Web Publishing Rule that will use this Server farm network element. You also have the options to use a ICMP PING request or establish a connection to a custom TCP socket (you enter the port number for the listening socket you want to connect to in the Connect to port text box).

    You can further customize the configuration of the connectivity monitor for this Server farm by clicking the Configure button.


Figure 5

  1. In the Advanced Farm Connectivity Verification dialog box you can customize the URL used to determine published server health status. Use this option when you want to override the URL used by the Web Publishing Rule. While I can’t think of a scenario where you would want to do this, there are more things in heaven and earth than what’s dreamed up in my philosophy. You also have the option to configure a custom HOST header if you need to use one that’s different than the HOST header that will be sent based on the Web Publishing Rule that publishes this Web farm. Click OK.


Figure 6

  1. Click Next on the Server Farm Connectivity Monitoring page.
  2. Click Finish on the Completing the New Server Farm Wizard page.
  3. A dialog box informing you that the Allow HTTP/HTTPS requests from ISA Server to selected servers for connectivity verifiers System Policy rule will be enabled. Click Yes to enable that System Policy Rule.


Figure 7

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

If you’re an experienced ISA 2004 firewall admin, you might wonder about certificate name mismatch issues. You might have wondered about this when configuring the server names in the array. From your experience with the dreaded 500 Server Error you might wonder how it will work, since in the past you had to forward the connections using the FQDN used in the common/subject name of the Web site certificate bound to the Exchange FE Web site.

The reason why this works is that the server names you enter in the definition of the Web farm are used internally; they are not used to construct the request that is made by the ISA firewall to the published Web site when the ISA firewall proxies the request. The name that will be used in the CONNECT will be the name you configure the ISA firewall to use in the Web Publishing Rule that publishes the Web farm. We’ll see how you do that in the next section on creating Web Publishing Rules for the OWA and RPC/HTTP sites.

It looks like I’ve used up all my space this week, so we’ll have to conclude the article with part 4, where I plan to go over the details of the OWA and RPC/HTTP Web Publishing Rules and then show you how to test the solution and confirm that everything is working correctly.

Discuss this article on the Web Boards at: http://tinyurl.com/fvflv

Summary

In this article we began the configuration of the network to support publishing an OWA and RPC/HTTP Web farm. We began with configuring the supporting DNS infrastructure and HOSTS files to support the solution. Then we moved on to a discussion on how the new ISA firewall’s Web farm load balancing feature works and then finished up by creating a new Web farm by using the New Server Farm wizard. In the next article I hope to finish up by going over the details of the Web Publishing Rules and then demonstrating how you can confirm that the load balancing and failover works properly. See you next week! –Tom.

If you missed the other parts in this article series please read:

About The Author

Tom Shinder is a Program Manager at Microsoft and has two decades of networking and security experience. He has written dozens of books, thousands of articles, and spoken at large industry conferences on the topics of IT infrastructure, Cloud computing, and cybersecurity. In his free time, Tom enjoys participating in equine prediction markets.

Read Next

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