![]()

Secure Exchange Connectivity from the Branch Office to the Main Office
Chapter 11
Connecting to the Main Office Exchange Server from the Branch Office using
Secure Exchange RPC Publishing
Contents
How
Exchange RPC Publishing Works
Creating
a Supporting DNS Infrastructure
Step
1: Install Windows Server 2003 on the Main Office and Branch Office Machines
Step
2: Install ISA Server 2000 on the Main Office and Branch Office Machines
Step
4: Create the Secure RPC Server Publishing Rule on the Main Office ISA Server
2000 Firewall
Step
5: Configure the Registry on the Main Office ISA Server 2000 to Force Encrypted
RPC Sessions
Step
7: Configure the Outlook 2003 Profile to Connect to the Exchange Server
Branch office Outlook clients can connect to the main office 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 branch office users to take advantage of the entire set of mail and groupware features provided by Exchange Server.
Secure Exchange RPC publishing enables remote users access
the full range of Exchange Services. Some important reasons for considering secure
Exchange RPC publishing include:
· Publishing Exchange RPC services is secure because of the application layer intelligence provided by the Exchange RPC filter
· Data can be encrypted between the branch office client and the Exchange Server. You can force encryption of Outlook client connections by installing ISA Server 2000 Feature Pack 1 on the main office ISA Server 2000 firewall
· Exchange RPC Server Publishing is relatively simple
· Access is limited to mail services only -- not access to the entire network
· Users can continue using their familiar Outlook MAPI client
Traditionally, RPC connections over the Internet have not been considered secure. The RPC filter handles the
connection between the branch office Outlook client and the main office
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 RPC connections are dropped by the filter. The RPC
filter is a unique feature that until recently was
found in ISA Server 2000 firewalls.
You can configure the Outlook client to encrypt data 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 are
dropped by the ISA Server 2000 firewall.
Exchange RPC publishing is relatively simple. A single
Server Publishing Rule enables 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.
In the past branch office users needs 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. Access to the entire network is should not be required in order to
allow users to access resources on the Exchange Server using the Outlook MAPI
client. Enabling users access to the entire network
represents a potential security risk that should be avoided. 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 often
resist using different email client applications to access Exchange resources when they move between the corporate
network and a remote site. Users prefer the same mail client regardless of
their location when you have standardized on Outlook. 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 branch office Outlook MAPI client connects to the
corporate Exchange Server from behind a NAT router or firewall, such as ISA
Server 2000. The branch office 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 main office 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
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 the Outlook client settings based on his location. Outlook should “just work” whereever the client system is located.
The ideal DNS configuration is the split DNS infrastructure. The split DNS infrastructure requires that you maintain two separate DNS zones for the same domain. One of these zones supports internal or main office network clients and the other zone supports external or branch office network clients. These two zones service the same domain or domains. The difference is that resource records on the internal DNS zone contain the private IP address of the Exchange Server and the external DNS zone has the public IP address remote users use to connect to your published Exchange Server.
The figure below shows the different paths Outlook clients take to access an Exchange Server via Exchange RPC.
1. The
branch office Outlook client is configured to connect
to an Exchange Server named exchange2003.
The client fully qualifies the name to exchange2003.msfirewall.org
and sends the request to a public DNS server. The public DNS server returns to
the branch office Outlook client the IP address on the external interface of
the ISA Server 2000 firewall that is used by the
secure RPC Server Publishing Rule at the main office network.
2. The
branch office Outlook client sends the RPC connection request to the external
address of the ISA Server 2000 firewall at the main office. The secure RPC
Server Publishing Rule forwards the request to the Exchange Server on the main
office network.
3. The
Outlook client located at the main office is configured
to connect to the same Exchange server. The main office Outlook client fully
qualifies the name and sends a DNS query to the main office DNS server for exchange2003.msfirewall.org. The main
office DNS server returns to the Outlook client the internal network IP address
of the Exchange Server.
4. The
main office Outlook client connects directly to the Exchange Server on the main
office network. The client does not loop back through the ISA Server 2000
firewall. The split DNS infrastructure prevents overloading the firewall with
internal network client requests for internal network resources.

You can access the Exchange Server via a secure Exchange
RPC publishing rule by using local host name resolution if your organization
does not use the same domain name for resources that are accessible both
internally and externally. In this case, you 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; only the NetBIOS name is required. The primary
drawback of this approach is that you need to change the IP address in the
HOSTS file depending on whether the Outlook client is located on the main
office or branch office network.
The host name portion (the leftmost name or “label”) of the FQDN must be the same as the computer name of the Exchange Server published via the secure Exchange RPC Server Publishing Rule. In addition, 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 order for the Outlook client computer to correctly fully qualify the single label, NetBIOS name of the Exchange Server, the client operating system must use a primary domain name or an adapter specific domain name. In addition, Outlook 2000 clients will need to be able to resolve the name of its Global Catalog server to the same IP address used to publish the Exchange RPC server. The Global Catalog Server’s name will also need to placed in the public DNS in the same domain as the Exchange Server’s name.
The figure below shows the name resolution process for two Outlook clients:
1. A branch office Outlook client is configured with a primary domain name of msfirewall.org. When this Outlook client connects to the Exchange Server on the main office network, it fully qualifies the NetBIOS name of the Exchange Server with its primary domain name. A query for NetBIOS_name.msfirewall.org is sent to a public DNS server. The public DNS server returns the IP address on the external interface of the ISA Server 2000 firewall that is publishing secure Exchange RPC.
2. The branch office Outlook client sends an Exchange RPC request to the ISA Server 2000 firewall at the main office. The secure Exchange RPC Server Publishing Rule forward the request to the Exchange Server on the main office network.
3. A second Outlook client is not configured with a primary domain name that it can use to append to unqualified names, such as the Exchange Server’s NetBIOS name. This Outlook client cannot issue a DNS query, so it sends a NetBIOS name query broadcast to the local branch office network segment. The Outlook client is unable to resolve the name to an IP address and the connection attempt fails.

Secure Exchange RPC publishing is a viable alternative for clients that are not able to connect to the main office via a site to site VPN link. The branch office Outlook clients derive the same high level of functionality as those who connect directly to the Exchange Server over a site to site VPN connection.
The following procedures are required to create the secure Exchange RPC connection:
· Step 1: Install Windows Server 2003 on the main office and branch office machines
· Step 2: Install ISA Server 2000 on the main office and branch office machines
· Step 3: Install the Microsoft DNS server on the branch office machine and configure the Exchange Public DNS Records
· Step 4: Create the RPC Server Publishing Rule on the main office ISA Server 2000 firewall
· Step 5: Configure the Registry on the Main Office ISA Server 2000 to force encrypted RPC sessions
· Step 6: Configure an RPC Protocol Rule at the branch office to enable outbound RPC sessions for SecureNAT and Firewall clients
· Step 7: Configure the Outlook 2003 profile to connect to the Exchange Server
· Step 8: Make the Connection
The first step is to install Windows Server 2003 on the
machines that will act as the main office and branch office ISA Server 2000
firewalls. The machines should meet the hardware requirements for both Windows
Server 2003 and ISA Server 2000. The table below shows the hardware
requirements for the Standard,
|
Windows Server 2003 System Requirements |
|||
|
Requirement |
Standard |
|
Datacenter |
|
Recommended CPU |
550 MHz |
733 MHz |
733 MHz |
|
Recommend Minimum RAM |
256 MB |
256 MB |
1 GB |
|
Multiprocessor Support |
Up to 4 |
Up to 8 |
Max 64 |
|
Disk Space for Setup |
1.5 GB |
1.5 GB |
1.5 GB |
The lab scenario used in this document is described in the table and figure below.
|
Lab Network Details |
|||||
|
Setting |
EXCHANGE |
LOCALHOST |
LOCALVPNISA |
REMOTEVPN |
REMOTEHOST |
|
IP Address |
10.0.1.2 |
10.0.1.3 |
Int: 10.0.1.1 Ext: 192.168.1.70 |
Int: 10.0.2.1 Ext: 192.168.1.71 |
10.0.2.2 |
|
Default Gateway |
10.0.1.1 |
10.0.1.1 |
192.168.1.60 |
192.168.1.60 |
10.0.2.1 |
|
DNS |
10.0.1.2 |
10.0.1.2 |
10.0.1.2 |
10.0.2.1 |
10.0.2.1 |
|
WINS |
10.0.1.2 |
10.0.1.2 |
10.0.1.2 |
|
|
|
Services |
DC DNS WINS DHCP |
None |
ISA Server 2000 |
ISA Server 2000 DNS |
|

Note that multiple network services are installed on the domain controller on the main office network. These services are typical services that would be maintained on a main office network. The DNS service is required by Active Directory.
The LOCALHOST and REMOTEHOST computers are configured as SecureNAT clients. Although you do not need to use the SecureNAT configuration to access the Internet (you can make the machines Firewall and/or Web Proxy clients), we will make the branch office client a SecureNAT client to demonstrate the functionality of the RPC Protocol Rule that enables the SecureNAT client full MAPI access to the Exchange Server on the main office network.
In the current example, the REMOTEHOST is the Outlook 2003 client. The LOCALHOST computer will not be used.
The next step is to install the ISA Server 2000 firewall and Web caching software onto the main office and branch office firewall machines. For detailed information on how to install ISA Server 2000 on Windows Server 2003 computers, please see the document Installing ISA Server 2000 on Windows Server 2003 in the ISA Server 2000 Exchange 2000/2003 Deployment Kit (document #32).
In the current example, we will install and configure a DNS server on the branch office ISA Server 2000 firewall computer and use it to simulate a public DNS server. In a production network, you would configure a public DNS server to host the public component of your split DNS infrastructure.
Perform the following steps on the branch office ISA Server 2000 computer to install the Microsoft DNS Server service:
1. Click Start and point to Control Panel. Click on Add or Remove Programs.
2. In the Add or Remove Programs window, click on the Add/Remove Windows Components button on the left side of the window.
3. On the Windows Components Wizard page, click on the Networking Services entry in the Components list and then click the Details button.
4. In the Networking Services dialog box, put a checkmark in the Domain Name System (DNS) checkbox and click OK.