Publishing Secure Outlook Web Access, POP3 and IMAP4 Services in an Exchange Front End/Back End Configuration

 

The Exchange Server Front End/Back End configuration distributes Exchange related tasks between front-end and back end Exchange Servers. This task distribution has many advantages over the back-end only Exchange configuration. Some of these advantages include:

 

 

The key advantage of a front-end and back-end server configuration is the ability to use a single namespace. You can define a namespace that users can use to connect to their mailboxes (for example, http://owa.internal.net for Outlook Web Access). Without a front-end/back-end configuration, each user must know the name of the server that stores their mailbox.

 

 

You can configure your OWA sites to use Secure Sockets Layer (SSL) traffic between the client and the server to protect the traffic from Internet intruders. However, encryption consumes a large number of processor cycles. The front-end and back-end server setup allows the front-end servers to handle all SSL encryption and decryption tasks. This offloads the encryption responsibilities from the back end Exchange Servers and improves overall performance

 

 

The IMAP4 protocol allows a server to refer IMAP4 client to another server. Exchange supports this referral functionality when a public folder store on specific particular server doesn’t contain the requested content. When a non referral-enabled IMAP4 client connects through a front-end server, the client can access to the entire public folder hierarchy. The front-end server automatically handles any referral response that is passed back when attempting to access a folder that is not available on the back-end server. These referrals are transparent to the client.

 

One of the putative advantages of the front-end/back-end configuration is that you can put the front-end Exchange Server in a DMZ segment. I do not recommend this configuration because the front-end Exchange Server must be a member of the internal network domain. A DMZ segment typically represents a separate and distinct security partition. The integrity of the internal network security partition is violated when extended into a DMZ segment. DMZ segments are generally reserved for bastion host machines that are at relatively high risk of attack. Internal network domain member computers do not typically fit into this category.

 

I recommend that you put both the front-end and back-end Exchange Servers on the internal network and leverage the layer 7 security features provided by ISA Server 2000 and ISA Server 2000 Feature Pack 1.

 

You can make Outlook Web Access (OWA), secure POP3 and secure IMAP4 services available to external network users (remote users) by publishing the front-end Exchange Server. ISA Server Web and Server Publishing Rules allow remote users secure inbound access to these vital services. In addition, users will never need to change configuration settings on their email client computers when you correctly configure a split DNS infrastructure to support remote access clients.

 

The following procedures are required to allow your remote users to access Exchange email services via the ISA Server 2000 firewall:

 

 

While it might seem like there is an unwieldy number of steps, the entire procedure can be carried out in just a couple hours.

 

The remainder of the ISA Server 2000 Exchange Server 2000/2003 Deployment Kit document discusses these procedures in detail.

 

Install the Front End and Back End Exchange Servers

 

The details of the front-end/back-end configuration are beyond the scope of this ISA Server 2000 Exchange Server 2000/2003 Deployment Kit document. Please refer to Microsoft Exchange 2000 Server Front-End and Back-End Topology for a detailed discussion of Exchange front-end/back-end deployments.

 

Configuring a machine to be a front-end server is quite easy. Open the Exchange System Manager and expand the Servers node in the left pane of the console. Right click on your front-end server’s name and click the Properties command. On the General tag of the front-end server’s Properties dialog box, put a checkmark on the This is front-end server checkbox (figure 1).

 

Figure 1 (fig1)

 

 

 

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 are 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 Site Certificates to the OWA, POP3 and IMAP4 Sites

 

Your goal is to provide secure remote access for remote OWA, POP3 and IMAP4 clients. You can provide secure access by requiring clients to use SSL/TLS encryption when connecting to the front-end Exchange Server. All communications moving through the secure channel are protected by TLS encryption (including basic authentication credentials.)

 

Each published service requests a Web site certificate. The Web site certificate is placed in the front-end server’s machine certificate store and bound to the Exchange Service its meant to protect.

 

I recommend that you obtain a Web site certificate for the OWA site, and separate Web site certificates for the POP3 and IMAP4 sites. For example, the OWA site certificate can use the common name (CN) of owa.domain.com and your POP3 and IMAP4 certificates can use the CN mail.domain.com. You can even use the mail.domain.com certificate to secure SMTP connection if you wish to use the SMTP service on the front-end Exchange Server as an SMTP relay.

 

Note:
You can obtain an even higher level of control over the security of your secure sites by using a different certificate for each site. For example, owa.internal.net, pop3.internal.net, imap.internal.net and smtp.internal.net.

 

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 certificates is the same as the name the external email client applications use 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. External SMTP, POP3 and IMAP4 applications must be configured with the name on the certificate used by those services. For example, if these services use a certificate with the name mail.domain.com, then the SMTP, POP3 and IMAP4 clients must be configured to access the server using mail.domain.com; they can not use the IP address of the published server or the IP address used by the external interface of the ISA Server firewall that is used to publish the internal Exchange Server service.

 

 

 

Export the OWA Site Certificate to a File

 

The ISA Server 2000 firewall computer performs SSL to SSL bridging to provide from end to end protection for the connection between the remote OWA client and front-end server on the internal network. 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.

 

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 all invalid packets. The ISA Server firewall then establishes a second SSL session between its own internal interface and the front-end Exchange Server and re-encrypts the packets and forwards them to the front-end Exchange server.

 

You can not use SSL to protect the communications between the front-end Exchange Server and the back end servers. However, you can use IPSec transport mode connections to protect all data moving between the front-end and back-end Exchange Servers. This meets the implicit requirement for an end to end encrypted link.

 

The ISA Server 2000 firewall impersonates the front-end 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 2), expand the Web Sites node and click on the Default Web Site entry. Right click on Default Web Site and click Properties.

 

Figure 2

 

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

 

Figure 3

 

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

 

Figure 4

 

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

 

Figure 5

 

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

 

Figure 6

 

  1. On the Export File Format page (figure 7), 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 7

 

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

 

Figure 8

 

  1. On the File to Export page (figure 9), 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 9

 

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

 

Figure 10

 

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

 

Figure 11

 

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

 

Figure 12

 

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

 

Figure 13

 

 

 

Configure the Front End OWA Site to Force SSL Encryption and Basic Authentication

 

The front-end server’s 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 by configuring those directories to require successfully negotiation of an SSL link.

 

In addition, we want to force basic authentication on all OWA directories that the ISA Server will make accessible to external users. This will allow you to take advantage of the ISA Server 2000 Feature Pack 1 feature that allows it to relay basic authentication credentials to the OWA site. This prevents all non-authenticated communications from every 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 14), 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 for 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 and then right click on an empty area in the right pane of the console. Click the Properties command.

 

Figure 14

 

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

 

Figure 15

 

3.       In the Authentication Methods dialog box (figure 16), 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 that warns you that the credentials should be protected by SSL. Type in your domain name in the Default domain text box.

 

Click OK.

 

Figure 16

 

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

 

Figure 17

 

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 18) when you have forced basic authentication on the Exchange, Exchweb and Public folders.

 

Figure 18

 

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 successfully 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 19), 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 19

 

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

 

Figure 20

 

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

 

Figure 21

 

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

 

Figure 22

 

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 a Client Certificate (optional)

 

You can further enhance the security provided to the connections clients make to the OWA directories by requiring a client certificate to connect to the OWA directories. The OWA client not only must provide user credentials via basic authentication, but must also present a client certificate to the front-end server. If you have internal network clients that must access the front-end server via OWA, you can assign these internal network clients user certificates via group policy.

 

The ISA Server does not have a logged on user that presents a certificate to the OWA Web site directories. Instead, you obtain a certificate for the Web Proxy service and then import that certificate into the ISA Server 2000 Web Proxy service’s Personal\Certificates certificate store. You then 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.

 

 

 

Issue Machine Certificates to the Front End and Back End Exchange Servers for IPSec Security

 

Remote OWA clients that establish a secure SSL link with the ISA Server have the implicit expectation that the connection is secure from end to end. While the connections between the OWA client and ISA Server, and the ISA Server and the front-end server, are secured with SSL encryption, the connections between the front-end server and the back-end servers cannot be secured with SSL.

 

You can set up IPSec Policies that create a secure transport mode IPSec connection between the front-end and back-end Exchange Servers. Assign these machines certificates to confer a higher level of authentication security. You can use either Group Policy-based autoenrollment to assign the front-end and back-end Exchange Server’s machine certificates, or you can use the Certificates mmc standalone snap-in.

 

Please review ISA Server 2000 Exchange Server 2000/2003 Deployment Kit documents

Issuing Certificates via the MMC Snap-in and Issuing certificates via autoenrollment for detailed information on how to assign machine certificates via autoenrollment and the Certificates mmc snap-in.

 

 

 

Install Windows Server 2003 on the Firewall Computer

 

The computer that will become the ISA Server 2000 firewall relay 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 the 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 front-end Exchange server to the ISA Server computer. This certificate is imported into the ISA Server’s machine certificate store and then 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 23).

 

Figure 23

 

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

 

Figure 24

 

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

 

Figure 25

 

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

 

Figure 26

 

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

 

Figure 27

 

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

 

Figure 28

 

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

 

Figure 29

 

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

 

Figure 30

 

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

 

Figure 31

 

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

 

Figure 32

 

11.   On the Password page, type in the password for the file (figure 33). 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 33

 

12.   On the Certificate Store page (figure 34), 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 34

 

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

 

Figure 35

 

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

 

Figure 36

 

15.   You will see the Web site certificate an the CA certificate in the right pane of the console. The Web site certificate has the FQDN that is assigned to the Web site. This is the name external users will 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 37).

 

Figure 37

 

16.   Click on the Certification Path tab on the Certificate dialog box (figure 38). 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 38

 

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

 

Figure 39

 

18.   Expand the Trusted Root Certification Authorities node and click the Certificates node (figure 40). 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 40

 

19.   Press F5 to refresh the display. You should see the certificate appear in the right pane of the console (figure 41). If you do not see the CA certificate in the right pane of the console, repeat the procedure

 

Figure 41

 

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 42). Notice that the red “x” no longer appears on the CA certificate. Click OK on the Certificate dialog box.

 

Figure 42

 

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

 

Figure 43

 

 

 

 

Run the Outlook Web Access Web Publishing Wizard and Create a HOSTS File Entry

 

One of the very nice improvements ISA Server Feature Pack 1 adds is the Outlook Web Access Publishing Wizard. The OWA Publishing Wizard does most of the work required to publish an OWA site on the internal network. In fact, the OWA Publishing Wizard can configure the Incoming Web Requests listener to use the Web site certificate. We went through that process manually so that you have a better idea of how it works, which will aid in troubleshooting SSL related problems if they occur.

 

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

 

1.       Open the ISA Management console (figure 44). 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 44

 

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 45). Click Next.

 

Figure 45

 

3.       On the Name of Published Server page (figure 46), 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 that the external user uses to connect to the site. This 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 46

 

4.       On the Listeners page (figure 47), 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 47

 

5.       On the Secure Connection from Client page (figure 48), put a checkmark in the Enable SSL. Client must use SSL to connect to the ISA Server checkbox. Click the Select button.

 

Select the Web site certificate in the Select Certificate dialog box. Click OK.

 

Figure 48

 

6.       The Web site certificate appears in the Certificate frame (figure 49). Click Next.

 

Figure 49

 

7.       <