Using the Exchange RPC Filter to Publish Microsoft Exchange

Using the RPC Filter to Publish Microsoft Exchange
By Thomas W Shinder MD

I’ve done a few articles on publishing mail servers, but one area that I haven’t touched upon is how to take advantage of the RPC application filter that allows you to use Outlook MAPI clients on the Internet to access an Exchange Server on your internal network. Exchange RPC publishing is very easy to do, and provides an excellent method for your external Outlook MAPI client to connect to their Exchange message store.

Why would you want to use an Exchange RPC Server Publishing Rule? Here are some advantages:

There is a general impression that RPC connections are not secure. This is not the case when you use the Exchange RPC filter to publish Exchange Servers. The RPC filter handles the connections between the Internet Outlook client and the internal Exchange Server and creates dynamic packet filters that can only be used by specific Outlook clients.

You can configure the Outlook client to encrypt data over the connection. If you do a Network Monitor trace, you’ll find that even when the data isn’t encrypted, there is nothing interesting that you can find in the decode. When you add data encryption to the mix, you are assured of a very high level of security for your data transferred between the Outlook client and the internal Exchange Server

Exchange RPC publishing is easy! A single Server Publishing Rule allows your Internet MAPI clients to access the internal Exchange Server. It just doesn’t get much easier than that!

If you don’t use Exchange RPC Server Publishing, the only other way you can connect your remote MAPI clients to an internal network Exchange Server is to allow these clients to establish a VPN link into the internal network. While this option is a viable one for your network administrators and other trusted accounts, you do not necessarily want all your users (which might include contractors and temps), to have free reign over the corporate network from remote locations. Exchange RPC Server Publishing gets around this problem by allowing users access only to the Exchange Server and nothing more.

Users tend to balk when they have to switch applications to get the same job done. This is especially the case with mail client software. If you have standardized your users on Outlook 2000/XP, those users will want to continue to use Outlook while at home or on the road. Exchange RPC publishing gives them the ability to use the same familiar interface they use at work while at home or on the road.

The typical “on the road” Outlook client first establishes a connection to the Internet via a local ISP. The Outlook client might also be on a remote network and connects to the Exchange Server via a NAT server on the remote network. The user then opens the Outlook client. When Outlook is opened, the following communications take place:

1. Outlook establishes a connection to TCP port 135 on the external interface of the ISA Server.
   
2. The ISA Server’s Exchange RPC filter intercepts the request and forwards the request to the internal network Exchange Server. The internal network Exchange Server responds to the request by sending a port number on which the Outlook client can send its messages. The Exchange RPC filter on the ISA Server intercepts this response and opens a dynamic packet filter on its external interface. The dynamic packet filter assigns a port on the external interface of the ISA Server on which only this particular Outlook client can communicate on. Any other Internet host will not be able to use that port for inbound access The ISA Server maps this port on its external interface to the port number the Exchange Server expects to receive messages from the Internet Outlook client. In addition, when the Outlook client logs on, it registers a port on which is can receive new mail notification messages from the Exchange Server. The ISA Server RPC filter also registers this port number, creates a dynamic packet filter, and passes the new mail notification messages from the Exchange Server to the Internet Outlook client.
   
3. The ISA Server forwards the response from the Exchange Server. The Outlook client receives the port number on the external interface of the ISA Server to which it can send its messages to the Exchange Server.
   
4. The Outlook client establishes a connection to the mapped port on the external interface of the ISA Server and through that port connects to the internal network Exchange Server.

Check out the diagram below to see the sequence of events.

You need to take care of a few things before your RPC Server Publishing Rule can work correctly. These things include:

DNS issues crop up constantly on the ISAserver.org message boards and mailing list. If your DNS infrastructure isn’t in place, things just won’t work properly. If your DNS infrastructure is already setup and working, great! If its not, you need to come to terms with it and get your shop in shape.

The ideal DNS configuration is referred to as a “split DNS”. In the split DNS configuration, you maintain two separate zones, one for internal network clients to use and one for external network clients to use. These two zones will service that same domains, but the resource records on the internal DNS server will have the private IP addresses for your network clients and the external DNS server will have the public IP address for your published network resources.

For example, a common compliant is that users on the internal network can access their published Web server, www.domain.com from external network hosts but they can’t access them from internal network clients. The reason for this is related to the fact that the internal network clients are probably trying to connect to the published server via the external interface of the ISA Server because internal network clients are using the same host records as the external network clients. When you create an internal DNS server that the internal network clients can use, the internal network clients will receive the private IP address of the published server and therefore will connect directly to the server.

Now, in regards to our Exchange RPC publishing situation, you need to make sure the host name of the internal network Exchange Server is the same the host name of the server that is accessible on the Internet. For example, if the server name is exchange.domain.com on the internal network, you need to make sure that exchange.domain.com is also accessible from external network hosts. You can accomplish this with your split DNS configuration by creating a Host (A) record on your external DNS server for exchange.domain.com to point to the external interface address on the ISA Server that you are using in the Exchange RPC publishing rule.

The reason why you must configure the Host (A) record is that the name of the Exchange Server is returned to the Outlook client. The Outlook client needs to be able to communicate with the name received from the Exchange Server. Note that only the Host name portion of the FQDN will appear in the client configuration dialog box after the name is resolved.

If your organization does not use the same domain name for internally and externally accessible resources, you can still access the Exchange Server via the RPC publishing rule. In this case, all you need to do is create a HOSTS file entry with the NetBIOS name of the computer. You do not need to include the FQDN of the Exchange Server in the HOSTS file, just the NetBIOS name is required to make it work.

The Exchange Server is going to need to forward mail it receives from the Outlook client to SMTP servers on the Internet. There you will need to create two Protocol Rules:

The DNS Query and Zone Transfer Protocol Rules allow the Exchange IIS SMTP service to resolve the MX domain name records for the outgoing mail. You can configure the Protocol Rule to allow only the Exchange Server access, or you can configure it to allow all machines on the network to use it. Access control on the DNS Zone Transfer Protocol Rule depends on which machine is resolving the MX domain names. You might want to forward the queries to an internal DNS server and let the DNS server on your internal network take care of name resolution.

The SMTP Protocol Rule is required for the Exchange Server to send out mail to external mail domains. Access controls on the SMTP Protocol Rule depend on what machine actually sends the mail to the external SMTP servers. If the Exchange Server is sending the mail directly to the Internet SMTP servers, allow only the Exchange Server access to the SMTP Protocol Rule. If you are using a SMTP relay server for outbound mail, allow the relay access to the SMTP Protocol Rule. If you are using a mail relay, make sure the SMTP relay server has access to the DNS Protocol Rule as well.

When the Outlook client logs on to the Exchange Server, the Exchange Server instructs the Outlook client to authenticate to an Active Directory domain controller. If you’ve been following my antics here at www.isaserver.org/shinder, you know that it’s difficult to get authentication requests and other intradomain communications through the ISA Server. To get around this problem, you can configure the Exchange Server to perform authentication on the behalf of the Outlook client and forward the authentication traffic through the RPC connection to the Outlook client.

To configure the Exchange Server to proxy authenticate requests for the Outlook client, navigate to the following registry key:

Add the following:

Value: No RFR Service

Type: REG_DWORD

Data: 1

Note the value does have spaces in it. At first I thought this might have been a typo in the Microsoft White Paper I got this from, but I confirmed that this value indeed is correct and the spaces should be included between the words. After adding the value, restart the Exchange Server

Clients behind NAT Servers/ISA Servers

If the Outlook client is behind a NAT server or an ISA Server, it will not be able to receive new mail notification requests. The reason for this is that these new mail notification requests are not affiliated with the existing RPC connection to allow communications between the Outlook client and the Exchange Server. Because the new mail notification message is seen as an unsolicited inbound request, the NAT server and ISA Server will drop the packet.

This doesn’t mean that you won’t ever get any new mail. If you send mail to the Exchange Server, a new mail notification message can be sent through the existing (active) RPC channel between the Outlook client and the Exchange Server. However, RPC wasn’t designed for an unreliable network like the Internet. If there is an error in any of the RPC packets carrying the new mail notification, the notification message will not go through. You can get around this by forcing synchronization with the F9 key in Outlook 2000 or setup the Exchange account to carry out an automatic send/receive every few minutes in Outlook 2002.

The good news is that everything else works fine when the Outlook client is behind the NAT server. If you are using the Windows 2000 RRAS NAT, no further configuration is required for the NAT Routing Protocol. If you there is an ISA Server in front of the Outlook client, you will need to configure an RPC Protocol Definition and then configure the client to be a Firewall client. The reason the Outlook client must be configured as a Firewall client is that SecureNAT clients do not support secondary connections.

From what I can tell, you need to create the following Protocol Definition:

Primary connection: TCP 135 Outbound

Secondary connections: TCP 1025-65534 Outbound

My reasoning here is that the initial connection takes place on TCP 135. The remote ISA Server (the one publishing the Exchange Server) sends back to the local ISA Server (the one in front of the Outlook client) the port number on which the Outlook client needs to subsequent requests. Since this new outgoing connection is part of the original RPC conversation, a secondary connection to an ephemeral (high number) port is required outbound from the local ISA Server to the remote ISA Server.

The Exchange RPC Server Publishing Rule uses a Protocol Definition provided by the RPC Application filter. If you disable the Application Filter, you lose the Protocol Definition, so make sure the filter is enabled! Do the following to create the Server Publishing Rule:

1. In the ISA Management Console, expand your server or array name and then expand the Publishing node.
   
2. Right click on the Server Publishing Rules node, point to New and then click on Rule.
   
3. On the Welcome page, type in a name for the rule and click Next.
   
4. On the Address Mapping page, type in the IP address of the internal Exchange Server and the IP address on the external interface you want external network clients to use to access the Exchange Server. Click Next.
   
5. On the Protocol Settings page, select the Exchange RPC Server rule and click Next.
   
6. On the Client Type page, select Any Request and click Next. (It’s unlikely that you’ll be able to identify a client address set to assign the external Outlook clients).
   
7. On the final page of the Wizard, click Finish.

The rule should take effect soon after you click Finish. If you want the rule to apply right away, restart the Firewall service.

Configuring the Outlook client can be an interesting experience. I’ve only used Outlook 2000 to connect to Exchange Servers via RPC over the Internet. Similar procedures should apply to Outlook 2002, but I have not worked through the details of the Outlook 2002 (XP) client.

The user can use the same Outlook Profile configuration settings they use when connecting to the Exchange Server on the internal network, provided that you have configured your DNS infrastructure correctly or made the appropriate changes to the users’ HOSTS files.

An interesting finding is that if you want to receive new email from the Exchange Server, you must configure the Outlook client to use offline folders. To access this configuration setting, perform the following steps:

1. Right click the Outlook icon on the desktop and click Properties.
   
2. Click the Show Profiles button.

3. Select a Profile and click Properties.
   
4. In the Profile Properties dialog box, select Microsoft Exchange Server and click Properties.

5. In the Microsoft Exchange Server dialog box, place a checkmark in the Enable offline use checkbox. You should also enable encryption for on the network and dial-up networking to secure the data. Click Apply and click OK.

6. Click OK in the Profile Properties dialog box.
   
7. Now start up the Outlook client and log onto the Exchange Server. Right click on the Inbox folder and click on the Synchronization tab. Notice that the folder is available for online and offline use. You want this option to be available to all folders you want to synchronize with the F9 key.

I found it interesting that you needed to set up the Outlook client to use Offline folders in order to get the F9 key to work. If you use the F5 key, nothing will happen. If you use the F9 key, and you do not configure the Outlook client for offline use, you will see an error telling you that you haven’t configured the client for offline use. Once Outlook is configured for offline use, everything works great! But under no circumstances does the F5 key appear to do anything.

Exchange RPC publishing allows your Outlook client users to access the Exchange Server over the Internet in the same way it accesses the Exchange Server over the internal network. If you configure things correctly, the change between internal and external network access to the Exchange Server will be virtually transparent to your remote users. The only exception to this is new mail notification for clients behind a NAT Server or Firewall.

I hope you found this article helpful or at least interesting! I would like to thank Steve Riley from Microsoft Consulting Services for inspiring this article. Steve has a presentation on Exchange Server publishing that is very interesting and entertaining. If you get a chance to see him live, tell him I said “hi!” If you have any questions on what I covered in this article, send me a note at [email protected] and we’ll see what can be done to get you fixed up. Thanks! –Tom