Improve the Security of Remote Access to Exchange Server with RPC over HTTP

Excerpt from the Tips and Tricks Guide to Secure Messaging

See other Security Tip of the Month columns

One of the most compelling features of Microsoft Exchange Server 2003 when combined with Microsoft Office Outlook 2003 is the ability to use the Remote Procedure Call (RPC) over HTTP feature. RPC over HTTP enables a remote Outlook client to encapsulate RPC data inside HTTP frames (see Figure 1). The only port that is required to be opened on a firewall is the HTTP or HTTPS port. Opening the necessary RPC ports between the client and the server is considered a security risk.

Figure 1. Typical RPC over HTTP implementation

RPC over HTTP can greatly reduce the support necessary for virtual private network (VPN) users because a VPN is no longer required for Outlook 2003 users. Without RPC over HTTP, many users keep a full-time VPN connection open almost exclusively for Outlook access to the Exchange Server.

Switching users from a VPN connection on their home or laptop computer to an RPC over HTTP connection only to Exchange both provides users with the functionality they require from their mail system and helps improve security on the internal network. The RPC over HTTP session is only established to an RPC over HTTP proxy and limits the remote client’s potential access to other hosts on the internal network. This configuration for remote Outlook 2003 clients potentially also reduces the number of ports that need to be opened on a firewall and thus improves security.

A possible downside is that configuring RPC over HTTP is slightly more complex than configuring Outlook 2003 to connect directly to the Exchange Server. If the choice is either to use RPC over HTTP or a VPN connection, the benefits and reduced complexity will outweigh the additional configuration. When deciding whether RPC over HTTP can be implemented for your organization, a couple of factors need to be considered. They are:

• Does your server infrastructure have the minimum software versions required?

• Do the clients have the minimum software versions required?

• Can you deploy reverse proxy solutions for RPC over HTTP to provide an additional layer of protection?

Requirements

Before implementing RPC over HTTP, you need to make sure that all the components within your network meet the minimum requirements. The following is a checklist of the minimum requirements for the servers on your network:

• All Exchange Servers must be running Exchange Server 2003, but I strongly recommend Exchange Server 2003 SP1 or a later version because of improvements in configuration. It must be running on Windows 2003.

• All domain controllers/Global Catalog (GC) servers must be running Windows 2003.

• A server on the inside of your network must be designated as the RPC Proxy server. In a small, single Exchange Server environment, the RPC Proxy service will run on the same server as the Exchange Server. In a large environment, you should use the same server or servers on which the Exchange 2003 front-end servers run.

• The RPC Proxy server must be issued an SSL certificate, and the certificate authority that issues the certificate must be trusted by all client computers.

On the client side, there is also a minimum configuration. The following are requirements for the client:

• Outlook 2003 (recommend Outlook 2003 SP1 or later).

• Windows XP Pro SP1 with the hotfix in KB 331320, though that hotfix is applied in Windows XP SP2.

• The certifying authority that issued the SSL certificate for the RPC Proxy must be trusted by the client.

Deployment Scenarios

There are many potential permutations of configuration possibilities for RPC over HTTP. Figure 1 above shows a typical deployment of RPC over HTTP for Internet-based clients; this environment can easily be scaled up for larger environments or scaled back for single-server organizations.

One of the most important security precautions that is in place for the organization represented by Figure 1 is that a reverse proxy server such as Internet Security and Acceleration (ISA) Server is used to publish the RPC over HTTP resource to the Internet. Internet clients do not connect directly to the RPC Proxy server running on the Exchange 2003 front-end server; instead, they connect to the ISA Server. The ISA Server authenticates the connection, offloads the Secure Sockets Layer overhead, and validates URLs before passing the RPC over HTTP data on to the RPC Proxy server.

This deployment can easily be scaled up to larger organizations by merely adding additional ISA Server or reverse proxy servers in the perimeter network (the DMZ) and configuring load balancing and then adding Exchange 2003 front-end servers on the internal network.

In a single-server environment, the organization may have a single firewall and Exchange Server. RPC over HTTP can easily be scaled back to this point and still provide reverse proxy security. Figure 2 below shows how a small organization can use RPC over HTTP just as securely as a large organization.

Figure 2. Single server and single firewall scenario

In this scenario, Exchange Server 2003 also has the RPC Proxy component installed, so only a single server is required.

There are a number of possible deployment scenarios for RPC over HTTP depending on the size of your organization. For more information, read “Exchange Server 2003 RPC over HTTP Deployment Scenarios.”

For more tips on how to improve the security of your messaging infrastructure, download the Tips and Tricks Guide to Secure Messaging at the Web site.