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

If you missed the first article in this series please read Publishing an OWA Site in a Back to Back ISA Firewall Configuration (Part 1).

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

by Thomas W Shinder MD, MVP

In part 1 of this two part series on configuring OWA access in a back to back ISA firewall configuration, we focused on the back-end infrastructure. In this, part 2 of the series, we’ll turn our attention to the front-end ISA firewall infrastructure and finish out by testing the solution.

In this article we’ll go over the following procedures:

• 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. Note that in order to have outbound access from the Internal network located behind the back-end ISA firewall, you will need to configure the back-end ISA firewall as a SecureNAT client of the upstream ISA firewall, or make the back-end ISA firewall a Firewall client of the upstream (using Firewall chaining), or make the back-end ISA firewall a Web proxy client of the upstream (via Web proxy chaining), or any combination of these three options.
• 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
• Making the Connection to the OWA Web Site Here we test the solution.

Running the Outlook Web Access Publishing Wizard and Creating the HOSTS file entry for the Back-end ISA Server 2004 Firewall on the Front-end ISA Server 2004 Firewall

In a production environment, you should create a split DNS infrastructure that enables hosts on external networks to properly resolve the name of the OWA Web site to the IP address on the external interface of the front-end ISA firewall. In addition, the front-end ISA firewall must be able to resolve the name of the OWA Web site to the IP address on the external interface of the back-end ISA firewall that is listening for incoming requests to the OWA Web site on the default Internal network behind the back-end ISA firewall.

We have not configured a split DNS infrastructure in our current example, so we will use a HOSTS file on the front-end ISA firewall that enables the front-end firewall to resolve the name of the OWA site to the IP address on the external interface of the back-end ISA firewall.

Perform the following steps to create the HOSTS file entry that maps the OWA site to the IP address on the external interface of the back-end ISA firewall:

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. In the current example, enter the following on the last line of the HOSTS file:

10.0.1.2     owa.msfirewall.org

 “10.0.1.2” is the IP address of the external interface of the back-end ISA Server 2004 firewall that is publishing the Exchange Server’s OWA site 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 1

4. 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 front-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 2

4. 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 3

5. 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 4

6. 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 front-end ISA Server 2004 firewall and the back-end ISA Server 2004 firewall’s Web listener. You can use either a split DNS or a HOSTS file entry on the front-end ISA Server 2004 firewall machine to resolve this name to the IP address used by the Exchange Server on the internal network. In the current example, we have used a HOSTS file. Click Next.

Figure 5

7. 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 6

8. On the Select Web Listener page, click the New button. The Web listener works like the Web listener in ISA Server 2000, but with ISA Server 2004, 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 based on the number of addresses bound to the external interface of the ISA Server 2004 firewall.
9. 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.
10. On the IP Addresses page, put a checkmark in the External checkbox. Click the Address button.
11. 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 Server 2004 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 192.168.1.70. Click Add. The IP address now appears in the Selected IP Addresses list. Click OK.

Figure 7

12. Click Next on the IP Addresses page.
13. 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.
14. 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 8

15. Click Next on the Port Specification page.
16. Click Finish on the Completing the New Web Listener page.
17. The details of the Web listener now appear on the Select Web Listener page. Click Edit.

Figure 9

18. In the OWA SSL Listener Properties dialog box, click the Preferences tab.

Figure 10

19. On the Preferences tab, click the Authentication button.
20. In the Authentication dialog box, remove the checkmark from the Integrated checkbox. Click OK in the Microsoft Internet Security and Acceleration Server 2004 dialog box warning that no authentication methods are currently configured.
21. Place a checkmark in the OWA Forms-Based authentication checkbox. The OWA Forms-based authentication feature is very useful and enhances the security the ISA Server 2004 firewall provides for your OWA site. The firewall generates the log on form and then forwards the credentials sent by the user to the OWA site for authentication. Only after the user is successfully authenticated is the connection request forwarded to the OWA site. This prevents unauthenticated users from connecting to the OWA site and eliminates the risks inherent in unauthenticated users accessing the OWA site. Note that you must not enable forms-based authentication at the Exchange Server’s OWA site. Forms-based authentication should be enabled only at the ISA firewall. Click the Configure button.

Figure 11

22. On the OWA Forms-Based Authentication dialog box, put checkmarks in the Clients on public machines, Clients on private machines and Log off OWA when the user leaves OWA site checkboxes. These settings enhance security for your OWA site. Note that you also have the option to set the session times-outs for clients on both public and private machines. It is important to note that the user decides if the machine should be recognized as public or private. Because it is not good security policy to let the user determine the level of security applied to a connection, you should force the same policy on all users. Click OK.

Figure 12

23. Click OK in the Authentication dialog box.
24. Click Apply and then click OK in the OWA SSL Listener Properties dialog box.
25. Click Next on the Select Web Listener page.

Figure 13

26. 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 Server 2004 firewall forwards to it. You cannot have the ISA Server 2004 firewall itself and the OWA site authenticate the user. This means that you must allow All Users access to the rule. An exception to this rule is when users authenticate to the ISA Server 2004 firewall itself using client certificate authentication. 
27. Click Finish on the Completing the New Mail Server Publishing Rule Wizard page.
28. Click Apply to save the changes and update the firewall policy.
29. Click OK in the Apply New Configuration dialog box.

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

The back-end ISA firewall needs outbound access to the Internet via the front-end ISA Server 2004 firewall. There are a number of ways this can be accomplished. In a production environment, you might configure firewall chaining and make the back-end ISA Server 2004 firewall a firewall client of the upstream front-end ISA Server 2004 firewall and then create a rule that allows only the back-end ISA Server 2004 firewall’s “user” account outbound access. In addition, you would determine which protocols should be allowed outbound access from the back-end firewall.

In the current example, we will create an “all open” Access Rule that allows the back-end ISA Server 2004 firewall access to all protocols when connecting to the Internet. We do this for simplicities sake for the current example. On a production network, outbound access control is critically important and you should determine the exact protocols that are allowed access.

ATTENTION:
At this point where you want outbound access from the back-end ISA firewall’s default Internet Network and the Internet, you’ll want to make sure the back end ISA firewall a SecureNAT client of the front-end ISA firewall.

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

1. In the Microsoft Internet Security and Acceleration Server 2004 management console on the front-end ISA Server 2004 firewall, 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. In the Task Pane, click the Create New Access Rule link.
3. In the Welcome to the New Access Rule Wizard page, enter All Open for Back-end ISA Firewall in the Access Rule name text box. Click Next.
4. Select Allow on the Rule Action page.
5. On the Protocols page, select the All outbound traffic entry in the This rule applies to list. Click Next.
6. On the Access Rule Sources page, click Add.
7. On the Add Network Entities dialog box, click the New menu and click Computer.
8. In the New Computer Rule Element dialog box, enter Back End ISA Firewall in the Name text box. Enter 10.0.1.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 Back End ISA Firewall 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. Double click the External entry and click Close.
13. Click Next on the Access Rule Destinations page.
14. On the User Sets page, accept the default entry, All Users and click Next.
15. Click Finish on the Completing the New Access Rule Wizard page.
16. Click Apply to save the changes and update the firewall policy.
17. Click OK in the Apply New Configuration dialog box.

Creating a Web Publishing Rule for the Web Enrollment Site on the Front-end ISA Firewall

The external OWA client machine needs to obtain a CA certificate in order to trust the Web site certificate on the front-end ISA 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 front-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 external interface of the back-end ISA Server 2004 firewall that is publishing the Web enrollment site in the Computer name or IP address text box. In this example, the IP address is 10.0.1.2, so we will enter that value into the text box. In the Path text box, enter /certsrv/*. Click Next.

Figure 14

6. 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 front-end ISA Server 2004 firewall. In this example, the front-end ISA Server 2004 firewall’s external address is 192.168.1.70, so we will enter that value into the text box. Enter /certsrv/* into the Path (optional) text box. Click Next.

Figure 15

7. On the Select Web Listener page, click the New button.
8. 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.
9. On the IP addresses page, put a checkmark in the External checkbox and click Next.
10. 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 16

11. Click Finish on the Completing the New Web Listener Wizard page.
12. Click Next on the Select Web Listener page.
13. Accept the default setting, All Users, on the User Sets page and click Next.
14. Click Finish on the Completing the New Web Publishing Rule Wizard page.
15. Right click the Publish Web Enrollment Site rule and click Properties.
16. 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 17

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

Configuring the public DNS to resolve the name of the OWA site

Correct DNS host name resolution is critical when you design a remote access solution. The ideal DNS configuration allows users who move between the internal and external networks to be able to resolve host names to the correct address regardless of where they are currently located.

The ideal DNS configuration is the split DNS. A split DNS infrastructure consists of two zones that serve the zone domain and subdomains:

• An internal zone that is used only by internal network hosts
• An external zone that is used only by external network hosts

Internal network hosts who need to resolve names on the internal network query an internal network zone and receive the internal network IP address of the host to which they want to connect. External network hosts query the external network zone and receive a public IP address to which they can connect. The destination machine is the same for the external and internal hosts; they just take different routes to arrive at their common destination.

For example, your internal network domain to which the Exchange Servers belong is domain.com. You publish the OWA site to the Internet using ISA Server 2000. The ISA Server uses IP address 131.107.0.1 to listen for incoming requests for the OWA site. The Exchange Server on the internal network has the IP address 10.0.0.3.

Your goal is to allow all hosts, regardless of their locations, to access the Exchange Server using the FQDN owa.domain.com. You want hosts on the internal network to connect directly to the OWA site using the IP address 10.0.0.3 and you want remote hosts connecting from the Internet to use IP address 131.107.0.1 to access the OWA site.

The solution is to create entries on a publicly available DNS server for the domain.com domain. You can have a third party host your DNS services or you can host them yourself. Regardless of who hosts these addresses, the DNS resource records for the domain.com domain on this publicly available DNS server contain the public addresses your want users to use to access resources. In the case of the published resources on the Exchange Server, you should create a Host (A) record for owa.domain.com to map to the IP address 131.107.0.1.

You should then create a second DNS server on the internal network behind the ISA Server firewall. The internal network DNS server also hosts a zone for the domain.com domain. You should create a Host (A) resource record on the internal network DNS server within the domain.com zone for owa.domain.com. The difference is that this time you map these three entries to 10.0.0.3.

External network hosts are assigned a DNS server address that allows them to resolve names to public addresses. How these external hosts are assigned an IP address depends on where they are located. You usually have no control over the specific DNS server address that’s assigned to your remote hosts. However, this is not a problem. If you have registered your domain.com with an Internet Registrar and indicated the correct address for the publicly available authoritative DNS server for your domain, external hosts will have no problems resolving your public addresses correctly.

Internal network hosts can be assigned a correct DNS server address using DHCP. When a remote host moves into the internal network, it will receive new IP addressing information, including a DNS server address, from your DHCP server. When the host receives the IP address of your internal DNS server, it will then be able to resolve the names associated with the front-end Exchange Server to its internal address.

Installing the Enterprise CA Certificate on the OWA Client Machine

Now we must obtain the CA certificate from the enterprise CA on the internal network. We can connect to the Web enrollment site to obtain the CA certificate. Perform the following steps to obtain the CA certificate and install it on the Outlook Express client computer:

1. On the Outlook Express e-mail client computer, enter http://192.168.1.70/certsrv in the Address bar and press ENTER.
2. In the Connect to dialog box, enter Administrator in the User name text box and the Administrator’s password in the Password text box. Click OK.
3. On the Welcome page of the Microsoft Certificate Services site, click the Download a CA certificate, certificate chain, or CRL link.
4. On the Download a CA Certificate, Certificate Chain, or CRL page, click the Install this CA certificate chain link.
5. Click Yes in the Security Warning dialog box asking if you want to install the Microsoft Certificate Enrollment Control.
6. Click Yes in the Potential Scripting Violation dialog box informing you that the Web site will add a certificate to the machine.
7. Click Yes in the Root Certificate Store dialog box asking if you want to add the CA certificate.
8. Close the browser after you see the CA Certificate Installation page that informs you that The CA certificate chain has been successfully installed.

Creating a HOSTS File Entry on the OWA Client Machine

The OWA client machine must be able to resolve the name of the OWA server to the name that is on the OWA server’s Web site certificate. The name we assigned to the Web site certificate on the OWA server is owa.msfirewall.org. The OWA client machine must be able to resolve this name to the IP address on the external interface of the ISA firewall that listens for incoming requests to the OWA server. In our current example, this is 192.168.1.70.

In a production environment, you should have a split DNS infrastructure that correctly resolves names for both internal and external network clients. We have not created a split DNS infrastructure in our example, so we will use a HOSTS file to resolve owa.msfirewall.org to the correct IP address.

ATTENTION:
A HOSTS file entry on the client is not required. We use the HOSTS file entry on the client in this example only to demonstrate the split DNS. In your production environment you would create your own split DNS comprising an internal and external DNS zone for the same domain name.

Perform the following steps to create the HOSTS file entry on the e-mail client machine:

1. Right click Start and click Explore.
2. Navigate to <system_root>\system32\drivers\etc and open the HOSTS file in Notepad.
3. In the HOSTS file, enter a line under the localhost entry:

192.168.1.70     owa.msfirewall.org

Ensure that you press ENTER after you complete the line so that the insertion point is under the new line. Otherwise, the new entry won’t be recognized.

Figure 18

4. Close the HOSTS file and save the changes.

Making the Connection to the OWA Web Site

Perform the following steps to make the connection to the OWA Web site:

1. Open Internet Explorer, enter http://owa.msfirewall.org/exchange into the Address bar and press ENTER.
2. On the Outlook Web Access logon page, enter MSFIREWALL\Administrator in the Domain\user name text box and enter the Administrator’s password in the Password text box. Select the Premium option under Client. Select the Private computer option under Security. Click Log On.

Figure 19

3. The OWA Site opens in an SSL window. The padlock icon in the status bar of Internet Explorer confirms the secure link.

Figure 20

4. Click Log Off to log off the OWA Web site.

Conclusion

In this article, we discussed the procedures required to publish a secure Microsoft Exchange OWA Web site and provision the OWA Web client for a secure connection in a back to back ISA Server 2004 firewall environment. The back to back configuration is especially useful because it essentially doubles the level of security you have, and enables you to create a secure DMZ between the ISA firewalls, while leveraging the total ISA firewall feature set make available to domain member ISA firewall on the back-end ISA firewall. Future articles will focus on outbound access issues with back to back ISA firewall configurations.

If you missed the first article in this series please read Publishing an OWA Site in a Back to Back ISA Firewall Configuration (Part 1).