This tip is part of the Messaging Security School lesson on securing Microsoft Exchange. Visit the Securing Microsoft Exchange lesson page for more learning resources.
How does one securely connect Microsoft Outlook from outside the company's firewall-protected environment? Outlook over a VPN is a tried, tested and secure approach, if it is done right. RPC over HTTPS is a secure alternative if your users only require access to Exchange.
Let's quickly review the possible methods to connect Outlook to Exchange over the Internet.
- Outlook Web Access with SSL (OWA over HTTPS)
- Mobile devices
- Full Outlook using MAPI/RPC (Not!)
- Outlook using POP3 or IMAP4
Outlook Web Access: The Web version of Outlook (OWA) improves with each version of Exchange and is the primary remote method of most users. It can easily be secured with by enabling 'Require SSL' and 'Require 128-bit encryption' to the /exchange virtual directory in IIS.
One OWA security concern is that while messages are encrypted on disk, perhaps at a kiosk at the airport, the attachment that is downloaded to the hard drive is not. It is possible to turn off this capability in Exchange 2003 and 2000. If you need a way of allowing such documents, Messageware Inc. translates documents to HTTP back on the Exchange Server and they show up in the secured OWA window. The upcoming Exchange 2007 release will handle this situation correctly. It will also allow secure access to internal documents and SharePoint sites, under administrative control of course.
Mobile devices: Handhelds running the Windows Mobile operating system are becoming more popular. Exchange includes the capability for synchronizing these devices with Exchange Server. The method is extremely similar to OWA and you implement SSL on the Server-ActiveSync virtual server within IIS. In addition, there must be a copy of the server's SSL certificate on the device. Previous versions could bypass this, but no longer.
Full Outlook: Some users need the full Outlook client so that they can have a synchronized copy of their mailboxes. Typically these user groups include management, sales and marketing teams on the road, and other mobile information workers.
While it is possible to allow Outlook to connect over the Internet using its native MAPI/RPC protocol, there is no way that we would open the ports on our firewall to make that happen. Security breach… malware target… career-limiting move. Enough said.
POP3/IMAP4: Using Outlook to connect to Exchange using POP3 or IMAP4 is possible; they can each be SSL encrypted, and SMTP could be as well (POP3 and IMAP4 use SMTP as their sending protocol). You might use these protocols at home for connecting to an ISP for personal email, but most corporate Exchange shops keep these listed under Services Disabled on the Exchange Server and do not open these ports on their firewalls.
We think of VPNs as secure, though they require an administrator who understands how to manage them. By that I mean you need to be specific in which users or groups get access to which resources. It's way too easy to install a VPN box that gives all users access to the full network. My biggest concern with VPN's though is the user who connects his or her home computer to the corporate network. Yes, the computer that little Johnny and Sally have been playing on all day. There are plenty of great SearchSecurity.com articles on VPNs. Outlook does very well in this environment, and Outlook 2003's cache feature allows the movement of mail to be truly a background process.
If some of your traveling users only need access to Exchange and don't need access to your internal network, there is an alternative. RPC over HTTPS takes the Outlook packets (MAPI/RPC) and tunnels them over secure HTTPS. Back inside your environment, an RPC proxy service decrypts the packets and connects to Exchange Server. Again, add cache mode move synchronization to the background, and you've limited VPN access to those that actually require it.
Note that RPC over HTTPS will get a new name with the 2007 wave of products: Outlook Anywhere. While the old name has always been hard to say, it clearly said what it did.
About the author:
Lee Benjamin has more than 20 years experience in the messaging industry and is one of a select group of Microsoft MVPs for Exchange. At ExchangeGuy Consulting, he specializes in migration and upgrade advice, technical writing and evaluation, product strategy and training and courseware development. He has delivered international training tours for Microsoft, and is a regular trainer for Pinnacle Training. Lee is also Chairman of ExchangeServerBoston and Director for BostonUsersGroups, an umbrella organization of over 50 user groups in New England. He is also an analyst with Ferris Research.
SECURITY SCHOOL MENU
Messaging Security School: Home
Securing Microsoft Exchange: Lesson Home
Securing Microsoft Exchange: Webcast
Securing Microsoft Exchange: Podcast
