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


Introduction. 1

How Exchange RPC Publishing Works. 2

Creating a Supporting DNS Infrastructure. 4

Step 1: Install Windows Server 2003 on the Main Office and Branch Office Machines. 7

Step 2: Install ISA Server 2000 on the Main Office and Branch Office Machines. 9

Step 3: Install the Microsoft DNS Server on the Branch Office ISA Server 2000 Firewall and Configure the Public DNS Record  10

Step 4: Create the Secure RPC Server Publishing Rule on the Main Office ISA Server 2000 Firewall 15

Step 5: Configure the Registry on the Main Office ISA Server 2000 to Force Encrypted RPC Sessions  17

Step 6: Configure an RPC Protocol Rule at the Branch Office to Enable Outbound RPC Sessions for SecureNAT and Firewall Clients. 18

Step 7: Configure the Outlook 2003 Profile to Connect to the Exchange Server 19

Step 8: Make the Connection. 22

Conclusion. 24

 

Introduction

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.

How Exchange RPC Publishing Works

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

Creating a 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 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

Step 1: Install Windows Server 2003 on the Main Office and Branch Office Machines

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, Enterprise, and Datacenter editions. Note that you cannot use the Web edition for ISA Server 2000.

Windows Server 2003 System Requirements

Requirement

Standard

Enterprise

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
2003

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

Enterprise CA

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.

Step 2: Install ISA Server 2000 on the Main Office and Branch Office Machines

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).

Step 3: Install the Microsoft DNS Server on the Branch Office ISA Server 2000 Firewall and Configure the Public DNS Record

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.