Using the RPC Filter to Publish Microsoft Exchange

 

You can allow remote Outlook 2000/2002/2003 clients to connect to your Exchange Server and take advantage of the full functionality provided by the full Outlook MAPI client. Unlike Outlook Web Access, full Outlook MAPI client functionality allows remote users to take advantage of the entire set of mail and groupware features provided by Exchange Server.

 

You can use secure Exchange RPC publishing to grant remote users access the full range of Exchange Services. Some of the reasons why you should consider secure Exchange RPC publishing include:

 

·         Publishing Exchange RPC services is secure because of the application layer intelligence provided by the Exchange RPC filter

 

There is a general impression that RPC connections are not secure. This is not true when you use the Exchange RPC filter to publish Exchange Servers. The RPC filter handles the connection between the remote Outlook client and the internal Exchange Server and creates dynamic packet filters that can only be used by specific Outlook clients. In addition, the secure Exchange RPC filter allows only valid Exchange Server related RPC connections; all other connections are dropped by the filter. This is a unique feature found only in ISA Server firewalls.

 

 

·         Data can be encrypted between the Internet client and the Exchange Server and you can force encryption of Outlook client connections using ISA Server 2000 Feature Pack 1

 

You can configure the Outlook client to encrypt data over the connection using 56-bit MD5 encryption. ISA Server 2000 Feature Pack 1 allows you to configure the Registry on the ISA Server firewall to force remote Outlook MAPI clients to use a secure connection. Non-secured connection attempts will be dropped.

 

·         Exchange RPC Server Publishing is relatively simple

 

Exchange RPC publishing is easy! A single Server Publishing Rule allows your remote Outlook MAPI clients access the internal Exchange Server. You do not need to create Destination Sets or special Protocol Definitions. The built-in Exchange RPC Protocol Definition works together with the RPC filter to provided a protected, secure publishing rule.

 

·         Access is limited to mail services only -- not access to the entire network

 

Users traditionally created a VPN connection to the corporate network before they could access the Exchange Server to obtain full Outlook MAPI client access. The drawback of allowing VPN connections to allow Outlook MAPI client access is that VPN clients have access to the entire network. You only want users to access resources on the Exchange Server using the Outlook MAPI client. Allowing access to the entire network leaves you overexposed. Secure RPC Publishing allows the Outlook MAPI client full access to the Exchange services remote users require without giving them access to any other resource on the network.

 

·         Users can continue using their familiar Outlook 2000/2002/2003 client

 

Users often balk when they have to use different email client applications to access Exchange resources when they move between the corporate network and a remote site. Users prefer to use the same mail client regardless of their location when you have standardized on Outlook 2000/2002/2003. Exchange RPC publishing gives them the ability to use the same familiar interface they use at work while at home or on the road.

 

 

How Exchange RPC Publishing Works

 

The typical remote Outlook MAPI client establishes a connection to the Internet via a local ISP. In this scenario the remote computer is assigned a public IP address (the same scenario would apply if the remote Outlook MAPI client were connected to a hotel broadband network that wasn’t “firewalled”). Another scenario has the remote Outlook MAPI client connecting to the corporate Exchange Server from behind a NAT router or firewall.  The remote Outlook MAPI connection can work in both scenarios.

 

The following communications take place when Outlook is opened:

 

  1. Outlook establishes a connection to TCP port 135 on the external interface of the ISA Server. Included in this connection request are the Exchange Server specific UUIDs.
  2. The ISA Server’s Exchange RPC filter intercepts the request and forwards it to the internal network Exchange Server.
  3. 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. 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.
  4. 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.
  5. 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.

 

 

Note:
For a deeper technical explanation of how the Exchange RPC filter works, please refer to TechNet articles Microsoft ISA Server 2000 - Configuring and Securing Microsoft Exchange 2000 Server and Clients and Protecting Windows RPC Traffic

 

 

 

Preparing the Network Infrastructure for Exchange RPC Publishing

 

There are a few network infrastructure elements that must be put in place before you can realize a successful Exchange RPC Publishing scenario. These network elements include:

 

·         Create a supporting DNS infrastructure so that the Outlook MAPI client can correctly resolve the name of the Exchange Server regardless of location

·         Creating DNS and SMTP Protocol Rules to support outbound DNS and SMTP traffic from the Exchange Server on the internal network

·         Configure the authentication referral method on the Exchange Server

·         Address requirements for Outlook MAPI clients located behind NAT routers and firewalls

 

Create the Supporting DNS Infrastructure

 

The DNS infrastructure must be designed in a way that allows the Outlook MAPI client to correctly resolve the name of the Exchange Server regardless of its location. The user should never need to reconfigure his client settings to support his location. Outlook should “just work” where ever the client system may be located.

 

The ideal DNS configuration is the “split DNS”. The split DNS infrastructure requires that you maintain two separate zones for the same domain. One of these zones supports internal network clients the other zone supports external network clients. These two zones service the same domain or domains.  The difference is that the resource record on the internal DNS zone has the private IP address of the Exchange Server and the external DNS zone has the public IP address that remote users access to connect to your published Exchange Server.

 

For example, if the server name is exchange.domain.com on the internal network, you need to assure that exchange.domain.com is accessible to external and internal network hosts. You can accomplish this with a split DNS configuration by creating a Host (A) record on your external DNS server for exchange.domain.com to point to the address on the external interface of the ISA Server that you’re using in the Exchange RPC publishing rule.

 

If your organization does not use the same domain name for resources that are accessible both internally and externally, then you can still access the Exchange Server via the RPC publishing rule by using local host name resolution. In this case, you will need to create a HOSTS file entry with the NetBIOS name of the Exchange Server computer (sometimes referred to as the “computer name”). You do not need to include the FQDN of the Exchange Server in the HOSTS file; just the NetBIOS name is required.

 

Note:
The host name portion (the leftmost label) of the FQDN must be the same as the computer name of the Exchange Server being published by the Exchange RPC Server Publishing Rule. The Outlook MAPI client must be configured to use the computer name of the Exchange Server and be able to fully qualify the name correctly. In addition, the Outlook client computer must use a primary domain name, or an adapter specific domain name that will allow the client to correctly fully qualify the NetBIOS name for the Exchange Server. Outlook 2000 clients will need to be able to resolve the name of its Global Catalog server to the same IP address that is used to publish the Exchange RPC server

 

Create DNS and SMTP Protocol Rules

 

The Exchange Server needs to forward mail it receives from the Outlook MAPI clients to SMTP servers on the Internet. A Protocol Rule that allows outbound access to the following protocols may be required:

 

 

The DNS Query and Zone Transfer Protocol Rules allow the Exchange IIS SMTP service to resolve the MX domain name records. You can configure the Protocol Rule to allow only the Exchange Server access to it, or you can configure the Protocol Rule to allow all machines on the network to use it. Access control on the DNS Zone Transfer Protocol Rule depends on what machine is responsible for 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.

 

 

 

Configuring the Authentication method

 

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. The problem here is that the Active Directory is not directly accessible to remote hosts. You can avoid this problem by configuring the Exchange Server to proxy authenticate the Outlook MAPI client.

 

Navigate to the following registry key to configure the Exchange Server to proxy authenticate requests for the Outlook MAPI client:

 

HKLM\System\CurrentControlSet\Services\MSExchangeSA\Parameters

 

Add the following:

 

Value: No RFR Service

Type: REG_DWORD

Data: 1

 

Note the value (No RFR Service) does have spaces in it. Restart the Exchange Server After adding the value.

 

 

 

Outlook MAPI Clients behind NAT Routers/Firewalls/ISA Servers

 

If the Outlook client is behind a NAT router or NAT-based conventional firewall, it will not be able to receive new mail notification requests. The reason for this is that these new mail notification requests are not associated with the existing RPC session that allows communications between the Outlook MAPI client and the Exchange Server. Because these new mail notification messages are seen as an unsolicited inbound requests, the NAT router/firewall and ISA Server drop the packet.

 

However, if the Outlook MAPI client is behind a sophisticated layer 7 aware firewall like ISA Server 2000, then the Outlook MAPI will be able to receive immediate notification when new messages arrive. Outlook MAPI clients located behind an ISA Server 2000 firewall that has ISA Server 2000 Feature Pack 1 installed have no problems receiving new mail notification messages.

 

The Outlook MAPI client is able to leverage a new and improved RPC Protocol Definition that ties into the new RPC application filter and it is able to intelligently manage the connection for the Outlook MAPI client. This intelligent connection management allows new mail notifications to flow from the Exchange Server to the remote Outlook MAPI client located behind an ISA Server 2000 firewall.

 

This doesn’t mean that you won’t ever get any new mail if the Outlook MAPI client is located behind a NAT router or NAT-based conventional firewall. If you send mail to the Exchange Server, a new mail notification message can be sent through the active RPC channel. However, if there is an error in any of the RPC packets carrying the new mail notification, the notification message will not reach the Outlook MAPI client located behind a NAT router or conventional firewall. You can get around this by clicking on any file or folder or pressing the Send/Receive button in Outlook 2000 or configure the Outlook 2002 client to carry out an automatic send/receive every few minutes in the background.

 

The good news is that everything else (outside of new mail notification messages) works fine when the Outlook client is behind the NAT router or conventional firewall. If you are using the Windows 20002003 RRAS NAT service, no further configuration is required for the NAT Routing Protocol. If there is a NAT router in front of the Outlook MAPI client, then an RPC NAT editor is required. Most NAT routers have a RPC NAT editor installed.

 

If a conventional firewall is in front of the Outlook MAPI client, the firewall administrator will need to configure the conventional firewall to allow a primary connection on TCP 135, and then secondary connections inbound and outbound to and from all ephemeral ports. These secondary connections are part of the same “connection bundle” and are part of the application layer session established by the primary connection.

 

You can create a simple Protocol Rule that allows the Outlook MAPI client outbound access through the ISA Server 2000 firewall. Perform the following steps to create the Protocol Rule:

 

  1. Open the ISA Management console, expand the Servers and Arrays node and expand your server name (figure 1). Expand the Access Policy node and right click on the Protocols node. Point to New and click on Rule.

 

Figure 1

 


  1. Type in a name for the Protocol Rule in the Protocol rule name text box on the Welcome to the New Protocol Wizard page (figure 2). Click Next.

 

Figure 2

 


  1. Select the Allow option on the Rule Action page (figure 3). Click Next.

 

Figure 3

 


  1. On the Protocols page (figure 4), select the Selected protocols option in the Apply this rule to drop down list. Select the RPC protocol from the list of Protocols. Click Next.

 

Figure 4

 


  1. Select a schedule from the Use this schedule drop down list. In this example we’ll use the Always schedule (figure 5). Click Next.

 

Figure 5

 


  1. On the Client Type page (figure 6), select the Any request option and click Next.

 

Figure 6

 


  1. Review your settings on the Completing the New Protocol Rule Wizard page and click Finish (figure 7).

 

Figure 7

 

The new Protocol Rule will appear in the right pane of the console.

 

 

 

Creating the Exchange RPC Server Publishing Rule

 

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.  You can check the status of the RPC Filter in the Application Filters node just under the Extensions node in the left pane of the ISA Management console.

 

Perform the following steps to create a secure Outlook MAPI client access Server Publishing Rule:

 

  1. In the ISA Management Console, expand your server or array name and then expand the Publishing node. Right click on the Server Publishing Rule node, point to New and click Rule (figure 8).

 

Figure 8

 


  1. On the Address Mapping page (figure 9), type in the IP address of the Exchange Server on the internal network. Click the Browse button and select the IP address on the external interface of the ISA Server 2000 firewall that you want to use to accept the incoming requests from the remote Outlook MAPI clients.

 

Figure 9

 


  1. Click Next after entering the IP addressing information on the Address Mapping page (figure 10). Click Next.

 

Figure 10

 


  1. On the Protocol Settings page, select the Exchange RPC Server rule and click Next (figure 11).

 

Figure 11

 


  1. On the Client Type page (figure 12), 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).

 

Figure 12

 


  1. On the final page of the Wizard, click Finish (figure 13).

 

Figure 13

 

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