Become a Columnist Microsoft Exchange Site Microsoft Support SiteMSDN Exchange Site

   

Subscribe to OutlookExchange
Anderson Patricio
Ann Mc Donough
Bob Spurzem
Brian Veal
Catherine Creary
Cherry Beado
Colin Janssen
Collins Timothy Mutesaria
Drew Nicholson
Fred Volking
Glen Scales
Goran Husman
Guy Thomas
Henrik Walther
Jason Sherry
Jayme Bowers
John Young
Joyce Tang
Justin Braun
Konstantin Zheludev
Kristina Waters
Kuang Zhang
Mahmoud Magdy
Martin Tuip
Michael Dong
Michele Deo
Mitch Tulloch
Nicolas Blank
Pavel Nagaev
Ragnar Harper
Ricardo Silva
Richard Wakeman
Russ Iuliano
Santhosh Hanumanthappa
Steve Bryant
Steve Craig
Todd Walker
Tracey J. Rosenblath
 
  Securing MAPI Access with ISA Server

Securing MAPI Access with ISA Server

This article applies to : Exchange 2000, ISA Server, Outlook 2002

Originally Published : 1st December 2001

Last Updated : 29th November 2002


Many people are aware of the ability to allow Outlook clients access to the Exchange Server via MAPI through a firewall. This method is covered in more detail in the Microsoft Article -  http://support.microsoft.com/support/kb/articles/q270/8/36.asp for Exchange Server 2000, however they pose one important problem. To utilise this functionality however, you need to also allow port 135 (one of the main RPC ports) access through the firewall. Full details of achieving this in Exchange Server 5.5 can be found in my article  http://www.outlookexchange.com/articles/colinjanssen/article_Firewall_Access_Outlook32bit.asp . The methods described here are the same for Exchange Server 2000.

Allowing access using these means opens your systems up to all sorts of security risks, especially since RPC is used to access most administration tools, including Active Directory. This is the main reasons why most people ignore this method of allowing MAPI access via the internet, and opt for more expensive options such as VPN's. If your brave, and don't believe in hackers, then by all means go ahead using this method. This aside, I know personally of an international company that has been using this method on all their Exchange Server Sites for a couple of years with no problems as yet.

VPN's pose their own issues, including cost and complexity for the client and company.  Anyone who's ever tried to set up VPN access on anything other than NT or W2K not using a third party product will know what I mean. And let's face it, in most instances, users really only require remote access to their email. Implementing all this new infrastructure and spending all this money seems an overkill just for purely email access. Don't get me wrong. The only other option is to grant users dial-in access. Aside from the speed issues, with large amounts of users, this is a more expensive option to implement and maintain.

ISA can solve this problem though, and still allow MAPI access via the internet  without using a VPN. Included with ISA is an Exchange RPC filter rule. This is a special packet filter that protects your servers from external attacks by first inspecting the packets and then proxying them onto the correct Exchange server. Basically, this is how it works :-

When a MAPI client tries to make a connection to an Exchange server (behind an ISA server using the Exchange RPC filter rule), it's first point of contact is the ISA server. The RPC packet it sends contains a MAPI data portion. ISA then inspects the packet to ensure it is a valid RPC packet. If the RPC packet is destined for the Exchange server, and contains the proper MAPI portion in the packet, otherwise called an Exchange MAPI RPC packet, it is then sent to the Exchange server by the ISA server on behalf of the client. Or in other words, a proxied request. Any other RPC packets are blocked.

To configure the rule, follow the below instructions

  1. In the ISA Management Console, expand your server or array name and then expand the Publishing node.
  2. Right click on the Server Publishing Rules node, point to New and then click on Rule.
  3. On the Welcome page, type in a name for the rule and click Next.
  4. On the Address Mapping page, type in the IP address of the internal Exchange Server and the IP address on the external interface you want external network clients to use to access the Exchange Server. Click Next.
  5. On the Protocol Settings page, select the Exchange RPC Server rule and click Next.
  6. On the Client Type page, select Any Request and click Next.
  7. On the final page of the Wizard, click Finish.

Note : The Protocol Definition is lost if you disable the Application Filter so if you wish to the Exchange RPC Publishing Rule you must make sure it's enabled.

But this method won't work without some extra configuration on the client end. Outlook 2000 / 2002 clients will, after initially contacting the Exchange Server 2000, attempt to access Active Directory for authentication. With Pre Outlook 2000 clients, Exchange Server 2000 proxies these requests on behalf of the client. To stop this from happening, a change in the registry on the Exchange Server is needed to make Exchange proxy these requests for Outlook 2000 / 2002 clients. This change is shown below :-

HKLM\System\CurrentControlSet\Services\MSExchangeSA\Parameters

Value Name : No RFR Service

Value Type : DWORD

Value Data : 0x1

For added security, the Outlook client can be configured to encrypt mail when using the network. You can find this (in Outlook 2002), in the Exchange email account properties. For other Outlook clients, this can be found in the Advanced Options in the Exchange Service properties. To do this in Outlook 2002 follow these instructions :-

  1. In Outlook 2002, click Tools, and then E-mail accounts.
  2. Click Next.
  3. Ensure the Exchange server is selected, and click Change.
  4. Click More Settings.
  5. Click the Advanced tab.
  6. Check When using the Network.
  7. Click OK.
  8. Click Next.
  9. Click Finish.


Back to Home

 

 


Disclaimer: Your use of the information contained in these pages is at your sole risk. All information on these pages is provided "as is", without any warranty, whether express or implied, of its accuracy, completeness, fitness for a particular purpose, title or non-infringement, and none of the third-party products or information mentioned in the work are authored, recommended, supported or guaranteed by Stephen Bryant or Pro Exchange. OutlookExchange.Com, Stephen Bryant and Pro Exchange shall not be liable for any damages you may sustain by using this information, whether direct, indirect, special, incidental or consequential, even if it has been advised of the possibility of such damages.

Copyright Stephen Bryant 2008