Enabling Full Outlook Client Access Anywhere using the ISA Firewall’s Secure Exchange RPC Filter

Enabling Full Outlook Client Access Anywhere
using the ISA Firewall’s Secure Exchange RPC Filter

by Thomas W Shinder MD, MVP

Got Questions? Go to:
http://forums.isaserver.org/ultimatebb.cgi?ubb=get_topic;f=23;t=000368 and ask!

You can allow remote Outlook 2000/2002/2003 clients to connect to your Exchange Server over the Internet 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. And unlike Outlook RPC over HTTP, you don’t need to use Exchange 2003 and you don’t need to use Outlook 2003.

All this can be accomplished using the ISA firewall’s Secure Exchange RPC publishing feature. You can use secure Exchange RPC publishing to grant remote users access to the full range of Exchange Services without settling for second best. Let’s fact it, when it comes to access to Exchange data, anything but the full Outlook MAPI client experience is second rate.

Some of the reasons you should consider secure Exchange RPC publishing include:

There is a general impression that RPC connections are not secure and for good reason. The Blaster worm whacked a lot of us a couple of years ago and it was associated with an RPC issue. The good news is that when you use the ISA firewall’s Exchange RPC filter to publish Exchange Servers, risks related to RPC exposure to the Internet are mitigated.

The RPC filter handles the connection between the remote Outlook MAPI client and the internal Exchange Server and creates dynamic packet filters that can only be used by specific Outlook clients. In addition to the secure Exchange RPC filter’s dynamic packet filter and connection management intelligence, 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.

The Outlook client can be configured to encrypt the data channel between itself and the Exchange Server. However, this is a client side configuration and depends on the user configuring the Outlook client. The ISA firewall’s Secure Exchange RPC filter allows you to force remote Outlook MAPI clients to use a secure connection. Non-secured connection attempts from Outlook MAPI client will be dropped by the ISA firewall’s Secure Exchange RPC filter.

Exchange RPC publishing is simple. A single Server Publishing Rule allows your remote Outlook MAPI clients to 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 provide a protected, secure publishing rule.

In order to provide users access to the full range of Exchange Server services to the full Outlook MAPI client, firewall administrators traditionally allowed VPN connections to the corporate network. The drawback allowing VPN connections (through non-ISA firewalls, VPN connections through ISA firewalls are subjected to stateful application layer inspection) is that in order to allow Outlook MAPI client access is that VPN clients have access to the entire network.

The fact is that you want users to access resources on the Exchange Server using the Outlook MAPI client and nothing else. You don’t want to open up the entire network just to allow the full Outlook MAPI client access to the full range of Exchange Server services. The ISA firewall’s Secure RPC Publishing feature allows the Outlook MAPI client full access to the all Exchange Server services remote users require without giving them access to any other resource on the network.

Users often complain when they must use different e-mail client applications to access Exchange resources as they move between the corporate network and a remote site. Users prefer to use the same mail client regardless of their locations 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 when connecting from home or on the road.

“Outlook Just Works”

I love the “Outlook Just Works” scenario because I use it all the time. I travel a lot and need to make sure I have all the time, anywhere access to the Exchange Server in my home office. We’re a small company, but that doesn’t mean we can’t take advantage of the same technologies that the big boys use! The “Outlook Just Works” allows me to use the full Outlook client from anywhere and I never have to think about my location.

Here’s the “Outlook Just Works” scenario:

• I use the full Outlook MAPI client at the office on my office workstation. I open Outlook and it just works.
• I also use the full Outlook MAPI client on my laptop computer. My laptop computer connects to the Exchange Server via a wireless connection. We have segregated the wireless LAN from out production LAN by creating a wireless DMZ segment on the ISA firewall. I open Outlook and it just works.
• Now I have to go on a business trip to Boston. I get to the airport and I need to check my mail, because I forgot my itinerary (which is in an e-mail message on my Exchange Server). I open the laptop while at the airport and connect to the airport’s wireless network. I open Outlook and it just works.
• The plane lands in Boston and I get to the hotel room. The hotel has a DSL connection for each room. Plug the laptop into the hotel’s broadband network, open it up and then open Outlook. It just works.
• We’re having a meeting at the client’s location and they have a wireless LAN. I connect to their WLAN and open Outlook. Outlook just works!

The key to the “Outlook Just Works” scenario is that all I had to do was open Outlook and it worked. I didn’t have to think about where I was and make any changes to Outlook. No client side reconfiguration, no fiddling with settings, no need to use OWA or anything else. Its great!

How Secure Exchange RPC Publishing Works

The typical remote Outlook MAPI client establishes a connection to the Internet via a local ISP or broadband Internet connection with a public address. In both these scenarios, the remote computer is assigned a public IP address. The remote Outlook MAPI connection works in both scenarios.

The following communications take place when Outlook is opened:

1. Outlook establishes a connection to TCP port 135 (the RPC endpoint mapper) on the external interface of the ISA firewall. Included in this connection request are the Exchange Server specific Universal Unique Identifiers (UUIDs).
2. The ISA firewall’s Exchange RPC filter intercepts the request and forwards it to the internal network Exchange Server. However, before the request is forwarded to the Exchange Server, the Secure Exchange RPC filter performs stateful RPC protocol inspection on the RPC communications. Only valid RPC communications are passed through to the 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 Secure Exchange RPC filter on the ISA firewall intercepts this response and opens a dynamic packet filter on its external interface that the Outlook MAPI client can use to connect to the Exchange Server. The dynamic packet filter assigns a port on the external interface of the ISA firewall on which only this particular Outlook client communicates. No other Internet host can use that port for inbound access The ISA firewall maps this port on its external interface to the port number the Exchange Server expects to receive messages from the Internet-based Outlook client. In addition, when the Outlook client logs on, it registers a port on which it can receive new mail notification messages from the Exchange Server. The ISA firewall 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 firewall 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 MAPI client establishes a connection to the mapped port on the external interface of the ISA firewall and through that port connects to the internal network Exchange Server.

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

Preparing the Network Infrastructure for Exchange RPC Publishing

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

• A supporting DNS infrastructure that enables the Outlook MAPI client to correctly resolve the name of the Exchange Server regardless of location
• DNS and SMTP Protocol Rules supporting outbound DNS and SMTP traffic from the Exchange Server on the internal network
• Exchange Server configuration that sets the authentication referral method on the Exchange Server
• NAT router and firewall configuration to support outbound secure Exchange RPC connections

Create the Supporting DNS Infrastructure

The DNS infrastructure must be designed in a way that enables 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 MAPI client settings to support the current location. Outlook should “just work” regardless of the client system’s current location. Transparency of name resolution is the key to making the “Outlook Just Works” scenario a reality for your organization.

The ideal DNS configuration for supporting hosts that move between the corporate network and remote locations is the split DNS. The split DNS infrastructure requires you to maintain two separate DNS zones that are authoritative for the same domain.

One of these zones supports internal network clients and the other zone supports external network clients. These two DNS zones service the same domain or domains. The difference is that resource records on the internal DNS zone have the private IP addresses of the Exchange Server(s) and the external DNS zone has the public IP addresses that remote users access to connect to your published Exchange Server(s).

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

The split DNS needs to include the names of all your Exchange Servers. In fact, any server containing information that requires remote access to information should be included in the DNS. For example, if your organization includes two Exchange Servers, exchange.domain.com and exchange2.domain.com, you should include both of these in the split DNS and map them to the IP addresses you use on the ISA firewall to publish them via Secure Exchange RPC publishing. You need to create a Server Publishing Rule for each machine hosting user mailboxes.

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, which bypasses the need for a DNS server.

The problem with the HOSTS file solution is that its not very scaleable and would apply only for an SBS type of environment, or one where your users are technically savvy. 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; only the NetBIOS name is required.

As the note above implies, things do get a bit tricky on the name resolution front depending on the version of Outlook you’re using. It appears that Outlook 2003 is more “Internet aware” and respects the use of FQDNs, but older version of Outlook require that the host machine be able to correctly qualify unqualified names. If it seems like I’m being a bit fuzzy on this, I am. Check out the client configuration information in the ISA Server 2000 Exchange Deployment Kit at http://isaserver.org/news/exchangekit.html  for details on client configuration.

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. An Access Rule allowing outbound access to the following protocols may be required:

A DNS Access Rules allows the Exchange SMTP service to resolve MX domain names. You can configure the Access Rule to allow only the Exchange Server access to it, or you can configure the Access Rule to allow all machines on the network to use it.

Access control on the DNS Access Rule depends on which machine is responsible for resolving the MX domain names. You might want to forward the DNS queries from the Exchange Server to an internal DNS server and let the DNS server on your internal network take care of name resolution.

The SMTP Access Rule is required for the Exchange Server to send out mail to external mail domains. Access controls on the SMTP Protocol Rule depend on which 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 an outbound SMTP relay, 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 are well, since it will need to resolve Internet MX mail domains. The exception to this requirement is if the SMTP relay (or the Exchange Server) is configured to use an internal DNS server, then allow only the internal DNS server to resolve Internet host names.

Configuring the Authentication method

When the Outlook client logs onto the Exchange Server, the Exchange Server instructs the Outlook MAPI client to authenticate to an Active Directory domain controller. However, 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:

Add the following:
Value: No RFR Service
Type: REG_DWORD
Data: 1

Note that the value (No RFR Service) does have spaces in it. Restart the Exchange Server After adding the value. Restart the Exchange Server after making this change.

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 or it might not be able to connect to the Exchange Server at all. Some ISPs, in their infinite wisdom, have decided that since the Blaster outbreak, there is no reason to allow outbound TCP 135 through their networks. This blocks the Outlook MAPI client’s connection to the RPC endpoint mapper. In my opinion, its a bad decision on this ISP’s part since if they want to block ports to prevent exploits, they need to block TCP ports 25 and 80.

New mail notification requests are not associated with the existing RPC session between the Outlook MAPI client and the Exchange Server. Because new mail notification messages are seen by the firewall as unsolicited inbound requests, the NAT router/firewall drops the packet.

If the Outlook MAPI client is behind a sophisticated layer 7-aware firewall such as an ISA firewall, then the Outlook MAPI client will be able to receive immediate notification when new messages arrive. Outlook MAPI clients located behind an ISA firewall have no problems receiving new mail notification messages.

For outbound connections through and ISA firewall, the Outlook MAPI client can leverage a new and improved RPC Protocol Definition that ties into the ISA RPC application filter. This filter intelligently manages the connections between the Outlook MAPI client and the Exchange Server. Intelligent connection management allows new mail notifications to flow from the Exchange Server to the remote Outlook MAPI client located behind an ISA 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 will 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 work around this by clicking on any file or folder or pressing the Send/Receive button in Outlook 2000 or you can configure the Outlook 2002/2003 client to carry out an automatic send/receive every few minutes in the background.

In practice, I’ve encountered very few problems while on the road. Last year I had a heck of a time finding hotels and conference centers who appreciated the fact that “port blocking” wasn’t exactly the most intelligent solution to network security. However, in the last few months, I’ve found that even when I’m assign a private address, the broadband service providers are allowing the new mail notifications to come through fine. Maybe they’re using ISA firewalls? Or maybe they’re using a non-ISA firewall/NAT device with increased RPC proxy intelligence. That fact is, our “Outlook Just Works” scenario is working again at just about the pre-Blaster levels.

The good news is that everything else (other than new mail notification messages) works fine when Outlook clients are behind a NAT router or conventional firewall. If you are using the Windows 2000 or Windows Server 2003 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, an RPC NAT editor is required. Most NAT routers have an RPC NAT editor installed.

If a conventional packet filtering firewall is in front of the Outlook MAPI client, the firewall administrator needs 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.

If you’re using an ISA firewall, you can create a simple Access Rule allowing the Outlook MAPI client outbound access through the firewall.

Perform the following steps to create the Access Rule:

1. Open the Microsoft Internet Security and Acceleration Server 2004 management console and expand the server name. Click the Firewall Policies node. Click the Tasks tab on the Task Pane and then click the Create New Access Rule link.
2. On the Welcome to the New Access Rule Wizard page, enter a name for the rule in the Access Rule name text box. In this example, enter Outbound Exchange RPC. Click Next.
3. In the Rule Action page, select the Allow option and click Next.
4. On the Protocols page, select the Selected protocols option in the This rule applies to drop-down list. Click the Add button.
5. In the Add Protocols dialog box, click the All Protocols folder. Double click on the RPC (all interfaces) protocol. Click Close.

Perform the following steps to create the HOSTS file entry on the EXTCLIENT machine (which is the name of the Outlook 2003 MAPI client in this example):

1. Right click Start and click Explore.
2. Navigate to \systemroot\system32\drivers\etc and open the HOSTS file using Notepad.

   In Notepad, add the following line to the list of mapped addresses:

   192.168.1.70 exchange2003be.msfirewall.org

   This entry maps the name of Exchange Server computer used in this example to the IP address on the external interface of the ISA Server 2004 firewall used by the secure Exchange RPC Server Publishing Rule to accept incoming connections. Make sure to press ENTER after adding the line so that the insertion point is on the next line. Otherwise, the name mapping will not saved.

Conclusion

I hope you enjoyed this article and found something in it that you can apply to your own network. If you have any questions on anything I discussed in this article, head on over to http://forums.isaserver.org/ultimatebb.cgi?ubb=get_topic;f=23;t=000368 and post a message. I’ll be informed of your post and will answer your questions ASAP. Thanks! –Tom

If you would like us to email you when Tom Shinder releases another article on ISAserver.org, subscribe to our ‘Real-Time Article Update’ by clicking here. Please note that we do NOT sell or rent the email addresses belonging to our subscribers; we respect your privacy