Configuring ISA Server 2000 to Support Outlook 2003 RPC over HTTP
Part 1: Preparing the Infrastructure and Configuring the Front-End Exchange Server
By Thomas W Shinder M.D.
Part 2 of this article can be found at:
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).
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 powerful 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 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@example.com if you’re interested in other implementations.
The figure below shows the basic network topology for the configurations cover in this article.
In this, part 1 of this series on enabling inbound RPC over HTTP access to the front-end Exchange Server, we will cover the following procedures:
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.
The ISA Server 2000 Exchange Server 2000/2003 Deployment Kit documentCreating the enterprise CA contains detailed information on how to install and configure a Microsoft enterprise CA.
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.
The ISA Server 2000 Exchange Server 2000/2003 Deployment Kit documentsIssuing certificates via the MMC snap-in for detailed information on how to issue machine certificates to the front-end and back-end Exchange Servers
There are no special requirements for the back-end Exchange Server in the RPC over HTTP publishing scenario. In our current example 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 necessarily 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.
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 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:
- 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.
- In the Windows Components dialog box, click on the Networking Services entry in the Components list and then click the Details button.
- In the Networking Services dialog box, put a checkmark in the RPC over HTTP Proxy checkbox and click OK.
- Click Next in the Windows Components dialog box, click Next.
- An Insert Disk dialog box may appear asked you to insert the Windows CD-ROM. Click OK.
- Enter a path to the i386 folder in the Files Needed dialog box. Click OK.
- Click Finish on the Completing the Windows Components Wizard page.
Close the Add or Remove Programs window.
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 enable 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:
- 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.
- In the Default Web Site Properties dialog box, click select your IP address from the list of IP addresses in the IP address list.
- Click Apply and then click OK in the Default Web Site Properties dialog box and then close the Internet Information Services (IIS) Manager console.
The front-end Exchange Server’s Web site requires a certificate. This allows you to 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.
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.
The ISA Server 2000 firewall computer performs SSL to SSL bridging to protect the connection from the remote RPC over HTTP 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 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:
After the first SSL tunnel is established and the packets pass inspection, a second tunnel between the ISA Server firewall and the front-end Exchange Server is established:
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 from the RPC over HTTP client, to the ISA firewall, to the front-end Exchange Server and finally to the back-end Exchange Server.
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:
- 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.
- Click on the Directory Security tab in the Default Web Site Properties dialog box. Click on the View Certificate button.
- In the Certificate dialog box, click on the Details tab. Click on the Copy to File button.
- Click Next on the Welcome to the Certificate Export Wizard page.
- Select the Yes, export the private key option on the Export Private Key page. Click Next.
- 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.
- 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.
- 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.
- Review your settings on the Completing the Certificate Export Wizard page and click Finish.
- Click OK on the Certificate Export Wizard dialog box that informs you the export was successful.
- Close the Certificate dialog box.
- Close the Default Web Site Properties dialog box.
In this, part 1 of our series on how to publish RPC over HTTP proxies to allow Outlook 2003 clients to use RPC over HTTP to connect to Microsoft Exchange, we went over some basic network infrastructure tasks. We setup the certificate services and installed the RPC over HTTP proxy service on the front-end Exchange Server. We then requested a certificate for the RPC over HTTP Web site and exported the certificate to a file which we will later install on the ISA Server 2000 firewall computer.
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:
I hope you enjoyed this article and found something in it that you can apply to your own network. If you have any questions on anything I discussed in this article, head on over to http://forums.isaserver.org/ultimatebb.cgi?ubb=get_topic;f=5;t=002297 and post a message. I’ll be informed of your post and will answer your questions ASAP. Thanks! –Tom
If you would like us to email you when Tom Shinder releases another article on ISAserver.org, subscribe to our 'Real-Time Article Update' by clicking here. Please note that we do NOT sell or rent the email addresses belonging to our subscribers; we respect your privacy!