Use ISA Server to Secure Exchange

In the old days, configuring remote access to email systems was simple: You couldn't. (UNIX-based systems gave command-line clients Telnet access, and Microsoft Mail—MS Mail—had a dial-in feature that worked slightly more often than not, but other than that, you were out of luck.) We've come a long way since then; you might even say that by comparison, Exchange 2000 Server offers an embarrassment of riches. Exchange 2000's Outlook Web Access (OWA) and IMAP and POP virtual servers give Internet-protocol access to clients using Web browsers or popular email programs such as Outlook, Outlook Express, Eudora, and Pegasus. What none of these Exchange 2000 services can do, alas, is replicate the full Outlook experience. For example, remote users can't easily synchronize with a handheld or use Outlook's Journal, Tasks, or Notes features.

These shortcomings exist because Outlook is a Messaging API (MAPI)-based client and expects to be able to pass remote procedure call (RPC) traffic directly to the Exchange Server system. Exposing your Windows computers to RPC traffic directly from the Internet, however, is a Really Bad Idea, so administrators who want to offer Outlook to remote users either need to depend on direct dial-up connections or a VPN. VPNs work well but require a certain degree of care and feeding, particularly when you're deploying a VPN solution for many users or using hardware VPN devices that require special client software.

Another solution exists, though, to the dilemma of how best to provide access to remote users: Deploy Microsoft Internet Security and Acceleration (ISA) Server 2000. ISA Server functions both as a firewall for inbound and outbound traffic and as a Web-caching device; its primary value for Exchange lies in its ability to secure traffic at the application level. Ordinary firewalls secure traffic at the network layer: They block or accept specified types of packets from and to selected network addresses but can't look inside those packets. ISA Server, however, is designed expressly to analyze the contents of HTTP, SMTP, and RPC packets to make sure that the packets contain legal requests. And Microsoft and third parties are working to add filtering capability for additional protocols.

To better secure your Exchange 2000 or Exchange Server 5.5 systems, you can use ISA's application-inspection capability in two key ways. The first way is to publish the Exchange RPC ports so that Outlook clients can access them directly. The clients communicate with the ISA server, which forwards all legal RPC packets to the Exchange server. (This process is similar to the function of an Exchange front-end server, except that front-end servers can't proxy MAPI traffic.) If you take this approach, Outlook clients who connect directly to your ISA Server get much the same experience as operating on the LAN—-they have full connectivity and access to all Outlook features. Every road warrior I know who has tried this feature has come away wanting it badly.

The second way to leverage ISA Server is to use it to publish OWA. In this mode, you can use ISA Server to proxy OWA traffic with additional Secure Sockets Layer (SSL) protection, which lets the ISA Server decrypt and inspect incoming traffic before reencrypting and retransmitting it. This option provides a welcome degree of additional security.

You can also use ISA Server to perform more exotic tricks. With the right third-party plugins, the server product can filter and archive Exchange Instant Messaging (IM) traffic, scan inbound SMTP mail for viruses, and filter, quarantine, or block specified content. In the future, I expect Microsoft to enhance ISA Server so that it works with the next version of Exchange (code-named Titanium) to provide MAPI-over-HTTP mode and to support Outlook 11's roaming-user enhancements. In the meantime, you can go to http://www.microsoft.com/isaserver to download an evaluation version and a ton of application notes about the process of setting up ISA Server to work with Exchange.