Configuring ISA Server 2000 to Support Outlook 2003 RPC over HTTP

 

Exchange Server 2003 allows Outlook 2003 clients installed on Windows XP Service Pack 1 and above full MAPI client access using the new RPC over HTTP protocol. RPC over HTTP allows the RPC commands required for full Outlook 2003 MAPI client access to wrapped or “encapsulated” in an HTTP header and passed through proxies that allow outbound HTTP.

 

In addition, you can secure RPC over HTTP communications using SSL. The RPC over HTTP protocol solves the problem of remote access to the full suite of Exchange Server 2003 services through firewalls that allow only HTTP and HTTPS (SSL) outbound to the Internet. Another advantage of the RPC over HTTP protocol is that it can leverage the security and functionality provided by the front-end/back-end Exchange Server configuration.

 

Its important to keep in mind that in an ISA Server 2000 remote access environment, the RPC over HTTP solution should be thought of as a “second best” method of remote access for the full Outlook 2003 MAPI client. The preferred method, in terms of high security, is secure Exchange RPC publishing because of the security enforced by the intelligent layer 7 aware ISA Server 2000 RPC filter. The RPC over HTTP publishing mechanism does not leverage the security provided by the ISA Server 2000 Exchange RPC filter and does not protect against illegal commands that may be sent to RPC servers.

 

However, this is not to say that RPC over HTTP publishing is without security. The fact is that the RPC over HTTP connection can be made extremely secure using a wide range of security technologies.  The connection between the remote Outlook 2003 client and the external interface of the ISA Server 2000 firewall is protected by SSL. And because ISA Server is able to perform SSL bridging, the connection between the internal interface of the ISA Server firewall and the front-end Exchange Server is also protected by an SSL link.

 

SSL to SSL bridging allows the ISA Server firewall to inspect the RPC over HTTP packets for illegal commands using URLScan and other security filters. The ISA Server firewall passes the RPC over HTTP messages to the front-end Exchange Server after they have passed a security inspection.

 

You can further enhance the security on the RPC over HTTP connection by requiring a transport mode IPSec connection between the front-end and back-end Exchange Servers. This allows end to end encryption between the Outlook 2003 client and the back end Exchange Server. It is important to insure this type of end to end encryption because the client has an implicit expectation of end to end encryption when it establishes a secure link with the external interface of the ISA Server firewall.

 

You need to carry out the following procedures to create a secure RPC over HTTP publishing solution using ISA Server 2000:

 

 

 

 

Install an Enterprise Certificate Authority

 

The Microsoft enterprise Certificate Authority (CA) allows you to issue certificates to all machines in the Active Directory domain. You can install a Microsoft CA in either standalone or enterprise mode. There are two primary advantages of using an enterprise CA over a standalone CA:

 

 

You will use the Microsoft enterprise CA to install machine certificates on the front end and back end Exchange Servers. These certificates will be used for authentication when you create the IPSec Policy to secure the link 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 detailed information on how to install and configure a Microsoft enterprise CA.

 

 

 

Assign Machine Certificates to the Front End and Back End Exchange Servers

 

You can use the enterprise CA to assign machine certificates to the front-end and back-end Exchange Servers. You can use Group Policy to assign these machine certificates or you can use the Certificates MMC standalone snap-in to assign the certificates.

 

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

Issuing certificates via autoenrollment and Issuing certificates via the MMC snap-in for detailed information on how to issue machine certificates to the front-end and back-end Exchange Servers

 

 

 

Install the Back End Exchange Server

 

There are no special requirements for the back-end Exchange Server in the RPC over HTTP publishing scenario. In the example covered in this ISA Server 2000 Exchange Server 2000/2003 Deployment Kit document, we assume the back-end Exchange Server is a domain controller for the domain that all Exchange Servers belong to. While we realize that it is not best practice, this is the configuration we use on the lab network setup in this document.

 

Please refer to TechNet document Microsoft Exchange 2000 Server Front-End and Back-End Topology for details on specific requirements for front-end and back-end Exchange Servers.

 

 

 

Install the Front End Exchange Server and the RPC over HTTP Service

 

The front-end Exchange Server acts as a “proxy” for RPC messages that are carried via the HTTP protocol. This proxy function allows the front-end Exchange Server to receive the RPC messages contained within the HTTP protocol headers and forward these messages to the back-end Exchange Server.

 

The front-end Exchange Server is a proxy for these messages because the front-end Exchange server is not the endpoint for these messages. The front-end Exchange Server only accepts these messages, removes the HTTP header, and forwards them to the back end Exchange Server. When the back-end sends its replies, the replies are accepted by the front-end Exchange Server that’s acting as a RPC over HTTP proxy. The front-end Exchange Server encloses the RPC reply it received from the back-end Exchange Server in an HTTP header and forwards this reply to the Outlook 2003 client.

 

Install and configure the front-end Exchange Server according to the guidelines in Microsoft Exchange 2000 Server Front-End and Back-End Topology. After the front-end Exchange Server is installed, the next step is to install the RPC over HTTP Proxy networking service.

 

Perform the following steps to install the RPC over HTTP Proxy networking service on the front-end Exchange Server:

 

  1. Click Start, point to Control Panel and click on Add or Remove Programs. In the Add or Remove Programs window, click on the Add/Remove Windows Components button (figure 1).

 

Figure 1

 


  1. In the Windows Components dialog box, click on the Networking Services entry in the Components list and then click the Details button (figure 2).

 

Figure 2

 


  1. In the Networking Services dialog box (figure 3), put a checkmark in the RPC over HTTP Proxy checkbox and click OK.

 

Figure 3

 


  1. Click Next in the Windows Components dialog box, click Next (figure 4).

 

Figure 4

 


  1. An Insert Disk dialog box may appear asked you to insert the Windows CD-ROM (figure 5). Click OK.

 

Figure 5

 


  1. Enter a path to the i386 folder in the Files Needed dialog box (figure 6). Click OK.

 

Figure 6

 


  1. Click Finish on the Completing the Windows Components Wizard page (figure 7).

 

Figure 7

 

Close the Add or Remove Programs window.

 

 

 

Configure the Front End Exchange Server Web Service to Listen on a Single IP Address

 

You should configure the front-end Exchange Server’s Web site to listen on a specific IP address. This helps facilitate the Web or Server Publishing Rules you create on the ISA Server firewall that allow inbound access to the RPC over HTTP service on the front-end Exchange Server.

 

Perform the following steps to configure the front-end Exchange Server to listen on a specific IP address:

 

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

 

Figure 8

 

2.       In the Default Web Site Properties dialog box, click select your IP address from the list of IP addresses in the IP address list (figure 9).

 

Figure 9

 

3.       Click Apply and then click OK in the Default Web Site Properties dialog box and then close the Internet Information Services (IIS) Manager console (figure 10).

 

Figure 10

 

 

 

Request and Install a Web Site Certificate on the Front End Exchange Server

 

The front-end Exchange Server’s Web site requires a certificate so that you can enforce SSL connections between the ISA Server firewall and the front-end Exchange Server. In addition, the front-end Exchange Server’s Web site requires a certificate so that the ISA Server firewall can impersonate the site when external Outlook 2003 clients create an SSL link with the firewall’s external interface.

 

You will then export the Web site certificate after the front-end Exchange Server obtains a certificate. The exported file is copied to the ISA Server firewall and imported into the firewall’s local machine certificate store and bound to the Incoming Web Requests listener.

 

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 a Web site certificate for the front-end server.

 

 

 

Export the Web 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 to the front-end server, 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 all invalid packets. The ISA Server firewall then establishes a second SSL session between its own internal interface and the front-end Exchange Server, 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 11), expand the Web Sites node and click on the Default Web Site entry. Right click on Default Web Site and click Properties.

 

Figure 11

 

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

 

Figure 12

 

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

 

Figure 13

 

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

 

Figure 14

 

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

 

Figure 15

 

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

 

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

 

Figure 17

 

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

 

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

 

Figure 19

 

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

 

Figure 20

 

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

 

Figure 21

 

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

 

Figure 22

 

 

 

 

Force SSL and Basic Authentication on the RPC Directory

 

The external Outlook 2003 clients will use SSL to connect to the external interface of the ISA Server firewall. The ISA Server firewall uses SSL to protect the connection between the internal interface of the firewall and the front-end Exchange Server’s Web site. The Outlook 2003 client will use basic authentication to authenticate with the ISA Server firewall’s Incoming Web Requests listener and the firewall will forward these basic credentials to the front-end Exchange Server’s Web site.

 

You need to force basic authentication on the front-end Exchange Server’s RPC directory to insure the best performance and compatibility. The user credentials are protected by SSL encryption so you do not need to worry about the clear text credentials being captured by an intruder. In addition, we will force an SSL connection between the firewall and the RPC directory. This presents any host, including the firewall, from using a non-secure connection to the front-end server’s RPC directory.

 

Perform the following steps to force basic authentication and SSL encryption on the front-end Exchange Server’s RPC directory:

 

1.       Click Start, point to Administrative Tools and click on Internet Information Services (IIS) Manager. In the Internet Information Services (IIS) Manager, expand your server name and then expand the Web Sites node. Click the Rpc node in the left pane of the console and right click an empty area in the right pane. Click on the Properties command (figure 23).

 

Figure 23

 

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

 

Figure 24

 

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

 

Figure 25

 

4.       Click the Edit button in the Authentication and access control frame (figure 26).

 

Figure 26

 

5.       In the Authentication Methods dialog box (figure 27), put a checkmark in the Basic authentication (password is sent in clear text) checkbox.

 

Figure 27

 

6.       An IIS Manager dialog box appears informing your that there are risks to using basic authentication. That’s OK because we’re using SSL to protect the credentials and the data. Click Yes (figure 28).

 

Figure 28

 

7.       Remove the checkmarks from the Enable anonymous access and Integrated Windows authentication checkboxes (figure 29). Click OK.

 

Figure 29

 

8.       Click Apply and then click OK in the Rpc Properties dialog box (figure 30).

 

Figure 30

 

9.       Close the Internet Information Services (IIS) Manager (figure 31).

 

Figure 31

 

Close the Internet Information Services (IIS) Manager console.

 

 

 

Configure the Registry Entries on the Front End Exchange Server

 

The front-end Exchange Server that is acting as an RPC over HTTP proxy server needs to know the names of the back-end Exchange Servers and global catalog servers. You will need to navigate to the Registry key HKEY_LOCAL_MACHINE\Software\Microsoft\Rpc\RpcProxy and change the value of the Valid Ports entry.

 

The change to the ValidPorts value is entered using the following format:

 

ExchangeServerFQDN:593;ExchangeServerFQDN:1024-65535;GlobalCatalogServerFQDN:593;GlobalCatalogServerFQDN:1024-65535

 

Note:
These entries are entered as a single line in the Registry editor; the edit value dialog box does not wrap line.

 

For example, if the back-end Exchange Server is named beexchange2003.internal.net and the Global Catalog Server is named dc.internal.net, the entries would look like this:

 

beexchange2003.internal.net:593; beexchange2003.internal.net:1024-65535; dc.internal.net:593; dc.internal.net:1024-65535

 

You will use fully qualified domain names in this Registry entry. The internal network DNS infrastructure should already be in place because these machines all belong to an Active Directory domain. The front-end Exchange Server must be able to resolve the FQDNs of the back end Exchange and Global Catalog servers.

 

Note:
You do not need to configure specific ports to be used on the Global Catalog server because the Global Catalog server and the Exchange Servers are ISA Server firewall LAT hosts. LAT hosts have full access to each other and communications between them are not screened by firewall policy. Never put a front-end Exchange Server on a DMZ segment.

 

Perform the following steps to configure the Registry on the front-end Exchange Server:

 

1.       Click Start and then click the Run command. Type regedit in the Open text box and click OK. In the Registry Editor, drill down to the following Registry key:

 

HKEY_LOCAL_MACHINE\Software\Microsoft\Rpc\RpcProxy

 

Right click on the ValidPorts value and click Modify (figure 32)

 

Figure 32

 

2.       Enter the information in the Value Data text box for the back-end Exchange Server and the Global Catalog server using the format:

 

ExchangeServerFQDN:593;ExchangeServerFQDN:1024-65535;GlobalCatalogServerFQDN:593;GlobalCatalogServerFQDN:1024-65535

 

Click OK after entering the information.

 

Figure 33

 

Restart the front-end Exchange Server computer.

 

 

 

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

 

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 applying IPSec Policies to force a secure, encrypted link between the front-end and back-end Exchange servers. The IPSec encrypted link protects 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 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 in 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 34).

 

Figure 34

 

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

 

Figure 35

 

3.       On the IP Security Policy Name page (figure 36), 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 36

 

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

 

Figure 37

 

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

 

Figure 38

 

6.       The Properties dialog box for the policy appears (figure 39). 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 39

 

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

 

Figure 40

 

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

 

Figure 41

 

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

 

Figure 42

 

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

 

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

 

Figure 44

 

12.