Configuring ISA Server 2000 to Support Outlook 2003 RPC over HTTP – Part 1: Preparing the Infrastructure and Configuring the Front-End Exchange Server

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

Its important to keep in mind that from a security viewpoint, 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 requirements, is secure ISA Server 2000 secure Exchange RPC publishing because of the very high level of security enforced by the intelligent layer 7 aware ISA Server 2000 RPC filter. The RPC over HTTP publishing mechanism is not able to use the ISA Server 2000 Exchange RPC filter and does not provide protection against illegal commands that may be sent over the HTTP tunnel to RPC servers.

This is not to say that RPC over HTTP publishing is insecure. The fact is that the RPC over HTTP connection can be made extremely secure using a wide range of Windows 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 an ISA Server firewall 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 HTTP commands and content using URLScan and other security filters. The ISA Server firewall passes the RPC over HTTP messages to the front-end Exchange Server only after they have passed a security inspection. No other firewall in ISA Server’s class is able to provide this type of protection.

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.

While the front-end/back-end Exchange Server configuration provides the highest level of security and flexibility for your RPC over HTTP Exchange Publishing solution, this is not the only way to accomplish this task. The RPC over HTTP proxy can be a standalone IIS 6.0 server running on Windows Server 2003. In fact, the RPC over HTTP proxy can be installed on the ISA Server 2000 firewall computer, thus obviating the need to install a separate machine as an RPC over HTTP proxy. If you have a single Exchange Server, you can install the service on the Exchange Server itself and allow inbound RPC over HTTP access that way.

In this series of articles we will go over all the step by step details required to allow inbound RPC over HTTP access to the front-end Exchange Server in a front-end/back-end Exchange Server environment. If enough of you show interest, I’ll write articles in the future on how to implement the ISA Server 2000 firewall as the RPC over HTTP proxy. Send me a note at [email protected] if you’re interested in other implementations.

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.

The ISA Server 2000 Exchange Server 2000/2003 Deployment Kit document

The ISA Server 2000 Exchange Server 2000/2003 Deployment Kit documents

Issuing certificates via autoenrollment

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.

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 the RPC commands and information 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 (or wraps) the RPC reply it received from the back-end Exchange Server in an HTTP header and forwards this reply to the external 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.
2. In the Windows Components dialog box, click on the Networking Services entry in the Components list and then click the Details button.

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

4. Click Next in the Windows Components dialog box, click Next.
5. An Insert Disk dialog box may appear asked you to insert the Windows CD-ROM. Click OK.
6. Enter a path to the i386 folder in the Files Needed dialog box. Click OK.
7. Click Finish on the Completing the Windows Components Wizard page.

Close the Add or Remove Programs window.

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

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.

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

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

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

The figure below shows the first step in the SSL to SSL bridging scenario:

The ISA Server 2000 firewall impersonates the front-end RPC over HTTP Web site by presenting the RPC over HTTP proxy’s Web site’s certificate to the remote RPC over HTTP client. The name of the RPC over HTTP 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, expand the Web Sites node and click on the Default Web Site entry. Right click on Default Web Site and click Properties.
2. Click on the Directory Security tab in the Default Web Site Properties dialog box. Click on the View Certificate button.
3. In the Certificate dialog box, click on the Details tab. Click on the Copy to File button.

4. Click Next on the Welcome to the Certificate Export Wizard page.
5. Select the Yes, export the private key option on the Export Private Key page. Click Next.

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

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.
8. On the File to Export page, 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.
9. Review your settings on the Completing the Certificate Export Wizard page and click Finish.
10. Click OK on the Certificate Export Wizard dialog box that informs you the export was successful.
11. Close the Certificate dialog box.

12. Close the Default Web Site Properties dialog box.

In the second part of this article we’ll make some Registry edits on the front-end Exchange Server and configure IPSec Policies that force IPSec transport mode connections between the front-end and back-end Exchange Servers.

Part 2 of this article can be found at:
http://isaserver.org/articles/rpchttppart2.html