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:
- 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 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 connection between the Outlook MAPI client and the Exchange Server can be encrypted and non-encrypted connections can be prevented by the ISA firewall
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 Server Publishing is simple
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.
- Access is limited to mail services only -- not access to the entire network
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 can continue using their familiar Outlook 2000/2002/2003 client
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!
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:
- 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).
- 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.
- 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.
- 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.
- 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.
For a deeper technical explanation of how the Exchange RPC filter works, Protecting Windows RPC Traffic at http://www.microsoft.com/technet/prodtechnol/isa/2000/maintain/rpcwisa.mspx
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
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.
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 must 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.
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.
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.
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
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.
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:
- 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.
- 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.
- In the Rule Action page, select the Allow option and click Next.
- On the Protocols page, select the Selected protocols option in the This rule applies to drop-down list. Click the Add button.
- In the Add Protocols dialog box, click the All Protocols folder. Double click on the RPC (all interfaces) protocol. Click Close.
- Click Next on the Protocols page.
- On the Access Rule Sources page, click the Add button.
- In the Add Network Entities dialog box, click the Networks folder and then double click Internal. Click Close.
- Click Next on the Access Rule Sources page.
- On the Access Rule Destinations page, click Add.
- In the Add Network Entities dialog box, click the Networks folder and then double click the External entry. Click Close.
- Click Next on the Access Rule Destinations page.
- On the Users Sets page, accept the default entry, All Users, and click Next.
- Click Finish on the Completing the New Access Rule Wizard page.
- The new rule appears on the Firewall Policy tab in the Details Pane.
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 ensure that the filter is enabled. You can check the status of the RPC Filter in the Add-ins node under the Configuration node in the left pane of the Microsoft Internet Security and Acceleration Server 2004 management console.
Remember to create a Secure Exchange RPC Server Publishing Rule for each Exchange Server hosting mailboxes. For example, if you have four Exchange Servers hosting user mailboxes, you will need to publish each of these Exchange Servers. Note that if you have a front-end Exchange Server, you do not need to publish the front-end Exchange Server, since it doesn’t proxy native RPC protocols. In contrast, a front-end Exchange Server can proxy HTTP tunneled RPC connections (RPC over HTTP).
Perform the following steps to create a secure Outlook MAPI client access Server Publishing Rule:
- In the Microsoft Internet Security and Acceleration Server 2004 management console, expand the server name in the left pane of the console and then click the Tasks tab on the Task Pane. Click the Create a New Server Publishing Rule link.
- On the Welcome to the New Server Publishing Rule Wizard page, enter a name for the rule in the Server publishing rule name text box. In this example, enter Publish Secure Exchange RPC. Click Next.
- On the Select Server page, enter the IP address of the Exchange Server in the Server IP address text box. Click Next.
- On the Select Protocol page, click the down-arrow in the Selected protocol list. Select the Exchange RPC Server entry. Note that in order to filter the incoming SMTP messages for spam and keywords, you must use the SMTP Message Screener. Click Next.
- On the IP Addresses page, select the External entry and click Address. We need to select a specific External address because the perimeter network adapter is also considered an external adapter at this time.
- In the External Network Listener IP Selection dialog box, select the Specified IP addresses on the ISA Server computer in the select network option. In the Available IP Addresses list, click the IP address on the External interface of the ISA Server 2004 firewall computer. In this example, click 192.168.1.70. Click Add. The address now appears in the Selected IP Addresses list. Click OK.
- Click Next on the IP Addresses page.
- Click Finish on the Completing the New Server Publishing Rule Wizard page.
The new Server Publishing Rule appears in the Firewall Policy list in the Details Pane.
You can test the secure Exchange RPC Server Publishing Rule using any version of the Microsoft Outlook MAPI client. In this example, we will test the rule using the Outlook 2003 client. Outlook 2000 and Outlook 2002 MAPI clients are configured in a similar fashion.
In the following walkthrough, we will use a HOSTS file to map the IP address of the Exchange Server to the external address on the ISA Server 2004 firewall machine.
In a production environment, you would use a split DNS infrastructure to support name resolution for the Outlook MAPI client. A split DNS infrastructure is the preferred method of name resolution for organizations that support machines that move between the internal and external networks, and is required to support a secure Exchange RPC Server publishing solution.
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):
- Right click Start and click Explore.
- 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:
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.
- Close Notepad and save the changes.
- Open a command prompt and enter ipconfig /displaydns and press ENTER. You should see the name mapping you entered into the HOSTS file appear immediately.
Configuring the Outlook 2003 Client
The next step is to configure the Outlook profile that connects to the Exchange Server. Perform the following steps to configure the Outlook profile:
- Click Start and then right click on the E-mail Microsoft Office Outlook icon. Click Properties.
- In the Mail dialog box, click the Add button.
- In the New Profile dialog box, enter Administrator in the Profile Name text box. Click OK.
- On the E-mail Accounts page, select the Add a new e-mail account option and click Next.
- On the Exchange Server Settings page, enter the NetBIOS name of the Exchange Server in the Microsoft Exchange Server text box. Put a checkmark in the Use Cached Exchange Mode checkbox. Enter Administrator in the User Name text box. Click Check Name.
- Notice that the name of the Microsoft Exchange Server changes to the fully qualified domain name of the Exchange Server. Click the More Settings button.
- In the Microsoft Exchange Server dialog box, click the Security tab. On the Security tab, put a checkmark in the Encrypt data between Microsoft Office Outlook and Microsoft Exchange Server checkbox. Click Apply and then click OK.
- Click Next on the Exchange Server Settings page.
- Click Finish on the Congratulations! page.
- Click OK in the Mail dialog box.
Now we’re ready to make the connection to the Microsoft Exchange Server via the secure Exchange RPC Server Publishing Rule. Perform the following steps to make the connection:
- Click Start and click E-mail Microsoft Office Outlook.
- In the Choose Profile dialog box, confirm that Administrator appears in the Profile Name box and click OK.
- Enter msfirewall\Administrator in the User name text box on the Connect to dialog box. Enter the Administrator’s password in the Password text box. Click OK.
- The Administrator’s mailbox is opened in Outlook.
There’s no reason why your users ever need to be without their full Outlook MAPI client. When you bring an ISA firewall into your organization and configure Secure Exchange RPC Server Publishing Rules and pair this with an industry standard split DNS infrastructure, your users will realize all the productivity benefits that flow from the "Outlook Just Works" scenario. We use it everyday and so do our customers. Give it a try and you’ll be a believer too!
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