Tunneling RPC over HTTPS


Not every site can deploy ISA Server. This is unfortunate, because ISA Server provides application-level screening of RPC packets to validate them before they enter your network. As I described earlier, using ISA Server gives you an easy way to provide native Outlook functionality to your users without compromising the security of your Exchange network by directly exposing your servers RPC ports to the Internet. With the right combination of parts , though, you can allow your Outlook 2003 users to have full functionality without using ISA Server s RPC publishing feature. This magic is accomplished through a new feature in Exchange Server 2003: the ability to tunnel RPC packets over plain old Hypertext Transfer Protocol (HTTP) connections. This functionality is normally known as RPC over HTTP; because it s more secure to tunnel RPC over HTTP Secure (HTTPS), that s how I ll refer to it here.

The system requirements for using RPC over HTTPS are simple. On the server, you need Exchange Server 2003 running on Windows Server 2003. That s because the actual RPC-over-HTTPS proxy is a Windows service (remember, Windows owns the RPC communication stack), and only the Windows Server 2003 version of the stack supports tunneling. The client must be using Outlook 2003 with Windows XP Service Pack 1 or later. Service Pack 1 systems require a separate hotfix (see Microsoft Knowledge Base article 331320), which is integrated in Service Pack 2 and later versions. Users have to configure their Outlook clients to use RPC over HTTPS, the process for which is described in Chapter 13, Securing Outlook. In addition, all of the global catalog (GC) servers that RPC-over-HTTPS clients will talk to must be running Windows Server 2003.

How does this magic work? There s a proxy service to which clients connect. This proxy accepts RPC packets that are encapsulated in standard HTTP or HTTPS packets, de-encapsulates them, and refers them to the appropriate back-end server. The RPC proxy can run on any IIS 6.0 machine; most of the Microsoft documentation talks about using RPC tunneling with a separate front-end proxy server, but that is not a requirement. The proxy service can be run on a single Exchange server that s acting as both front end and back end, on an Exchange front-end server, or on some random server that happens to be exposed in your perimeter network. Figure 11-18 shows the difference between using RPC over HTTPS and standard RPC; in the former case, the proxy accepts the HTTPS connection and forwards RPC packets on to the mailbox server.

click to expand
Figure 11-18: RPC tunneling versus pure RPC connectivity.

Alert readers might wonder whether there s any advantage to this configuration if you re already using ISA Server. The answer is a loud yes, because many Internet providers are blocking or filtering RPC traffic on TCP port 135, so users on those ISPs probably won t be able to make a direct RPC-only connection. In addition, combining the two provides an additional degree of security, as ISA can be used to terminate the SSL session, inspect the tunneled RPC packets as it would with a pure RPC connection, and only then allow connections to the RPC proxy service.

Setting Up RPC over HTTPS

The basic process of setting up RPC over HTTPS is fairly straightforward, although there are certainly some pitfalls awaiting the unwary. Microsoft uses a custom script internally to set up all of the parameters and settings; after complaints from customers, Exchange Server 2003 Service Pack 1 includes improvements in the configuration interface. No matter how you configure it, though, the basic process remains the same.

First, you need an SSL certificate on the front-end server, as described earlier in this chapter and (in more detail) in Chapter 14. You have to do this even if you re using ISA Server in front of your front end, because the common name (CN) of the certificate to which Outlook 2003 connects has to match the CN of the front end, even if there s an intermediary ISA Server. If you re using ISA Server, export the front-end SSL certificate and import it onto the ISA Server machine. You should be doing this even if you re not using RPC over HTTPS, because it gives you a known good backup of your server s certificate and private key.

Note  

If you re using URLSCAN, be aware that the version included with ISA Server Feature Pack 1 doesn t allow two verbs that are necessary for getting RPC tunneling to work. Make sure you add the RPC_OUT_DATA and RPC_IN_DATA verbs to the AllowVerbs section of Urlscan.ini.

Your clients will need to be able to validate this certificate; that means you might need to add the root and intermediate CA certificates for the issuers to the client. You can do this by modifying the domain certificate trust list, or by importing the certificates directly into the client (use Internet Explorer s Tools Internet Properties command, click the Content tab, click Certificates, and use the Trusted Root Certificate Authorities tab to add them).

Next , you must install the RPC proxy service. Normally, you ll do this on your Exchange front-end server, but you can actually do it on any Windows Server 2003 computer. This is a simple matter of using the Add/Remove Programs control panel (more specifically , the Add/Remove Windows Components icon therein) and picking the RPC over HTTP Proxy component from the Networking Services component (select it, then click Details to find it).

The next step involves changing some settings on the RPC virtual directory on the proxy server. To do this, you need to start the Internet Information Services Manager application and connect to the server you re using as the proxy. At that point, you can do the following:

  1. Expand the server s node, then expand its Web Sites and Default Web Site items. You ll see the RPC virtual directory beneath the Default Web Site object.

  2. Right-click the RPC virtual directory and open its Properties dialog box.

  3. Click the Directory Security tab, then click Edit in the Authentication and Access Control group .

  4. Clear the Enable Anonymous Access check box, as the proxy won t work with anonymous access enabled.

  5. Select the Basic Authentication (Password Is Sent In Clear Text) check box. IIS Manager will helpfully remind you that enabling basic authentication without requiring SSL is unadvisable from a security standpoint, but you know that already, so click Yes in the confirmation dialog box.

  6. You ll be back at the Directory Security tab. Click Edit in the Secure Communications group. When the Secure Communications dialog box appears, make sure that the Require Secure Channel (SSL) and Require 128-Bit Encryption check boxes are both selected, then click OK.

  7. Click OK to apply your changes.

    Note  

    If you re using RPC over HTTPS in conjunction with ISA Server, see Chapter 14 to learn how to use ISA s publishing functionality to securely expose your RPC tunneling proxy to Internet clients.

Configuring Ports

The RPC proxy service can be forced to use a defined set of ports to communicate with other servers on your network. This is valuable in cases where your RPC proxy is in a perimeter network that limits which ports it can pass traffic on to the internal network. By default, Exchange Server 2003 uses a simple set of ports:

  • TCP 593 for the RPC endpoint mapper service. This traffic is the equivalent of TCP port 135 traffic.

  • TCP 6001 for RPC traffic destined to the information store.

  • TCP 6002 for RPC traffic related to directory service referrals (issued when a MAPI client needs to be referred to a different directory server).

  • TCP 6004 for RPC traffic for the DSProxy service, which allows older MAPI clients (prior to Outlook 2002) to use the non-MAPI Active Directory directory service.

You ll need to open all of these ports from the proxy server to the Exchange back- end servers your front end is using; you ll also need to open TCP 593 and TCP 6004 to each GC that the front end or its clients might attempt to use. This is only half the battle; you still have to tell the other machines which ports they should listen on.

For the RPC proxy server, you need to modify the ValidPorts registry value, which is found under HKLM\Software\Microsoft\Rpc\RpcProxy . ValidPorts is a multivalued string, and its syntax takes a little getting used to. You ll need to list each server you want clients to be able to reach. If you don t list the server here, the proxy won t be able to contact it. In the string, list the server name and port number for each server. Although it s not required, Microsoft recommends listing both the NetBIOS and fully qualified DNS names for each server, to ensure that name resolution problems don t prevent your clients from working. The proxy service doesn t canonicalize names , so if the client asks for a machine named exch01, the proxy won t try exch01.contoso.com or any other better qualified name. If your clients will be making requests by IP address, you should put that in, too.

Here s an example that illustrates how this works:

 contoso-exch01:593; contoso-exch01.us.contoso.com:593;  contoso-exch01: 6001-6002; contoso-exch01.us.contoso.com:6001-6002; contoso-gc*: 6004; contoso-gc*.us.contoso.com: 6004 

In this case, note that the Exchange server (contoso-exch01) has the ports it needs listed both ways, with NetBIOS and DNS name. The GC servers are listed with a wildcard, which might be an option if your servers follow a predictable naming pattern.

When you edit these port settings, the proxy service will automatically honor them for no more than five minutes ”at that interval, it rereads the value of ValidPorts and refreshes its port list.

After making this change on the proxy, you still have to configure the GCs to use the matching set of ports. This process is somewhat different:

  1. Log on to the GC as a user with administrative privileges, then start the registry editor of your choice.

  2. Find HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters .

  3. Create a new multistring value named NSPI interface protocol sequences.

  4. Specify an initial value of ncacn_http:6004. This tells the GC to listen for proxied RPC-over-HTTP traffic on TCP port 6004, which you might recall is the default port number used by the proxy.

  5. Reboot the GC.

Disabling DCOM

Of course, just because you ve set up RPC over HTTPS for your Exchange users doesn t mean you re going to want any old traffic from the Internet coming to your servers. As an added precaution, you can disable the use of the Distributed Component Object Model (DCOM) through RPC tunneling by removing the portmapper port (TCP 593) from your ValidPorts entry.

Troubleshooting RPC over HTTPS

Many administrators have complained that getting RPC tunneling to work is too difficult. It s not always straightforward, but I can offer a few troubleshooting tips that might help.

First, if you ve set up the RPC virtual directory and certificates correctly, you should be able to use any Web browser to open the RPC directory on the proxy server, just by attempting to load http://serverName/rpc . If your attempt results in an error page that shows error 403.2, then you know your configuration is fine; if not, go back and double-check the authentication settings on the virtual directory (and be sure it s properly published with ISA, if you re using it).

Next, for more subtle troubleshooting, you can use the rpcping tool, available on the Exchange product CD. Here s a sample command line:

 rpcping /t ncacn_http /s mailboxFQDN /o RpcProxy=proxyFQDN    /u 10 /a connect /l log.txt /v 3 /I username,domain,password    /P username,domain,password /F 1 /H 1 /E /R none /b 

The first thing to note is that the switches in rpcping are case-sensitive, so be careful. The /t switch specifies the protocol to use. The /s switch specifies the FQDN of the mailbox server, and the /o switch specifies the FQDN of the RPC proxy server.

The /b switch displays the certificate subject name for the server; this shows you which certificate and root hierarchy are in use so you can check to ensure that it s correct.

If you get constant prompts for credentials on the client, one common cause is that the client cannot validate the trust path for the RPC proxy server s certificate ”make sure all of the necessary root and intermediate CA certificates have been added to the client s trust list.




Secure Messaging with Microsoft Exchange Server 2003
Secure Messaging with MicrosoftВ® Exchange Server 2003 (Pro-Other)
ISBN: 0735619905
EAN: 2147483647
Year: 2004
Pages: 189

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net