The challenge for IT and security professionals is to enhance the competitive position of their companies by providing remote access to Exchange Server resources in a private, secure, and reliable fashion.
Corporate IT departments traditionally arranged for network level VPN access to the corporate network. The problem with network level VPNs (based on the PPTP or L2TP/IPSec VPN protocols) is that they provide a private connection, but they don’t necessarily ensure a secure connection. Network level VPN access uses the native Exchange Server Remote Procedure Call (RPC) protocols to enable access to the entire array of Exchanger Server information resources. Remote access network level VPN connections make VPN clients virtual nodes on the corporate network. These VPN clients can then access resources on any server on the corporate network, using any protocol, in the same fashion as hosts directly connected to the Ethernet network. Like most of the directly connected hosts, these VPN clients don’t aggressively filter those connections at the VPN gateway.
This can have potentially disastrous results. In contrast to devices that never leave the well-managed corporate network, VPN client computers, by definition, are devices used for remote access and have likely been connected to unmanaged or poorly managed networks. This exposes them to viruses, worms, and spyware. These infected devices can then spread the malicious payload to any other device on networks to which they connect, including the corporate network through a network level VPN link.
There are many approaches you can use to mitigate these risks. An increasingly popular remote access method is the Secure Sockets Layer (SSL) VPN. With its ability to provide remote access to users on a per application basis, the SSL VPN offers the privacy of the network level VPN and adds a level of security that is difficult to obtain with traditional network level VPNs.
Unlike network level VPNs, where the primary differences between them are the control channel and encryption methodologies, SSL VPNs represent a diverse collection of significantly different remote access methods sharing SSL (actually TLS) as their common encryption method. Variants of SSL VPNs include:
Reverse Web proxy for Web-enabled applications This type of SSL VPN takes advantage of server applications that have built-in support for Web access to server hosted data. Microsoft Office Outlook Web Access is the best example of this type of application. Microsoft Internet Security and Acceleration (ISA) Server 2004 provides the reverse Web proxy for the Outlook Web Access site. |
|
Reverse Web proxy with application gateways for non-Web–enabled applications For server applications that do not have native Web integration, some SSL VPNs include application gateways that translate data returned from the server application and reformat the server data dynamically so that it can be rendered in a Web browser. |
|
Application proxy for HTTP encapsulated client/server protocols Some SSL VPNs enable client applications on the SSL VPN client to encapsulate or “wrap” the native server application protocol in an encrypted HTTP header (SSL). The encapsulated communications are sent to an SSL VPN proxy that “unwraps” the HTTP header and exposes the native application protocol and forwards it to the server. Outlook 2003 RPC over HTTP is an example of this type of SSL VPN, and ISA Server 2004 can provide reverse proxy for the encapsulated connection. |
|
Network extension SSL VPNs that act like network level VPNs are referred to as network extension SSL VPNs. These SSL VPN implementations can make the SSL VPN client a virtual node on the corporate network and provide functionality for all protocols, including complex multi-connection application protocols. |
While there are significant differences in the technologies used to implement the SSL VPN connection, all SSL VPNs share the following advantages of traditional network level VPNs:
|
|
|
|
|
You don’t need to purchase dedicated SSL VPN gear if your company requires SSL VPN type access to Exchange Server resources. Microsoft has included SSL VPN functionality for remote access to Microsoft Exchange Server-hosted data through two core technologies:
|
|
ISA Server 2004 provides reverse Web proxy support and HTTP application layer inspection for both the integrated Exchange Server services communications and RPC over HTTP protocols.
Outlook Web Access SSL VPN Connectivity
With Outlook Web Access (OWA), users can access Exchange Server hosted information through any Web browser. The Exchange Server 2003 version of OWA provides a very rich user experience that closely mirrors the interface seen with Microsoft Office Outlook 2003. OWA in Exchange Server 2003 provides access to almost all features and data that would be accessible using the full Outlook 2003 client.
ISA Server 2004 can be combined with OWA to provide the enhanced security seen with full- featured SSL VPN solutions:
|
|
|
|
|
|
|
All these features make connections to the OWA Web site through an ISA Server 2004 firewall virtually indistinguishable from what would be attained with a dedicated SSL VPN device.
Outlook 2003 RPC over HTTP to Microsoft Exchange Server 2003
Outlook 2003 has the ability to encapsulate the native Exchange Server RPC protocols that the full Outlook MAPI client normally uses to communicate with the Exchange Server. The native RPC communications are encapsulated in an encrypted HTTP header (SSL) and then forwarded to an RPC over HTTP proxy on the corporate network. The RPC over HTTP proxy removes the HTTP header and forwards the native RPC protocol communications to the Exchange Server. After the Exchange Server sends responses to the RPC over HTTP proxy, the proxy re-encapsulates the RPC communications in an encrypted HTTP (SSL) header and returns the response to the Outlook 2003 client.
Although the RPC over HTTP solution does not meet the clientless aspect of SSL VPN connectivity, it does provide many of the other features seen with dedicated SSL VPN connections:
|
|
|
|
|
Like remote access to the OWA Web site, the combination of Outlook 2003, Exchange Server 2003, and ISA Server 2004 provides SSL VPN connectivity without requiring dedicated SSL VPN servers.
Conclusion
Traditional network level VPN connections can provide remote access clients a private but not necessarily secure connection to the corporate network. SSL VPN technologies are becoming increasingly popular because they provide private connections for remote access clients using SSL encrypted communications, and they enable access only to resources that are required for users to accomplish their work. Outlook Web Access and Outlook 2003 RPC over HTTP client connections to Microsoft Exchange Server 2003 provide many of the privacy and security features seen in dedicated SSL VPN device implementations