Publishing Secure Exchange 2003 Outlook Web Access Sites with ISA Server 2000

 

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

 

Note:

Secure Exchange RPC Publishing is inherently more secure than OWA. The sophisticated layer 7 RPC filter tightly secures the connection between the remote full Outlook MAPI client and Exchange Server. However, many remote users are behind conventional firewalls that do not allow outbound MAPI access to your Exchange Server because they lack the layer 7 intelligence provided by ISA Server firewalls.

 

OWA Web site publishing provides a viable alternative, both in terms of level of functional and level of security, to secure Exchange RPC Publishing. Your challenge as the ISA Server 2000 firewall administrator 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:

 

 

Secure OWA Web site publishing using ISA Server 2000 provides a higher level of security than virtually any other firewall on the market and provides a level of functionality and security second only to secure Exchange RPC Publishing.

 

You need to carry out the following procedures to create a highly secure remote access OWA Web site publishing solution:

 

 

The remainder of this ISA Server 2000 Exchange Server 2000/2003 Deployment Kit document discusses the details of each of these steps.

 

 

 

Install the Exchange Server

 

There are no special installation requirements on the Exchange Server to allow OWA publishing to work correctly with ISA Server. As long as the OWA site is operational for internal network clients, it will be operational via ISA Server 2000 Web Publishing Rules.

 

 

Install an enterprise CA on the internal network

 

An enterprise Certificate Authority (CA or Certificate Server) has several advantages over a standalone CA. Two of the primary advantages of using an enterprise CA is that you can use autoenrollment to automatically deploy machine and user certificates to all domain members. In addition, you can use the Certificates MMC stand-alone snap-in to request and install a certificate from an online enterprise CA.

 

You can install an enterprise CA on a domain member in the same domain as the front-end Exchange Server and the ISA Server 2000 firewall. This configuration allows you to request Web site certificates for the OWA, POP3 and IMAP4 sites from an online certificate authority and install them immediately.

 

In addition, all Exchange Servers and the ISA Server 2000 firewall can request certificates from the online enterprise CA and install them immediately. This simplifies the task of creating the SSL link between the ISA Server 2000 firewall and the front-end Exchange Server as well as making it easier to create a working IPSec Policy based on certificate authentication to secure the communications between the front-end and back-end Exchange Servers.

 

Please refer to ISA Server 2000 Exchange Server 2000/2003 Deployment Kit document Creating the enterprise CA for more information on how to create an enterprise CA and ISA Server 2000 Exchange Server 2000/2003 Deployment Kit documents Issuing certificates via the MMC snap-in and Issuing certificates via autoenrollment

 

 

Issue and bind certificates for the OWA site

 

Your goal is to provide secure remote access for your remote OWA clients. You can provide secure access by requiring these clients to use SSL/TLS encryption when connecting to the Exchange Server. All communications moving through the secure channel are protected by TLS encryption (including basic authentication credentials.

 

The published Web site requires a Web site certificate. The Web site certificate is placed in the Exchange Server’s machine certificate store and bound to the Exchange Server’s Web site.

 

Please refer to ISA Server 2000 Exchange Server 2000/2003 Deployment Kit document

How to Obtain a Web Site Certificate for details on how to obtain, install and bind the Web site certificate to the Exchange services you wish to publish.

 

Note:
It is critically important that the common name on the certificate is the same as the name the OWA client uses to access the service. For example, remote browsers must use the FQDN owa.domain.com when connecting to the OWA Web site when the name on the certificate is owa.domain.com. This name must also resolve to the IP address on the external interface of the ISA Server that you’ve configured to listening for incoming connections to the OWA site.

 

 

 

Export the OWA site certificate to a file

 

The ISA Server 2000 firewall computer performs SSL to SSL bridging to protect the connection from the remote OWA client end to end. This end to end protection is important because the implicit assumption made by the remote host is that if the initial connection requires a secure link, then the entire transaction is protected by an encrypted link.

 

SSL to SSL bridging allows the external Web browser to create an encrypted SSL link with the external interface of the ISA Server 2000 firewall. The ISA Server firewall decrypts the packets and inspects them for validity and drops invalid packets. The ISA Server firewall then establishes a second SSL session between its own internal interface and Exchange Server, re-encrypts the packets and forwards them to the Exchange server.

 

The ISA Server 2000 firewall impersonates the OWA Web site by presenting the OWA Web site’s certificate to the remote OWA client. The name of the OWA Web site is contained in the certificate; this is the mechanism of impersonation.

 

Perform the following steps to export the Web site certificate from the OWA server:

 

  1. Click Start, point to Administrative Tools and click on Internet Information Services. In the Internet Information Services (IIS) Manager console (figure 1), expand the Web Sites node and click on the Default Web Site entry. Right click on Default Web Site and click Properties.

 

Figure 1

 

  1. Click on the Directory Security tab in the Default Web Site Properties dialog box (figure 2). Click on the View Certificate button.

 

Figure 2

 


  1. In the Certificate dialog box, click on the Details tab (figure 3). Click on the Copy to File button.

 

Figure 3

 


  1. Click Next on the Welcome to the Certificate Export Wizard page (figure 4).

 

Figure 4

 


  1. Select the Yes, export the private key option on the Export Private Key page (figure 5). Click Next.

 

Figure 5

 


  1. On the Export File Format page (figure 6), select the Personal Information Exchange – PKCS #12 (.PFX) option. Put a checkmark in the Include all certificate in the certification path if possible checkbox. Remove the checkmarks from the Enable strong protection (requires IE 5.0, NT 4.0 SP4 or above) and Delete the private key if the export is successful checkboxes.

 

The enable strong protection option requires user intervention before the certificate can be used to establish a connection. The server on which the certificate is installed cannot perform the required actions. That is why you must not select that option. You do not want to delete the private key from the OWA site, because you want to keep the key there for backup.

 

Click Next.

 

Figure 6

 


  1. On the Password page, type a password and confirm the password. This password protects the private key from being stolen by anyone who might obtain the exported file (figure 7).

 

Figure 7

 


  1. On the File to Export page (figure 8), type in a path and file name for the certificate file. Remember where you store the file because you need to copy it to the ISA Server machine in the DMZ. Click Next.

 

Figure 8

 


  1. Review your settings on the Completing the Certificate Export Wizard page (figure 9) and click Finish.

 

Figure 9

 


  1. Click OK on the Certificate Export Wizard dialog box that informs you the export was successful (figure 10).

 

Figure 10

 


  1. Close the Certificate dialog box (figure 11).

 

Figure 11

 


  1. Close the Default Web Site Properties dialog box (figure 12).

 

Figure 12

 

 

 

Configure the OWA Site to Force SSL Encryption and Basic Authentication

 

The OWA Web site supports SSL connections as soon as the certificate is bound to the site. However, users still have the option to connect to the site using a non-secure connection. You can force both the ISA Server and internal users to use an SSL connection to the OWA Web site directories. You can require all clients to successfully negotiate an SSL link before connecting to the OWA site directories.

 

We also want to force basic authentication on all OWA directories the ISA Server makes accessible to external users. This allows you to take advantage of the ISA Server 2000 Feature Pack 1 feature that allows relay of basic authentication credentials from the firewall to the OWA site. This prevents all non-authenticated communications from reaching the OWA Web site and significantly improves the level of security.

 

Perform the following steps to force an SSL connection to the OWA Web site directories:

 

1.       Click Start, point to Administrative Tools and click on Internet Information Services. In the Internet Information Services (IIS) Manager (figure 13), 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

 

We want the ISA Server 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.

 

Figure 13

 

2.       Click on the Directory Security tab (figure 14). In the Authentication and access control frame, click on the Edit button.

 

Figure 14

 

3.       In the Authentication Methods dialog box (figure 15), remove the checkmark from all checkboxes except for 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. Type in your domain name in the Default domain text box.

 

Click OK.

 

Figure 15

 

4.       Click Apply and then click OK in the Exchange Properties dialog box (figure 16).

 

Figure 16

 

5.       Repeat these steps with the /Exchweb and /Public directories found in the left pane after the console. Close the Internet Information Services (IIS) Manager console (figure 17) when you have forced basic authentication on the Exchange, Exchweb and Public folders.

 

Figure 17

 

 

The next step is to force the ISA Server’s Web Proxy 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 on Internet Information Services. In the Internet Information Services (IIS) Manager (figure 18), expand your server name and then expand the Default Web Site node in the left pane of the console.

 

Now you will force an SSL connection on the directories the remote OWA users will access though the ISA Server. These directories are:

 

/Exchange

/Exchweb

/Public

 

Click on the Exchange node in the left pane of the console to highlight it. Right click on an empty area in the right pane of the console and click the Properties command.

 

Figure 18

 

2.       Click on the Directory Security tab in the Exchange Properties dialog box (figure 19). Click the Edit button in Secure communications frame.

 

Figure 19

 

3.       In the Secure Communications dialog box (figure 20), put a checkmark in the Require secure channel (SSL) checkbox. Put a checkmark in the Require 128-bit encryption checkbox. Click OK.

 

Figure 20

 

4.       Click Apply and then click OK on the Exchange Properties dialog box (figure 21).

 

Figure 21

 

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

 

 

 

Configure the OWA Site to Require Client Certificate

 

You can further enhance the security provided to the connections clients make to the OWA directories by configuring the OWA directories to require a host to provide a client certificate before allowing the connection. The OWA client must provide user credentials via basic authentication and must also present a client certificate. You can assign internal network clients certificates via group policy if you have internal network clients that need to access the Exchange Server via OWA.

 

This ISA Server does not have a logged on user that presents a client certificate to the OWA Web site directories. Instead, you obtain a user certificate for the Web Proxy service and then import the certificate into the ISA Server 2000 Web Proxy service’s Personal\Certificates certificate store. Next, you configure the OWA Web Publishing Rule to present a client certificate to the OWA Web site after the certificate is imported into the Web Proxy service’s certificate store.

 

Please refer to ISA Server 2000 Exchange Server 2000/2003 Deployment Kit document

Increasing OWA Security by Configuring the ISA Server to Present a Client Certificate to an OWA Web site for detailed information on how to configure the OWA Web site to require a user certificate and how to configure the ISA Server’s Web Proxy service to present a user certificate to the OWA site.

 

Note:
User authentication is performed via basic authentication. The OWA directories are configured to require the client to present a client certificate, but this certificate is not mapped to a user account and the client certificate is not used to authenticate the client. It is the information send with the basic authentication credentials that determines the mailbox that is opened.

 

 

 

Install Windows Server 2003 on the firewall computer

 

The computer that becomes the ISA Server 2000 firewall must meet the following minimum requirements:

 

 

The ISA Server firewall and Web caching components work very well on modest hardware. This is true even when the SMTP filter is enabled and protecting published SMTP servers. However, if you run decide to use the SMTP Message Screener on the firewall, or if you use SSL to protect Web Published Web site, or if you use the ISA Server firewall as a VPN server, you need to increase the minimum requirements to support encryption services.

 

 

Install ISA Server 2000 on the firewall computer

 

Install ISA Server 2000 after installing Windows Server 2003 onto the firewall computers. You must go through some specific procedures outside of the standard ISA Server 2000 installation when installing the firewall software onto a Windows Server 2003 computer. Please refer to ISA Server 2000 Exchange Server 2000/2003 Deployment Kit document Installing ISA Server 2000 on Windows Server 2003.

 

 

 

Import the OWA Web Site Certificate into the ISA Server Firewall’s Machine Certificate Store

 

Now that the ISA Server software is installed, you’re ready to copy the Web site certificate file from the Exchange Server to the ISA Server. The OWA Web site certificate is imported into the ISA Server’s machine certificate store. Then the imported certificate is bound to the Incoming Web Requests listener.

 

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

 

1.       Click Start and click on the Run command. Type 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 (figure 22).

 

Figure 22

 

2.       Click the Add button in the Add/Remove Snap-in dialog box (figure 23).

 

Figure 23

 

3.       Click on the Certificates entry in the Available Standalone Snap-in list on the Add Standalone Snap-in dialog box (figure 24). Click Add.

 

Figure 24

 

4.       Select the Computer account option on the Certificates snap-in page (figure 25). Click Next.

 

Figure 25

 

5.       On the Select Computer page, select the Local computer: (the computer this console is running on) option and click Finish (figure 26).

 

Figure 26

 

6.       Click Close on the Add Standalone Snap-in page (figure 27).

 

Figure 27

 

7.       Click OK on the Add/Remove Snap-in dialog box (figure 28).

 

Figure 28

 

8.       Right click on the Personal node in the left pane of the console, point to All Tasks and click Import (figure 29).

 

Figure 29

 

9.       Click Next on the Welcome to the Certificate Import Wizard (figure 30).

 

Figure 30

 

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 31).

 

Figure 31

 

11.   On the Password page, type in the password for the file (figure 32). Do not put a checkmark in the Mark this key as exportable. This will allow you to back up or transport you keys at a late time checkbox. The reason is that this machine is a bastion host with an interface in a DMZ or on the Internet and may be compromised. The compromiser may be able to steal the private key from this machine if it is marked as exportable.

 

Click Next.

 

Figure 32

 

12.   On the Certificate Store page (figure 33), confirm that the Place all certificate in the follow store option is select and that is says Personal in the Certificate store box. Click Next.

 

Figure 33

 

13.   Review the settings on the Completing the Certificate Import page and click Finish (figure 34).

 

Figure 34

 

14.   Click OK on the Certificate Import Wizard dialog box informing you the import was successful (figure 35).

 

Figure 35

 

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.

 

Double click on the Web site certificate in the right pane of the console (figure 36).

 

Figure 36

 

16.   Click on the Certification Path tab on the Certificate dialog box (figure 37). Notice the red “x” on the CA certificate node. This indicates that this machine does not trust the CA that issued the Web site certificate. In order to use this certificate to perform SSL to SSL bridging, this machine must trust the CA that issued the Web site certificate.

 

Close the Certificate dialog box.

 

Figure 37

 

17.   Right click on the CA certificate in the right pane of the console and click the Copy command (figure 38).

 

Figure 38

 

18.   Expand the Trusted Root Certification Authorities node and click the Certificates node (figure 39). Right click on the Certificates node and click the Paste command. This pastes the CA certificate into the Trusted Root Certificate Authorities\Certificates store and allows this machine to trust certificates issued by this CA.

 

Figure 39

 

19.   Click the Refresh button refresh the display. You should see the certificate appear in the right pane of the console (figure 40). If you do not see the CA certificate in the right pane of the console, repeat the procedure

 

Figure 40

 

20.   Return to the Personal\Certificates node in the left pane of the console and double click on the Web site certificate. In the Web site certificate’s Certificate dialog box, click on the Certification Path tab (figure 41). Notice that the red “x” no longer appears on the CA certificate. Click OK on the Certificate dialog box.

 

Figure 41

 

21.   Close the mmc console (figure 42). You may want to save this console with the name of certificates and store it in the Administrative Tools menu.

 

Figure 42

 

 

 

 

Run the Outlook Web Access Publishing Wizard and create the HOSTS file entry

 

One of the nice improvements ISA Server Feature Pack 1 adds to any ISA Server 2000 installation is the Outlook Web Access Publishing Wizard. The OWA Publishing Wizard does most of the work required to publish an internal network OWA site. In fact, the OWA Publishing Wizard can configure the Incoming Web Requests listener to use the Web site certificate.

 

Perform the following steps to create the OWA Web Publishing Rule:

 

1.       Open the ISA Management console (figure 43). Expand the Server and Arrays node and then expand your server name. Expand the Publishing node and click on the Web Publishing Rules node. Right click on the Web Publishing Rules node, point to New and click Publish Outlook Web Access Server.

 

Figure 43

 

2.       Type in a name for the rule in the Outlook Web Access Server rule name text box on the Welcome to the Outlook Web Access Publishing Wizard page (figure 44). Click Next.

 

Figure 44

 

3.       On the Name of Published Server page (figure 45), type in the FQDN of the OWA site in the Internal name or IP address of the Outlook Web Access Server. This information is used to forward the incoming request to the internal OWA server. You can use the IP address of the internal server, or the IP address of the external interface of the firewall protecting the internal OWA server if you are using reverse NAT to publish the OWA server.

 

I prefer to use the actual FQDN the external user uses to connect to the site. This also makes the Web Proxy logs easier to interpret. You can create a HOSTS file entry on the ISA Server that resolves this name to the IP address you want the incoming request forwarded to.

 

Put a checkmark in the Use an SSL connection from the ISA Server to the Outlook Web Access Server checkbox. This forces the ISA Server to establish an SSL link between itself and the OWA server. All communications between the ISA Server and the OWA server are protected by SSL.

 

Click Next.

 

Figure 45

 

4.       On the Listeners page (figure 46), enter the URL that the external users will use to connect to the OWA site. Because we are forcing an SSL connection between the external client and the ISA Server, we use the URL https://owa.internal.net.

 

Click Next.

 

Figure 46

 

5.       On the