Publishing an OWA Site in a Back to Back ISA Firewall Configuration (Part 1)

If you would like to read the next article in this series please go to Publishing an OWA Site in a Back to Back ISA Firewall Configuration (Part 2).

Publishing an OWA Site in a Back to Back ISA Firewall Configuration (Part 1)

by Thomas W Shinder MD, MVP

Have Questions about the article?
Ask at: http://forums.isaserver.org/ultimatebb.cgi?ubb=get_topic;f=23;t=000679

Remote users can connect to your Exchange Server from virtually any site in the world using the HTTP protocol by connecting to the Exchange Server’s Outlook Web Access (OWA) Web site. Exchange Server 2003 takes OWA to the next level. The Exchange Server 2003 OWA site provides much greater functionality than available with the Exchange 5.5 or Exchange 2000 OWA site, and provides a user experience that is very close to what you get with the full Outlook MAPI client.

OWA Web site publishing provides a viable alternative, both in terms of functionality and security, to secure Exchange RPC Publishing. Your job as the ISA firewall administrator is to provide remote users access to your Exchange Server 2003 OWA site and do so in a secure fashion.

Fortunately, it is possible to provide remote users a highly secure connection to your corporate OWA Web site. Security technologies that assure a protected link between the remote user and the OWA Web site include:

  • SSL connection between the OWA client and the ISA firewall. The SSL secured connection ensures that user credentials and data are always exchanged over an encrypted link.
  • SSL connection between the ISA firewall and the OWA site. This is accomplish using SSL to SSL bridging. You can no longer implicitly trust the corporate network, and therefore an end to end SSL connection is required.
  • Client certificate presentation can be enforced on the OWA directories; this requires the ISA firewall (and all other hosts) present a user certificate before it can connect to any of the OWA Web site directories
  • User (client) certificate authentication can be configured on the ISA firewall’s Incoming Web Requests listener to require remote OWA client to present a user certificate to authenticate with the ISA firewall before it forwards credentials to the OWA site
  • OWA forms-based authentication enables the ISA firewall to generate the log on form. This prevents unauthenticated connections from reaching the OWA site, because the ISA firewall (rather than the OWA site) generates the log on form.
  • Delegation of basic credentials can be configured on the ISA firewall so that the firewall forwards the credentials to the OWA Web site. This prevents unauthenticated hosts from sending a single packet to the OWA Web site and prevents attackers from leveraging the unauthenticated connection to launch an attack against the Exchange OWA Web site.
  • Microsoft enterprise CA’s allow tight control over certificates; this can be used to mitigate the risk of clients connecting from untrusted hosts, such as airport kiosks or home computers that do not meet corporate security standards. Access and session control features provided by ISA firewall’s OWA Forms-based authentication further enhances security.

Secure OWA Web site publishing using the ISA firewall provides a higher level of security than can be accomplished with virtually any other firewall in its class, and provides a level of functionality and security second only to secure Exchange RPC Publishing.

We will discuss the following procedures in step-by-step detail in this article series:

  • Issuing and Binding a Web Site Certificate to the OWA Web site on the Exchange Server In order to have an end to end SSL connection, the ISA firewalls must be able to perform SSL to SSL bridging. The back-end ISA firewall will forward the connection requests received from the front-end ISA firewall as a new SSL connection between the back-end ISA firewall’s internal interface and the Exchange OWA site.
  • Exporting the OWA Web Site Certificate to a File (Including the Site’s Private Key) After the OWA site receives a certificate, that certificate is exported to a file. The private key must be included in the exported certificate file.
  • Configuring the OWA Site to Force SSL Encryption and Basic Authentication This is an optional step, but increases security because it requires that all hosts use SSL to communicate with the OWA site.
  • Importing the OWA Web Site Certificate into the Back-end ISA Firewall’s Machine Certificate Store After exporting the OWA Web site’s Web site certificate, that file is copied to the back-end ISA firewall. The certificate (along with its private key) is imported into the back-end ISA firewall’s machine certificate store.
  • Running the Outlook Web Access Publishing Wizard and creating the HOSTS file entry for the OWA Web Site Address on the Back-end ISA Firewall At the back-end ISA firewall, we create a HOSTS file entry so that the name on the certificate (and the same name which is included on the “To” tab of the Web Publishing Rule) resolves to the actual IP address of the OWA site on the Default Internal Network.
  • Creating a Web Publishing Rule for the Web Enrollment Site on the Back-end ISA Firewall This is an optional step. We create this rule so that clients on the external network can access a CA certificate to place into their own machine certificate store. If you only want domain members to access the OWA site, and if you have an enterprise CA, then the domain members will already have the CA certificate in their machine certificate stores (for Windows Server 2003 domains).
  • Creating an “All Open” Access Rule on the Back-end ISA Server 2004 Firewall This is an optional step that we use for testing purposes only. At a minimum, we need a rule that allows DNS queries outbound from the Default Internal Network behind the back-end ISA firewall to the Default External Network.
  • Importing the OWA Web Site Certificate into the Front-end ISA Firewall’s Machine Certificate Store The front-end ISA firewall will also need to impersonate the OWA Web site. We will perform the same procedure on the front-end ISA firewall as we preformed on the back-end ISA firewall. We’ll import the OWA Web site certificate (with its private key) into the machine certificate store on the front-end ISA firewall.
  • Running the Outlook Web Access Publishing Wizard and Creating the HOSTS file entry for the Back-end ISA Firewall on the Front-end ISA Firewall The HOSTS file entry maps the name on the Web site certificate to the IP address on the back-end ISA firewall that is being used on the Web listener used on the OWA Web Publishing Rule on the back-end ISA firewall. We will also create the Web Publishing Rule on the front-end ISA firewall that publishes the OWA site through the back-end ISA firewall’s Web listener’s IP address.
  • Creating an “All Open” Access Rule on the Front-end ISA Firewall This rule is not required, but it used for demonstration purposes in this example. You can create an Access Rule that allows all outbound traffic from the IP addresses bound to the external interface of the back-end ISA firewall only. If you have other servers in the DMZ segment between the front-end and back-end ISA firewalls, then you can create a custom firewall policy on the front-end ISA firewall to allow outbound traffic from those devices, as required.
  • Creating a Web Publishing Rule for the Web Enrollment Site on the Front-end ISA Firewall This is an optional step. This rule enables external hosts access to the enterprise CA’s Web enrollment site. If you plan to support only domain members, or hosts that must be on the corporate network as some time, then this rule is not required.
  • Configuring the public DNS to resolve the name of the OWA site The external hosts must be able to resolve the name of the OWA site to the IP address on the external interface of the front-end ISA firewall. This name must also be the same name included in the subject/common name of the OWA Web site certificate used on the front-end ISA firewall’s Web listener.
  • Installing CA certificates on the OWA clients This is an optional step. If you do not install the CA certificate on the Web clients, then users will see an error dialog box informing them that they do not trust the CA that issued the Web site certificate presented by the front-end ISA firewall. However, users will be able to click through this dialog box. If you do install the CA certificate on the Web clients, then the dialog box will not appear.
  • Creating a HOSTS File Entry on the OWA Client Machine In a production environment, this step will not be required, because the public DNS will already have the name of the OWA site included in the authoritative DNS zone for that domain. However, in the lab setup we’re using to demonstrate publishing OWA sites in the back to back ISA firewall configuration, we’ll use the HOSTS file entry so that I don’t have to go through the procedure of configuring a public DNS server J.
  • Making the Connection to the OWA Web Site Here we test the solution.

In this article we will focus on publishing an OWA Web site in a back to back ISA firewall environment. The back to back ISA firewall configuration consists of a front-end ISA firewall with an interface directly connected to the Internet, and a back-end ISA Server 2004 firewall with an interface connected to the Internal network. Both the front-end and back-end ISA Server 2004 firewalls have an interface connected to a DMZ segment between the firewalls.

The network diagram below provides a high level overview of the network on which this document is based.


Figure 1

There are some interesting aspects to this configuration which might appear to deviate from what you might understand about the ISA firewall. Its important to note that this network setup doesn’t represent a best practices comment, and is used only to demonstrate the solution discussed in the article series.

In the sample network diagram you will notice that the front-end ISA firewall doesn’t have a default gateway configured. The reason for this is that its not required on the example network. However, in a production network you would include a default gateway on the front-end ISA firewall so that hosts on the corporate network, and even on the DMZ segment, will be able to access the Internet.

You will also notice that there is no default gateway on the back-end ISA firewall. Again, this is for demonstration purposes for this solution only. In a production environment, where you need to enable hosts on the DMZ segment and the corporate network outbound access, then you would need to either configure the back-end ISA firewall to use the internal interface of the front-end ISA firewall as its default gateway, or you could configure firewall chaining between the back-end and front-end ISA firewalls. However, if you configure firewall chaining between the back-end and front-end ISA firewalls, you must not require user authentication on the front-end firewall, as the authentication attempt will fail and that will cause the firewall chaining configuration to fail.

The reason why the configuration works in our OWA publishing example is that the front-end ISA firewall forwards the connection to the external interface of the back-end ISA firewall and the back-end ISA firewall forwards the connection to the OWA site. In both cases, the ISA firewalls change the source IP address of the connection to its own IP address.

So, when the front-end ISA firewall forwards the connection to the external interface of the back-end ISA firewall, the back-end ISA firewall “sees” the source IP address as the IP address on the internal interface of the front-end ISA firewall. Since the internal interface of the front-end ISA firewall and the external interface of the back-end ISA firewall are on the same network ID, there is no need for a default gateway on the back-end ISA firewall. When the back-end ISA firewall forwards the connection to the OWA site, the OWA site “sees” the source IP address as that of the internal interface of the back-end ISA firewall. Since the OWA site and the internal interface of the back-end ISA firewall are on the same network ID, there is no need for a default gateway setting on the OWA server (although there is one in this example).

Note:
If you want to replicate the lab environment so that you can also test outbound connections from the Default Internal Network behind the back-end ISA firewall, then configure the default gateway on the external interface of the back-end ISA firewall to be 10.0.1.1.

The table below provides information about each of the hosts on this sample network.

Table 1: Back to Back ISA Server 2004 Firewall Network Parameter

Lab Network Details

Setting

EXCHANGE
2003BE

OWA Client

Front-end ISA

Back-end ISA

IP Address

10.0.0.2

192.168.1.90

Int: 10.0.1.1

Ext: 192.168.1.70

Int: 10.0.0.1

Ext: 10.0.1.2

Default Gateway

10.0.0.1

None

None

None
or

10.0.1.1 (if you want to test outbound access from the back-end ISA firewall’s Default Internal Network)

DNS

10.0.0.2

None

None

10.0.0.2

WINS

10.0.0.2

None

None

10.0.0.2

OS

Windows Server 2003

Windows XP

Windows Server 2003

Windows Server 2003

Services

DC

DNS

WINS

DHCP

RADIUS

Enterprise CA

IIS:

WWW

SMTP

NNTP

FTP

ISA Server 2004

ISA Server 2004

In this, part 1 of a two-part series on publishing OWA Web sites using a back to back ISA firewall configuration, we’ll go over the following procedures:

  • Issuing and binding the Web site certificate to the OWA Web site
  • Export the OWA Web site certificate to a file – including the site’s private key
  • Configuring the OWA site to force SSL encryption and Basic authentication
  • Import the OWA Web site certificate into the back-end ISA firewall’s machine certificate store
  • Create a HOSTS file entry for the OWA Web site address and running OWA Web Publishing Rule Wizard
  • Create an “all open” Access Rule on the back-end ISA firewall
  • Import the OWA Web site certificate into the front-end ISA firewall’s machine certificate store

Issuing and Binding a Web Site Certificate to the OWA Web Site

In order to perform SSL to SSL bridging, both the front-end and back-end ISA firewalls must establish two SSL connections. On the back-end ISA firewall, the first SSL connection is between the front-end ISA firewall and the back-end ISA firewall, and the second SSL connection is between the back-end ISA firewall and the OWA Web site. On the front-end ISA firewall, the first SSL connection is between the OWA client and the second SSL connection is between the front-end ISA firewall and the external interface of the back-end ISA firewall.

The same Web site certificate will be used on the OWA site, the back-end ISA firewall and the front-end ISA firewall. The first step is to request a Web site certificate for the OWA site.

Perform the following steps to request a Web site certificate for the OWA Web Site:

  1. At the EXCHANGE2003BE machine, click Start and point to Administrative Tools. Click Internet Information Services (IIS) Manager.
  2. In the left pane of the Internet Information Services (IIS) Manager console, expand the Web Sites node and click the Default Web Site. Right click Default Web Site and click Properties.
  3. On the Default Web Site Properties dialog box, click the Directory Security tab.
  4. On the Directory Security tab, click the Server Certificate button in the Secure communications frame.
  5. On the Welcome to the Web Server Certificate Wizard page, click Next.
  6. On the Server Certificate page, select the Create a new certificate option and click Next.


Figure 2

  1. On the Delayed or Immediate Request page, select the Send the request immediately to an online certificate authority option and click Next.


Figure 3

  1. On the Name and Security Settings page, accept the default settings and click Next.
  2. On the Organization Information page, enter your organization’s name in the Organization text box and your Organizational Unit’s name in the Organizational Unit text box. Click Next.
  3. On the Your Site’s Common Name page, enter the common name of the site. The common name is the name that external and internal users will use to access the site. For example, if users will enter https://owa.msfirewall.org into the browser to access the OWA site, you would make the common name owa.msfirewall.org. In our current example, we will enter owa.msfirewall.org into the Common name text box. The value you enter in the Common name page will be reflected in the subject name on the certificate itself. This is a critical setting. If you do not enter the correct common name, you will see errors when attempting to connect to the secure OWA site. Click Next.


Figure 4

  1. On the Geographical Information page, enter your Country/Region, State/province and City/locality in the text boxes. Click Next.
  2. On the SSL Port page, accept the default value, 443, in the SSL port this web site should use text box. Click Next.
  3. On the Choose a Certification Authority page, accept the default selection in the Certification authorities list and click Next.
  4. Review the settings on the Certificate Request Submission page and click Next.
  5. Click Finish on the Completing the Web Server Certificate Wizard page.
  6. Notice that the View Certificate button is now available. This indicates that the Web site certificate has been bound to the OWA Web site and can be used to enforce secure SSL connections to the Web site.


Figure 5

  1. Click OK in the Default Web Site Properties dialog box.

Export the OWA Web Site Certificate to a File – Including the Site’s Private Key

The ISA firewall impersonates the OWA Web site when the OWA client establishes the first SSL link between itself and the ISA Server 2004 firewall. In order for the ISA Server to do this, you must export the Web site certificate and import that certificate into the ISA Server 2004 firewall’s machine certificate store. It is important that you export the Web site’s private key when you export the certificate to a file. If the private key is not included in the file, you will not be able to bind the certificate to a Web Listener on the ISA Server 2004 firewall.

Perform the following steps to export the Web site certificate with its private key to a file:

  1. In the Internet Information Services (IIS) Manager console, expand the Web Sites node in the left pane of the console and then click the Default Web Site. Right click the Default Web Site and click Properties.
  2. In the Default Web Site Properties dialog box, click the Directory Security tab.
  3. On the Directory Security tab, click the View Certificate button in the Secure communications frame.
  4. In the Certificate dialog box, click the Details tab. On the Details tab, click the Copy to File button.


Figure 6

  1. Click Next on the Welcome to the Certificate Export Wizard page.
  2. On the Export Private Key page, select the Yes, export the private key option and click Next.


Figure 7

  1. On the Export File Format page, select the Personal Information Exchange – PKCS #12 (.PFX) option. Put a checkmark in the Include all certificates in the certification path if possible checkbox and remove the checkmark from the Enable strong protection (requires IE 5.0, NT 4.0 SP4 or above) checkbox. Click Next.


Figure 8

  1. On the Password page, enter a Password and then enter it again in the Confirm Password field. Click Next.
  2. On the File to Export page, enter c:\owacert in the File name text box. Click Next.
  3. Click Finish on the Completing the Certificate Export Wizard page.
  4. Click OK in the Certificate dialog box.
  5. Click OK in the Default Web Site Properties dialog box.
  6. Copy the owacert.pfx file to the root of the C:\ drive on both the front-end and back-end the ISA Server 2004 firewall machines.

Note:
We will use the same certificate file on both the front-end and back-end ISA Server 2004 firewall machines, so make sure to copy the file to both firewalls.

Configuring the OWA Site to Force SSL Encryption and Basic Authentication

As a best security practice, you should prevent data and user credentials from being visible to intruders who may install network protocol analyzers (sniffers) on the corporate network. If unencrypted communications are allowed through the corporate network, then anyone with a network analyzer will be able to easily read username and passwords as they move over the corporate network.

This can be accomplished by forcing all connections to the OWA Web site directories to use SSL. In addition, you should configure the OWA directories to use basic authentication only. This prevents browser compatibility issues. You do not need to worry about using basic authentication because the user credentials are secured by the SSL link. Note that this is not required. You can still use integrated authentication on the OWA directories, but you may encounter some issues depending on your deployment. I highly recommend that you force SSL on the OWA directories for all users, then you don’t need to worry about using Basic authentication.

Perform the following steps to configure the OWA Web site to force SSL connections and basic authentication on the OWA Web sites:

  1. Click Start, point to Administrative Tools and click on Internet Information Services. In the Internet Information Services (IIS) Manager, expand your server name and then expand the Default Web Site node in the left pane of the console.

The three OWA Web site directories that you will make accessible to remote users are:

/Exchange
/ExchWeb
/Public

  1. We want the ISA firewall to always negotiate an SSL connection when proxying communications between these directories and the remote OWA client.Start by clicking on the Exchange directory so that it is highlighted. Then right click on an empty area in the right pane of the console. Click the Properties command.
  2. Click on the Directory Security tab. In the Authentication and access control frame, click the Edit button.
  3. In the Authentication Methods dialog box, remove the checkmark from all checkboxes except the Basic authentication (password is sent in clear text) checkbox. Place a checkmark in the Basic authentication checkbox. Click Yes in the dialog box warning you that the credentials should be protected by SSL. Enter your domain name in the Default domain text box. In this example, the domain name is MSFIREWALL. Click OK.


Figure 9

  1. Click Apply and then click OK in the Exchange Properties dialog box.
  2. Repeat these steps with the /Exchweb and /Public directories in the left pane of the console. Close the Internet Information Services (IIS) Manager console after you have forced basic authentication on the Exchange, Exchweb and Public folders.

The next step is to force the ISA firewall’s Web Proxy filter (it’s a filter now, not a service) to use SSL when connecting to the OWA directories. Perform the following steps to force all connections to the OWA directories to negotiate an SSL connection:

  1. Click Start, point to Administrative Tools and click Internet Information Services. In the Internet Information Services (IIS) Manager, expand your server name and then expand the Default Web Site node in the left pane of the console.

Next, you will force an SSL connection on the directories the remote OWA users will access through the ISA Server. These directories are:

/Exchange
/Exchweb
/Public

  1. Click the Exchange node in the left pane of the console to highlight it. Right click an empty area in the right pane of the console and click the Properties command.
  2. Click the Directory Security tab in the Exchange Properties dialog box. Click the Edit button in Secure communications frame.
  3. In the Secure Communications dialog box, put a checkmark in the Require secure channel (SSL) checkbox. Put a checkmark in the Require 128-bit encryption checkbox. Click OK.


Figure 10

  1. Click Apply and then click OK in the Exchange Properties dialog box.
  2. Repeat the procedure to force an SSL connection on the /Exchweb and /Public directories in the left pane of the console. Close the Internet Information Services (IIS) Manager console after forcing SSL on the Exchange, Exchweb and Public directories.

Have Questions about the article?
Ask at: http://forums.isaserver.org/ultimatebb.cgi?ubb=get_topic;f=23;t=000679

Importing the OWA Web Site Certificate into the Back-end ISA Firewall’s Machine Certificate Store

The OWA site’s Web site certificate must be imported into the back-end ISA firewall’s machine certificate store before it can be bound to the OWA Web Listener on the back-end ISA firewall. Only after the Web site certificate (along with its private key) is imported into the back-end ISA firewall’s machine certificate store will the certificate be available for binding.

Note:
If you do not need the Web site certificate as being available in the ISA firewall console when you configure the Web listener, this indicates that you did not export the private key. Repeat the OWA Web site certificate export and include the private key in the file.

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

  1. At the back-end ISA firewall, click Start and click on the Run command. Enter mmc in the Open text box and click OK. In the Console 1 console, click the File menu and click the Add/Remove Snap-in command.
  2. Click the Add button in the Add/Remove Snap-in dialog box.
  3. Click the Certificates entry in the Available Standalone Snap-in list on the Add Standalone Snap-in dialog box. Click Add.
  4. Select the Computer account option on the Certificates snap-in page. Click Next.
  5. On the Select Computer page, select the Local computer: (the computer this console is running on) option and click Finish.
  6. Click Close on the Add Standalone Snap-in page.
  7. Click OK in the Add/Remove Snap-in dialog box.
  8. Right click the Personal node in the left pane of the console, point to All Tasks and click Import.
  9. Click Next on the Welcome to the Certificate Import Wizard.
  10. Click the Browse button and locate the certificate file. Click Next after the file path and name appear in the File name text box.


Figure 11

  1. On the Password page, enter the password for the file. Do not put a checkmark in the checkbox labeled Mark this key as exportable. This will allow you to back up or transport you keys at a late time. You should not use this option because this machine is a bastion host with an interface in a perimeter network or on the Internet and may be compromised. The compromiser might be able to steal the private key from this machine if it is marked as exportable. Click Next.
  2. On the Certificate Store page, confirm that the Place all certificate in the follow store option is selected and that it says Personal in the Certificate store box. Click Next.
  3. Review the settings on the Completing the Certificate Import page and click Finish.
  4. Click OK on the Certificate Import Wizard dialog box informing you the import was successful.
  5. You will see the Web site certificate and the CA certificate in the right pane of the console. The Web site certificate has the FQDN assigned to the Web site. This is the name external users use to access the OWA site. The CA certificate must be placed into the Trusted Root Certification Authorities\Certificates store so that this machine will trust the Web site certificate installed on it. Double click the Web site certificate in the right pane of the console.


Figure 12

  1. Expand the Trusted Root Certification Authorities node in the left pane of the console and scroll down to the CA certificate of the enterprise CA that issued the Web site certificate. Note that the enterprise CA certificate automatically appears in the Trusted Root Certification Authorities because we have an enterprise CA and the ISA Server 2004 firewall belongs to the same domain as the enterprise CA machine. If you used a standalone CA, or if the ISA Server 2004 firewall did not belong to the same domain as the enterprise CA, you would need to copy the enterprise CA’s certificate into the Trusted Root Certification Authorities\Certificates node. In the current example, we could accomplish this by right clicking the EXCHANGE2003BE CA certificate and then clicking the Copy command. Then we would click the \Trusted Root Certification Authorities\ node in the left pane of the console and click the Paste button in the MMC button bar.

Creating a HOSTS File Entry for the OWA Web Site Address and Running the Outlook Web Access Publishing Wizard

In a production environment, you should create a split DNS infrastructure that enables hosts on the internal and external networks to properly resolve the name of the OWA Web site. We have not configured a split DNS infrastructure in our current example, so we will use a HOSTS file on the back-end ISA firewall that enables the firewall to resolve the name of the OWA site to the site’s Internal IP address.

Note:
Even if you have a split DNS, you can still place the HOSTS file entry on the ISA firewall. However, be aware that HOSTS and LMHOSTS file entries are a common name resolution troubleshoot issue, as network admins often experience name resolution issues and forget that there are entries in either the HOSTS or LMHOSTS file.

Perform the following steps on the back-end ISA firewall to create the HOSTS file entry that maps the OWA site to its Internal address:

  1. Open Windows Explorer, navigate to \WINDOWS\system32\drivers\etc directory and open the hosts file.
  2. In the Open With dialog box, select Notepad and click OK.
  3. The HOSTS file is opened in Notepad. Add a line at the end of the hosts file that resolves the name in the redirect to the IP address that can reach the OWA server on the internal network. In the current example, add the following line at the end of the HOSTS file:

10.0.0.2     owa.msfirewall.org

 “10.0.0.2” is the IP address of the OWA server machine on the internal network. Ensure that you press ENTER after you add this line to the hosts file to ensure that there is an empty line at the end of the file.


Figure 13

  1. Close Notepad and click Yes to save the changes made to the file.

Now we’re ready to create the OWA Web Publishing Rule on the back-end ISA firewall. Perform the following steps to securely publish the Exchange OWA Web site:

  1. In the Microsoft Internet Security and Acceleration Server 2004 management console, expand the server name and click the Firewall Policy node. Click the Tasks tab in the Task Pane. Click the Publish a Mail Server link.
  2. On the Welcome to the New Mail Server Publishing Rule Wizard page, enter a name for the rule in the Mail Server Publishing Rule name text box. In this example, we will call it Publish OWA Web Site. Click Next.
  3. On the Select Access Type page, select the Web client access (Outlook Web Access (OWA), Outlook Mobile Access, Exchange Server ActiveSync option and click Next.


Figure 14

  1. On the Select Services page, put a checkmark in the Outlook Web Access checkbox. Confirm that there is a checkmark in the Enable high bit characters used by non-English character sets. This option allows OWA users to access mail using non-English character sets. Click Next.


Figure 15

  1. On the Bridging Mode page, select the Secure connection to clients and mail server option and click Next. This option creates a Web Publishing Rule that ensures a secure SSL connection from the client to the OWA Web site. This prevents the traffic from moving in the clear, where an intruder can sniff the traffic and intercept valuable information. The external client that makes an SSL connection expects that traffic to be secure from end to end.


Figure 16

  1. On the Specify the Web Mail Server page, enter the name for the Internal OWA Web site in the Web mail server text box. In this example, we will use the name owa.msfirewall.org. Note that this is the name used for the Exchange Server site on the internal network and this is the common name on the OWA Web site’s certificate. You could use an IP address, but that would create problems with the SSL connection between the internal interface of the ISA firewall and the Exchange OWA site. You can use either a split DNS or a HOSTS file entry on the ISA firewall to resolve this name to the IP address used by the Exchange Server on the internal network. Click Next.


Figure 17

  1. On the Public Name Details page, select the This domain name (type below) option in the Accept requests for list. Enter the name external users will use to access the OWA Web site in the Public name text box. In this example, the external users will use the name owa.msfirewall.org. Again, this is the name the external users use when accessing the Web site, and this is also the common name on the Web site certificate. This is the name the user enters into his browser in the browser’s Address bar. Click Next.


Figure 18

  1. On the Select Web Listener page, click the New button. The Web listener works like the Web listener in ISA 2000, but with new ISA firewall, you have more options. For example, you can create a separate Web listener for SSL and non-SSL connections on the same IP address. In addition, the Web listener settings are no longer global, and you can configure separate settings for each listener, limited only by the number of addresses bound to the external interface of the ISA firewall.
  2. On the Welcome to the New Web Listener Wizard page, enter a name for the listener in the Web listener name text box. In this example, we will use the name OWA SSL Listener. Click Next.
  3. On the IP Addresses page, put a checkmark in the External checkbox. Click the Address button.
  4. In the External Network Listener IP Selection dialog box, select the Specified IP addresses on the ISA Server computer in the select network option. Click the external IP address on the ISA firewall that you want to listen for incoming requests to the OWA site in the Available IP Addresses list. In this example, we will select 10.0.1.2. Click Add. The IP address now appears in the Selected IP Addresses list. Click OK.
  5. Click Next on the IP Addresses page.
  6. On the Port Specification page, remove the checkmark from the Enable HTTP checkbox. Place a checkmark in the Enable SSL checkbox. Leave the SSL port number at 443. By configuring this listener to use only SSL, you can configure a second listener with different settings that is dedicated for non-SSL connections.
  7. Click the Select button. In the Select Certificate dialog box, click the OWA Web site certificate that you imported into the ISA firewall’s machine certificate store and click OK. Note that this certificate will appear in this dialog box only after you have installed the Web site certificate into the ISA Server 2004 firewall’s machine certificate store. In addition, the certificate must contain the private key. If the private key was not included, the certificate will not appear in this list.


Figure 19

  1. Click Next on the Port Specification page.
  2. Click Finish on the Completing the New Web Listener page.
  3. The details of the Web listener now appear on the Select Web Listener page. Click Edit.


Figure 20

  1. Click Next on the Select Web Listener page.
  2. On the User Sets page, accept the default entry, All Users, and then click Next. Note that this does not mean that all users will be able to access the OWA site. Only users who can authenticate successfully will be able to access the site. The actual authentication is done by the OWA site, using the credentials that the ISA firewall forwards to it (embedded in an HTTP header). You cannot have the ISA firewall itself and the OWA site authenticate the user. This means you must allow All Users access to the rule. An exception to this rule is when users authenticate to the ISA firewall itself using user (client) certificate authentication. 
  3. Click Finish on the Completing the New Mail Server Publishing Rule Wizard page.
  4. Click Apply to save the changes and update the firewall policy.
  5. Click OK in the Apply New Configuration dialog box.

Publishing the Web Enrollment Site

The external OWA client machine needs a CA certificate in order to trust the Web site certificate on the front-end ISA Server 2004 firewall when it creates the SSL link to the front-end firewall. There are a number of ways this can be accomplished, but the easiest way is to make the enterprise CA’s Web enrollment site available to the external host. We can accomplish this by creating Web Publishing Rules on both the back-end and front-end ISA firewalls.

Perform the following steps on the back-end ISA firewall to publish the enterprise CA’s Web enrollment site:

  1. In the Microsoft Internet Security and Acceleration Server 2004 management console, expand the server name and click the Firewall Policy node.
  2. In the Task Pane, click the Tasks tab. On the Tasks tab, click the Publish a Web Server link.
  3. Enter a name for the Web Publishing Rule on the Welcome to the New Web Publishing Rule Wizard page. In this example, we will enter the name Publish Web Enrollment Site in the Web publishing rule name text box. Click Next.
  4. Select the Allow option on the Select Rule Action page.
  5. On the Define Website to Publish page, enter the IP address of the enterprise CA’s Web site in the Computer name or IP address text box. In this example, the IP address is 10.0.0.2, so we will enter that value into the text box. In the Path text box, enter /certsrv/*. Click Next.


Figure 21

  1. On the Public Name Details page, select the This domain name (type below) option in the Accept request for list box. In the Public name text box, enter the IP address on the external interface of the back-end ISA Server 2004 firewall. In this example, the back-end ISA Server 2004 firewall’s external address is 10.0.1.2, so we will enter that value into the text box. Enter /certsrv/* into the Path (optional) text box. Click Next.


Figure 22

  1. On the Select Web Listener page, click the New button.
  2. On the Welcome to the New Web Listener page, enter a name for the rule in the Web listener name text box. In this example, we will name the listener HTTP Listener, to indicate the IP address on which the listener is listening. Click Next.
  3. On the IP addresses page, put a checkmark in the External checkbox and click Next.
  4. On the Port Specification page, accept the default settings. Confirm that there is a checkmark in the Enable HTTP checkbox and that the value 80 is in the HTTP port text box. Click Next.


Figure 23

  1. Click Finish on the Completing the New Web Listener Wizard page.
  2. Click Next on the Select Web Listener page.
  3. Accept the default setting, All Users, on the User Sets page and click Next.
  4. Click Finish on the Completing the New Web Publishing Rule Wizard page.
  5. Right click the Publish Web Enrollment Site rule and click Properties.
  6. On the Publish Web Enrollment Site Properties dialog box, click the Paths tab. On the Paths tab, click the Add button. In the Path mapping dialog box, add the entry /CertControl/* in the Specify the folder on the Web site that you want to publish. To publish the entire Web site, leave this field blank. Click OK.


Figure 24

  1. Click Apply and then click OK in the Publish Web Enrollment Site Properties dialog box.
  2. Click Apply to save the changes and update the firewall policy.
  3. Click OK in the Apply New Configuration dialog box.

Creating an “All Open” Access Rule on the Back-end ISA Firewall

The Exchange Server needs to send outbound mail and perform DNS lookups against Internet DNS servers. The Exchange Server may also need access to other protocols, such as NNTP, HTTP, HTTPS and POP3. In a production environment, you should determine in advance the exact protocols the Exchange Server requires for outbound access. In addition to the Exchange Server’s requirements, you also need to determine what type of access you want to enable for other users located on the back-end ISA firewall’s Protected Networks.

In the current example, we will simplify the process by allowing the Exchange Server access to all protocols. Note that we do this only for demonstration purposes and you should not allow the Exchange Server outbound access for all protocols in a production network. This goes for all other users and computers as well. You should not create all open rules for other than demonstration and testing purposes.

Perform the following steps on the back-end ISA Server 2004 firewall to create the “all open” Access Rule:

  1. In the back-end ISA firewall’s Microsoft Internet Security and Acceleration Server 2004 management console, expand the server name and then click the Firewall Policy node.
  2. In the Firewall Policy node, click the Tasks tab in the Task Pane. On the Task Pane, click the Create New Access Rule link.
  3. On the Welcome to the New Access Rule Wizard page, enter All Open for Exchange Server in the Access Rule name text box and click Next.
  4. On the Rule Action page, select the Allow option and click Next.
  5. On the Protocols page, select the All outbound traffic option in the This rule applies to list and click Next.
  6. On the Access Rule Sources page, click the Add button.
  7. In the Add Network Entities dialog box, click the New menu and then click Computer.
  8. In the New Computer Rule Element dialog box, enter Exchange Server in the Name text box. Enter 10.0.0.2 in the Computer IP Address text box. Click OK.
  9. In the Add Network Entities dialog box, click the Computers folder and then double click the Exchange Server entry. Click Close.
  10. Click Next on the Access Rule Sources page.
  11. On the Access Rule Destinations page, click Add.
  12. In the Add Network Entities dialog box, click the Networks folder and then double click the External entry. Click Close.
  13. Click Next on the Access Rule Destinations page.
  14. Click Next on the User Sets page.
  15. Click Finish on the Completing the New Access Rule Wizard page.

Importing the OWA Web Site Certificate into the Front-end ISA Firewall’s Machine Certificate Store

The Web site certificate must be imported into the front-end ISA firewall’s machine certificate store before it can be bound to the OWA Web Listener. Only after the Web site certificate (along with its private key) is imported into the firewall’s machine certificate store will the certificate be available for binding.

Perform the following steps to import the OWA server’s Web site certificate into the front-end ISA firewall’s machine certificate store:

  1. At the front-end ISA firewall machine, click Start and click on the Run command. Enter mmc in the Open text box and click OK. In the Console 1 console, click the File menu and click the Add/Remove Snap-in command.
  2. Click the Add button in the Add/Remove Snap-in dialog box.
  3. Click the Certificates entry in the Available Standalone Snap-in list on the Add Standalone Snap-in dialog box. Click Add.
  4. Select the Computer account option on the Certificates snap-in page. Click Next.
  5. On the Select Computer page, select the Local computer: (the computer this console is running on) option and click Finish.
  6. Click Close on the Add Standalone Snap-in page.
  7. Click OK in the Add/Remove Snap-in dialog box.
  8. Right click the Personal node in the left pane of the console, point to All Tasks and click Import.
  9. Click Next on the Welcome to the Certificate Import Wizard.
  10. Click the Browse button and locate the certificate file. Click Next after the file path and name appear in the File name text box.
  11. On the Password page, enter the password for the file. Do not put a checkmark in the checkbox labeled Mark this key as exportable. This will allow you to back up or transport you keys at a late time. You should not use this option because this machine is a bastion host with an interface in a perimeter network or on the Internet and may be compromised. The compromiser might be able to steal the private key from this machine if it is marked as exportable. Click Next.
  12. On the Certificate Store page, confirm that the Place all certificate in the follow store option is selected and that it says Personal in the Certificate store box. Click Next.
  13. Review the settings on the Completing the Certificate Import page and click Finish.
  14. Click OK on the Certificate Import Wizard dialog box informing you the import was successful.
  15. You will see the Web site certificate and the CA certificate in the right pane of the console. The Web site certificate has the FQDN assigned to the Web site. This is the name external users use to access the OWA site. The CA certificate must be placed into the Trusted Root Certification Authorities\Certificates store so that this machine will trust the Web site certificate installed on it.


Figure 25

  1. Right click the EXCHANGE2003BE certificate in the right pane of the console and click Cut.


Figure 26

  1. Click the \Trusted Root Certification Authorities\Certificates node and click the Paste button in the mmc button bar.
  2. The CA certificate now appears in the \Trusted Root Certification Authorities\Certificates node in the right pane.


Figure 27

Have Questions about the article?
Ask at: http://forums.isaserver.org/ultimatebb.cgi?ubb=get_topic;f=23;t=000679

Summary

In this, part 1 of a two part series on publishing OWA sites in a back to back ISA firewall configuration, we went over the basic principles of OWA Web site publishing and the procedures required to get the solution to work. We created a Web site certificate for the OWA Web site, and exported the certificate with its private key so that it could be imported into the machine certificate stores on both the front-end and back-end ISA firewall. We also addressed name resolution issues and created the OWA Web Publishing Rule on the back-end ISA firewall. In part 2 of this series, we will complete the configuration on the front-end ISA firewall and test the configuration from an external Web browser OWA client.

If you would like to read the next article in this series please go to Publishing an OWA Site in a Back to Back ISA Firewall Configuration (Part 2).


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