Recipe10.10.Setting Up RPC over HTTPS

Recipe 10.10. Setting Up RPC over HTTPS

Problem

You want to enable RPC tunneling over HTTPS so that your Outlook 2003 users can use Outlook directly against your servers.

Solution

Setting up RPC over HTTPS is easier in Exchange Server 2003 SP1 than it was in the original release version, but it's still a reasonably involved task that requires you to know a good bit about your Exchange topology, and to understand the underlying mechanics. There are three basic steps:

1. Setting up an RPC-over-HTTP proxy. This step requires a Windows Server 2003 computer, on which the proxy runs; the proxy's job is to disassemble incoming HTTP packets that contain RPC traffic and convert them into conventional RPC traffic, then reverse the process for reply packets.

2. Configuring the Exchange front-end servers. This process is very simple, requiring nothing more than clicking a radio button; however, it must be done separately for each Exchange FE.

3. Configuring the Exchange back-end servers. This is also a matter of a single click of a radio button.

Using a graphical user interface

To install the RPC-over-HTTP proxy, do the following:

1. Log in to the front-end server using an account with Windows administrative privileges.

2. From the Control Panel, open the Add or Remove Programs applet.

3. Click Add/Remove Windows Components.

4. Select Networking Services and click the Details button.

5. Ensure that the RPC over HTTP Proxy box is checked and click OK.

6. Click Next (you may need to pop in your Windows Server 2003 CD during the install process).

To enable RPC-over-HTTP on an Exchange front-end server, do the following:

1. Launch the Exchange System Manager (Exchange System Manager.msc).

2. In the left pane, expand the appropriate Administrative Groups container, and then expand the Servers container.

3. Open the Properties dialog for the front-end server you're configuring and switch to the RPC-HTTP tab.

4. Select the RPC-HTTP front-end server radio button and click OK.

5. You'll see a dialog warning you that SSL is required for use with RPC-over-HTTP; click OK to close it.

6. Repeat steps 1-5 for each additional front-end server that you want to accept RPC-over-HTTP requests.

To configure an Exchange back-end server, do the following:

1. Log on to your Exchange server using an account that has Exchange administrative privileges.

2. Launch the Exchange System Manager (Exchange System Manager.msc).

3. In the left pane, expand the appropriate Administrative Groups container, and then expand the Servers container.

4. Open the properties dialog for the back-end server you want to configure and switch to the RPC-HTTP tab.

5. Select the RPC-HTTP back-end server radio button and click OK.

6. If you see a warning dialog telling you that you don't have any RPC-HTTP front-end proxies, click OK to close it.

7. If you're configuring a back-end server that also happens to be a domain controller, you'll see a warning dialog that tells you that the ports aren't configured right (see Figure 10-3). Click OK to configure the ports automatically, but be forewarned: you'll need to reboot your server before the changes take effect.

8. Repeat steps 1-6 for each additional back-end server you want to configure.

Figure 10-3. The warning dialog produced when you enable RPC-over-HTTP on a domain controller

To configure SSL offloading for the front-end, do the following:

1. Log on to the RPC proxy server (which may be your Exchange front-end, or another Windows Server 2003 computer) using an account with administrative privileges.

2. Open the Registry Editor (regedit.exe).

3. Navigate to HKEY_LOCAL_MACHINE\ Software\Microsoft\Rpc\RpcProxy.

4. Right-click on RpcProxy and select New DWORD to add a new DWORD value named AllowAnonymous.

5. In the right pane, right-click the AllowAnonymous entry and select Modify.

6. In the Value data field, type 1 and click OK.

7. Quit the Registry Editor.

8. Use the Services snap-in or command line to stop and restart the World Wide Web Publishing Service (w3svc).

To configure a single-server Exchange Server 2003 organization, do the following:

1. Log in to your Exchange server and follow the previous steps for configuring an Exchange back-end server.

2. Open the IIS Manager snap-in (%SystemRoot%\system32\inetsrv\iis.msc).

3. Locate and expand the target server's Default Web Site object, then right-click the RPC virtual directory and select Properties.

4. Switch to the Directory Security tab and click the Edit button in the Authentication and access control group.

5. Clear the Enable anonymous access checkbox; set the Basic authentication (password is sent in clear text) and Integrated Windows authentication checkboxes. Click OK.

6. Click OK.

7. Open the Registry Editor (regedit.exe)

8. Navigate to HKEY_LOCAL_MACHINE\ Software\Microsoft\Rpc\RpcProxy.

9. Right-click the ValidPorts value and select Modify. You'll need to change its value to open ports 6001 and 6004 to your server, for which you'll need the NetBIOS and fully qualified domain names of your server. Format the string like this:

   <serverNetBIOS>:6001;<serverFQDN>:6001;<serverNetBIOS>:6004;<serverFQDN>:6004;

   
   

   where <serverNetBIOS> is the NetBIOS name of your Exchange server and <serverFQDN> is the full DNS name (e.g., someserver.oreilly.com).

If your Exchange back-end server is also a global catalog server, you have to force the directory service to use the correct TCP port for queries. To do so, follow these steps:

1. Open the Registry Editor (regedit.exe).

2. Navigate to HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters.

3. Right-click on Parameters and select New Multi String Value. Name the new value NSPI interface protocol sequences.

4. Right-click the new NSPI interface protocol sequences value and select Modify. Change the value to contain ncacn_http:6004.

5. Quit the Registry Editor and restart the server.

Discussion

One of the biggest new features of Exchange Server 2003 is its ability to work with Outlook 2003 to tunnel remote procedure call (RPC) traffic inside of ordinary-looking HTTP packets. This might not seem like a big deal, but it is. Microsoft has long recommended against allowing random Internet clients to send RPCs directly into your networka number of serious vulnerabilities in the Windows NT RPC stack led to this policy, and it's very rare to find exceptions. That means that Outlook, which uses RPCs to exchange MAPI data with the server, needs an unobstructed path between the Outlook machine and the Exchange server. Previously, there were three primary ways to accomplish this: allow raw RPC traffic from the Internet, use ISA Server to publish the RPC interfaces, or allow Outlook users to establish VPN connections to the corporate network. This new feature adds a fourth way: when enabled, Outlook 2003 takes its RPC requests and encapsulates them in an HTTP packet, which it then sends using HTTP (preferably with SSL) to an RPC proxy server. This server breaks apart the HTTP packet and redirects the RPC requests to the Exchange back-end server, returning any results to the client in an encapsulated HTTP packet.

The advantages of this are obvious: it allows the Outlook client to connect without needing a VPN (and thus without any special configuration or, worse, proprietary VPN clients on the client machine), but it doesn't allow raw RPC traffic from the Internet. If you wish, you can use ISA Server to perform application-level inspection of the RPC packets as they come in, but that's not mandatory. However, there are some prerequisites: to use RPC-over-HTTP, you must have Exchange Server 2003 running on Windows Server 2003, and all GCs that Exchange or the clients will talk to must also be running Windows Server 2003. Outlook 2003, running on Windows XP SP1 or later, is required as the client.

Overall, the configuration and setup process for RPC-over-HTTP is fairly straightforward; it was greatly improved with the release of SP1, which introduced the RPC-HTTP tab in the server properties dialog. One significant speed bump is that the server SSL certificate installed on the RPC proxy must match the common name that the client uses to connect. Let's say you've configured a client to connect to exchange.robichaux.net, and that your RPC proxy is named spiderman.robichaux.net and has a certificate by that name. Because the names don't match, the SSL handshake will fail (as described in MS KB 822594). To fix this, either change the RPC proxy name specified on the Outlook client or get a new certificate for the RPC proxy itself.

What about SSL offloading? This term is a little misleading in this context. It would probably be more proper to talk about SSL termination, since the steps in this recipe are required when you want to terminate an inbound RPC-over-HTTPS connection at an ISA server (or other firewall), then pass the unencrypted traffic to the RPC proxy server, then to the back-end server. In most configurations, it's easier to either allow SSL bridging so that the proxy sees an SSL connection or to put the proxy service on the firewall machine so that the termination happens at the proxy.

See Also

"Configuring Outlook 2003 for RPC over HTTP" topic in the Outlook 2003 Resource Kit (www.microsoft.com/office/ork/2003/three/ch8/OutC07.htm), Exchange Server 2003 RPC over HTTP Deployment Scenario Guide (http://www.microsoft.com/technet/prodtechnol/Exchange/guides/E2k3RPCHTTPDep/1583ab17-f7d1-41c1-ba52-37ec276e3644.mspx), MS KB 833401 (How to configure RPC over HTTP on a single server in Exchange Server 2003), MS KB 841652 (How to configure an RPC over HTTP topology on computers that are running Exchange Server 2003 with Service Pack 1), MS KB 827330 (How to troubleshoot client RPC over HTTP connection issues in Office Outlook 2003), MB KB 833003 (Description of the RPC over HTTP feature and the AllowAnonymous registry entry in Windows Server 2003), and MS KB 822594 (Remote Procedure Call over HTTP Is Not Successful or Reverts to TCP)