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.       Review the settings on the Completing the Outlook Web page and click Finish (figure 50).

 

Figure 50

 

8.       Select the Save the changes and restart the service(s) option on the ISA Server Warning dialog box (figure 51), and click Finish.

 

Figure 51

 

 

Review the Settings on the Incoming Web Requests Listener and the OWA Web Publishing Rule

 

Let’s now examine the changes the OWA Web Publishing Rule Wizard made to the Incoming Web Requests listener and the details of the Web Publishing Rule.

 

Perform the following steps to review the changes to the Incoming Web Requests listener:

 

1.       Open the ISA Management console and expand the Servers and Arrays node (figure 52). Right click on your server name and click the Properties command.

 

Figure 52

 

2.       In the server’s Properties dialog box (figure 53), click on the Incoming Web Requests tab. Notice that the Configure listeners individually per IP address has been selected. This option allows the Incoming Web Requests listener to listen on a specific IP address instead of all addresses bound to the external interface of the ISA Server.

 

The Enable SSL listeners checkbox has been enabled. This allows the Incoming Web Requests listener to accept inbound SSL connection requests. The SSL port is set for TCP port 443.

 

Select the listener entry and click the Edit button.

 

Figure 53

 

3.       The Outlook Web Access Publishing Wizard has configured the listener to use the primary address bound to the external interface on the ISA Server. Integrated authentication is enabled by default. The Use a server certificate to authenticate to web clients option is selected and the OWA Web site’s certificate is bound to the listener.

 

The remote OWA client will use only basic authentication when communicating with the ISA Server. Put a checkmark in the Basic with this domain checkbox (figure 54).

 

Figure 54

 

4.       Click Yes on the ISA Server Configuration dialog box warning you that basic credentials are sent in the clear (figure 55).

 

Figure 55

 

5.       Enter the name of your domain in the Domain Name text box on the Select Domain dialog box (figure 56) and click OK.

 

Figure 56

 

6.       Remove the checkmark from the Integrated checkbox. You want the remote OWA clients to use only basic authentication and not try to negotiate integrated authentication (figure 57). Click OK.

 

Figure 57

 

7.       Select the Save the changes and restart the service(s) option and click OK (figure 58).

 

Figure 58

 

8.       Click OK in the server’s Properties dialog box (figure 59).

 

Figure 59

 

The Outlook Web Access Web Publishing Wizard created a Web Publishing Rule allowing the ISA Server to forward incoming requests to owa.internal.net to the OWA server on the internal network. Note that the FQDN in the request is critical. The FQDN must match exactly the name on the Web site certificate. The client will not be able to establish an SSL link to the Incoming Web Requests listener if there is a mismatch between the FQDN the client uses to access the OWA server, the FQDN of the server in the Destination Set and the name of the OWA server on the certificate.

 

Let’s look at some of the details of the Web Publishing Rule created by the Wizard and tune it up a bit:

 

1.       In the ISA Management console (figure 60), expand your Servers and Arrays node and expand your server name. Expand the Publishing node and click on the Web Publishing Rules node. Double click on the OWA Web publishing rule you created.

 

Figure 60 (fig60)

 

2.       Click on the Destinations tab (figure 61). Notice that the This rule applies to option is set to Selected destination set. The name of the Destination Set is listed in the Name drop down list. The specific destinations included in this Destination Set are seen in the Destinations included in set list.

 

These destinations include the FQDN of the OWA server and the directories that external users are allowed to access. These path entries are:

 

/exchweb*

/public*

/exchange*

 

The wildcard entry at the end of the path indicates that the external client can access all files and folders under the exchweb, public and exchange folders.

 

Figure 61

 

3.       Click on the Action tab. Notice that the Redirect the request to this internal Web server (name or IP address) option is selected (figure 62). The FQDN of the OWA site is entered into the text box under this option. This FQDN must resolve to an IP address that can accept incoming requests to the OWA site. We will create a HOSTS file entry later that insures that the requests are forwarded correctly.

 

The Send the original host header to the publishing server instead of the actual one (specified above) check is enabled. Do not disable this checkbox.

 

Put a checkmark in the Allow delegation of basic authentication credentials checkbox. This allows the ISA Server to forward the basic authentication credentials to the OWA site on the internal network. This allows only authenticated connections to be made to the OWA site. If the client is not authenticated, no packets are forwarded to the internal site.

 

Figure 62

 

4.       Click on the Bridging tab (figure 63). In the Redirect HTTP requests as frame has the SSL requests (establish a secure channel to the site) option select. This setting will be ignored because all connections must be SSL; no non-SSL connections will be accepted.

 

The SSL requests (establish a new secure channel to this site) option is select in the Redirect SSL requests as) frame. This setting insures that SSL requests are bridged as SSL requests (SSL to SSL bridging). The external client establishes an SSL connection with the ISA Server, then the  ISA Server establishes a new SSL connection with the OWA site on the internal network.

 

Put a checkmark in the Require secure channel (SSL) for published site checkbox. This setting forces the external client to successfully negotiate an SSL connection. If the client cannot negotiate an SSL link, the connection is dropped. Put a checkmark in the Require 128-bit encryption checkbox if you know that all your OWA clients support 128-bit (almost all Microsoft clients now support 128-bit encryption).

 

You do not need to select the Use a certificate to authenticate to the SSL Web server checkbox. This is only required if you want to require the ISA Server to use a client certificate to authenticate to the OWA web site. This feature increases security by forcing the ISA Server to present a client certificate to the OWA server before it can connect to it. We will not cover this procedure in this ISA Server 2000 Exchange Server 2000/2003 Deployment Kit document.

 

Figure 63

 

Notice that the Web Publishing Rule uses the name of the OWA server, owa.internal.net, in the redirect. This FQDN must resolve to an IP address that can reach the OWA server. If you are routing between the DMZ and the internal network, the FQDN must resolve to the actual IP address of the OWA server. If you are performed reverse NAT between the OWA server and the DMZ (such as a Server Publishing Rule in ISA Server 2000), then the FQDN must resolve to the address of the external interface of the firewall on the edge of the private network.

 

You can configure a DNS server to support DMZ hosts, or you can use a HOSTS file on the Web  ISA Server to forward the requests to the correct IP address.

 

Perform the following steps to create the HOSTS file on the ISA Server:

 

  1. Open Windows Explorer and navigate to \WINDOWS\system32\drivers\etc directory and open the hosts file.
  2. In the Open With dialog box, select the Notepad entry and click OK.
  3. The hosts file is opened in Notepad. Put 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. For example, if the firewall in front of the OWA server on the internal network is performing reverse NAT to publish the internal OWA site, and the redirect is owa.internal.net, then you would put in the following entry:

 

131.107.0.2              owa.internal.net

 

Where “131.107.0.2” is the IP address on the external interface of the internal network firewall that is publishing the internal network OWA site, and owa.internal.net is the entry in the Web Publishing Rule for the redirection. Make sure you press ENTER after you put this line into the hosts file so that there is an empty line at the end of the file.

 

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

 

 

 

Install the URLScan Filter on the ISA Server 2000 Firewall Computer

 

The URLScan filter is an optional component of the ISA Server 2000 Feature Pack 1. This version of URLScan installs directly on the ISA Server 2000 firewall computer. Like the version of URLScan that installs on the Web server, the Feature Pack 1 version of URLScan examines incoming HTTP connections for invalid commands and requests. Validity is determined by the settings in the urlscan.ini file.

 

You can download the ISA Server 2000 Feature Pack 1 version of URLScan from the ISA Server 2000 Feature Pack 1 Web site. Download the isafp1ur.exe file from the site and run the installation program. Follow the onscreen instructions. If you are not familiar with the URLScan tool, review the readme file before installing.

 

Be sure to installing URLScan on the ISA Server 2000 firewall using the OWA template. The installation Wizard will ask you to make this decision during the course of installation.

 

 

 

Configure the POP3 and IMAP4 Sites to Force SSL and Create the Secure POP3 and IMAP4 Server Publishing Rules

 

Remote users can access the front-end Exchange server using POP3 and IMAP4 email clients. While this email clients don’t offer the same rich experience provided by OWA or the full MAPI Outlook client, POP3 and IMAP4 allow users almost universal access to their messages.

 

The challenge to POP3 and IMAP4 remote access is that it needs to be done securely. You can force secure communications between the POP3/IMAP4 client and the front-end Exchange server by forcing SSL/TLS security on the connection. The security protects both the user’s log on credentials an the data moving through the secure channel.

 

For a detailed explanation on how to create and publish secure POP3 and IMAP4 sites, please refer to ISA Server 2000 Exchange Server 2000/2003 Deployment Kit documents

Exchange 2003 POP3/Secure POP3 publishing and Secure Exchange 2003 IMAP4/IMAP4 publishing

 

 

 

Configure IPSec Policy to Secure All Communications Between the Front End and Back End Servers

 

The link between the OWA client and the external interface of the ISA Server firewall is protected by SSL encryption. In addition, the link between the internal interface of the ISA Server firewall and the front-end Exchange Server is protected by SSL encryption. The problem is that the link between the front-end and back-end Exchange Server is not protected by SSL encryption. You can not use SSL between the front-end and back-end Exchange servers.

 

You can solve this problem by creating IPSec Policies to force a secure, encrypted link between the front-end and back-end Exchange servers. The IPSec encrypted link protects the messages moving between the front-end and back-end and provides the end to end encryption the OWA client implicitly expects when it creates the secure link with the external interface of the ISA Server.

 

There are several ways you can implement IPSec Policies. The two most popular methods are to create a Group Policy-based security policy and deploy IPSec Policies via domain group policy. Another method available to you is to use local security policy on the front-end and back-end Exchange servers.

 

There are several ways to enforce authentication between the front-end and back-end Exchange Servers when they establish their IPSec links. In this following example we assume that the front-end and back-end Exchange Servers have received machine certificates from the same CA. We will use certificate authentication as the preferred authentication method when establishing the IPSec Policy.

 

Perform the following steps to create the IPSec transport mode secure connection between the front-end and back-end Exchange Servers:

 

1.       Go to the front-end Exchange Server, click Start, point to Administrative Tools and click on Local Security Settings. In the Local Security Settings console, click on the IP Security Policies on Local Computer node in the left pane of the console. Right click on an empty area in the right pane of the console and click the Create IP Security Policy command (figure 64).

 

Figure 64

 

2.       Click Next on the Welcome to the IP Security Policy Wizard page (figure 65).

 

Figure 65

 

3.       On the IP Security Policy Name page (figure 66), give the policy a name in the Name text box. Enter an optional description for the policy in the Description text box. Click Next.

 

Figure 66

 

4.       On the Requests for Secure Communication page (figure 67), remove the checkmark from the Activate the default response rule checkbox and click Next.

 

Figure 67

 

5.       On the Completing the IP Security Policy Wizard page (figure 68), put a checkmark in the Edit properties checkbox and click Finish.

 

Figure 68

 

6.       The Properties dialog box for the policy appears (figure 69). Keep in mind that a security policy consists of a set of rules. If any of the conditions we set in any of the rules matches a connection, then the settings of the rule are triggered. The only rule included in the policy at this point is the default response rule, but it is not selected and we will not select it. Instead, we will add our own rule. Make sure that there is a checkmark in the Use Add Wizard checkbox and click the Add button.

 

Figure 69

 

7.       Click Next on the Welcome to the Create IP Security Rule Wizard page (figure 70).

 

Figure 70

 

8.       We are creating a transport mode connection between the front-end and back-end Exchange Servers. Therefore, on the Tunnel Endpoint page select the This rule does not specify a tunnel option (figure 71).

 

Figure 71

 

9.       Select the All network connections option on the Network Type page (figure 72). Click Next.

 

Figure 72

 

10.   An IP filter list contains IP addresses, computer names, or network IDs and protocol information. When a connection matches a connection specified in the IP filter list, then a filter action is applied. In this example we will create an IP filter list that contains the source IP address being the back-end Exchange Server and the destination IP address being the front-end Exchange Server. We will also configure the IP filter list to match all protocol connections inbound from the back-end Exchange Server to the front-end Exchange Server.

 

On the IP Filter List page, click the Add button (figure 73). In the IP Filter List dialog box, type a name for the filter list in the Name text box. Type an optional description in the Description text box. To add filters to the list, make sure there is a checkmark in the Use Add Wizard checkbox and click the Add button.

 

Figure 73

 

11.   Click Next on the Welcome to the IP Filter Wizard page (figure 74).

 

Figure 74

 

12.   On the IP Filter Description and Mirrored property page (figure 75), type in a description of the filter in the Description text box. You should enter information about the nature of the filter, such as the source and destination addresses and the protocols. In our example, we have a single front-end and back-end Exchange Server, so we’ll just call it OWA.

 

Put a checkmark in the Mirrored. Match packets with the exact opposite source and destination addresses option. This will allow the trigging of the filter action when packets moving in the opposite direction as specified in the filter as detected by the IPSec Policy Agent.

 

Figure 75

 

13.   On the IP Traffic Source page (figure 76), select the A specific IP Address option in the Source address drop down list. In the IP Address text box, type in the IP address of the back-end Exchange Server. You will have to repeat the step if you have multiple back-end Exchange Servers. Click Next.

 

Figure 76

 

14.   On the IP Traffic Destination page (figure 77), select the My IP Address option from the Destination address drop down list. Click Next.

 

Figure 77

 

15.   On the IP Protocol Type page (figure 78), left the default setting of Any in the Select a protocol type drop down list. We want to match all packets moving between the front-end and back-end Exchange Servers, so we match all protocols with this filter list entry. Click Next.

 

Figure 78

 

16.   Do not put a checkmark in the Edit properties checkbox, then click Finish on the Completing the IP Filter Wizard page (figure 79).

 

Figure 79

 

17.   The IP filter that matches all protocols for communications between the front-end and back-end Exchange Server. You have completed the configuration of the IP filter list that matches the packets moving between the front-end and back-end Exchange Server. Click OK to continue create the rule that secures the connection between the front-end and back-end Exchange Servers (figure 80).

 

Figure 80

 

18.   On the IP Filter List page (figure 81), select the IP filter list you created in the IP Filter lists box. Click Next.

 

Figure 81

 

19.   On the Filter Action page (figure 82), select the Require Security option from the Filter Actions list.

 

When a packet matches the source and destination, as well as protocol included in the filter list, then a Filter Action is triggered. We are creating a rule that includes a filter list we created that matches all protocol packets between the front-end and back-end Exchange Servers. When packets match these conditions, then the Filter Action is applied. The Require Security filter action will require that all packets moving between the front-end and back-end Exchange Server are security with IPSec encryption.

 

Click Next.

 

Figure 82

 

20.   On the Authentication Method page (figure 83), you can choose from Active Directory default (Kerberos V5 protocol), Use a certificate from this certification authority (CA) and Use this string to protect the key exchange (preshared key) options.

 

You and use the Active Directory default option if the front-end and back-end machines belong to the same domain. You can enhance security by using the Use a certificate from this certification authority (CA) option. The front-end and back-end Exchange Server must have machine certificates from the same CA (or in a more complex environment, trust the CAs that issued each other’s machine certificates).

 

In the current example, we have already deployed machine certificates to both the front-end and back-end Exchange Servers, so select the Use a certificate form this certification authority (CA) and click Browse.

 

Figure 83

 

21.   On the Select Certificate dialog box (figure 84), find the CA certificate for your root CA on the internal network and select it. Then click OK.

 

Figure 84

 

22.   The CA information appears in the text box. Click Next.

 

Figure 85

 

23.   Put a checkmark in the Completing the Security Rule Wizard checkbox and click Finish.

 

Figure 86

 

24.   Click OK on the New Rule Properties dialog box (figure 87).

 

Figure 87

 

25.   On the Properties dialog box for the policy, click the General tab. You can change the Name and the Description for this rule on this tab (figure 88). You can click the Settings button and change core characteristic of the how key exchange is performed. Click OK.

 

Note:
Details of IPSec negotiation and policy as beyond the scope of this ISA Server 2000 Exchange Server 2000/2003 Deployment Kit document. Please refer to Deploying IPSec on the Microsoft TechNet site.

 

Figure 88

 

26.   You will need to repeat the procedure on the back-end Exchange Servers. The only difference between the policy you created on the front-end Exchange Sever and the back-end Exchange Servers is few settings in the IP Filter. Figure 89 shows the IP Traffic Source page of the IP Filter Wizard. On the back-end Exchange Servers, make sure you use the back-end Exchange Server’s address in the source address text box.

 

Figure 89

 

27.   The Destination address on the back-end Exchange Servers is set for My IP address (figure 90).

 

Figure 90

 

28.   The protocol type on the back-end Exchange Server’s is Any. Again, the same as what we did with the front-end Exchange Servers (figure 91).

 

Figure 91

 

29.   After the IPSec Policies are created on the front-end and back-end Exchange Servers, right click on the policy you created to secure communications between the front-end and back-end Exchange Servers and click the Assign command (figure 92).

 

Figure 92

 

30.   When the policy is assigned, you will see a Yes entry in the Policy Assigned column (figure 93).

 

Figure 93

 

31.   You can test the policy by opening a command prompt and typing the command:

 

ping –t w.x.y.z

 

where w.x.y.z is the IP address of another Exchange Server included in the IP filter list. You will see the ping command report that it is negotiating IP Security and then you will see ping replies. You can see details of the IPSec negotiation and packet exchange by using the IP Security Monitor standalone mmc console snap-in (figure 91).

 

Figure 91

 

 

 

Configure the Public DNS to Resolve the Names of the OWA, POP3 and IMAP4 Sites

 

Correct DNS host name resolution is critical when designing a remote access solution. The ideal DNS configuration allows users who move between the internal and external network 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:

 

 

Internal network hosts who need to resolve names queries an internal network zone and receive the internal network IP address of the host they want to connect to. External network hosts query the external network zone and receive a public IP address they can connect to. The destination machine may be 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 to is domain.com. Your publish the POP3, IMAP4 and OWA sites of the front-end server to the Internet using ISA Server 2000 and the ISA Server is using the IP address 131.107.0.1 to listen for incoming requests for those services. The front-end Exchange Server on the internal network has the IP address 10.0.0.3.

 

Your goal is to allow all hosts, regardless of their location, to access the front-end Exchange Server using the FQDNs owa.domain.com, pop3.domain.com and imap4.domain.com. You want hosts on the internal network to connect directly to the front-end Exchange Server using the IP address 10.0.0.3 and remote hosts connecting from the Internet to use IP address 131.107.0.1 to access the front-end Exchange server.

 

The solution is to create a 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 front-end Exchange Server, you would create three Host (A) records: one for owa.domain.com, one for pop3.domain.com and the last one for imap4.domain.com and all three of these map to the IP address 131.107.0.1.

 

You then create a second DNS server, this one being on the internal network behind the ISA Server firewall. The internal network DNS server also hosts a zone for the domain.com domain. You create three Host (A) resource records on the internal network DNS server within the domain.com zone: one for owa.domain.com, one for pop3.domain.com and the last one for imap4.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, then 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, then it will be able to resolve the names associated with the front-end Exchange Server to its internal address.

 

 

Install the CA Certificate on the OWA, POP3 and IMAP4 Clients

 

You must install the root CA certificate of the certificate authority that assigned the front-end Exchange Server’s services their certificates onto the remote OWA, POP3 and IMAP4 clients. There are a number of ways to do this. Please refer to the ISA Server 2000 Exchange Server 2000/2003 Deployment Kit document How to Import the Root CA Certificate into Email Client Certificate Stores

.