One of the strongest deployment scenarios for ISA Server 2004 is for protecting Microsoft Exchange Servers and services. ISA Server 2004 includes a number of technologies aimed at providing enhanced security for remote access connections to Exchange. These include:
- Forms-based authentication for Outlook Web Access (OWA)
- Pre-authentication at the ISA firewall for Outlook Web Access, RPC over HTTP, Exchange ActiveSync and Outlook Mobile Access using Windows authentication, RADIUS or SecurID
- An HTTP Security Filter that insures that only valid OWA, OMA, Exchange ActiveSync and RPC over HTTP connections are made through the ISA firewall
- The Secure Exchange RPC filter that allows the native Outlook MAPI client to connect to Microsoft Exchange Servers in a sure fashion by performing protocol validation on all RPC communications and preventing RPC exploits against the Exchange Server
- SSL to SSL bridging, which enables the ISA firewall to perform stateful application layer inspection on commands and data moving through the ISA firewall while preserving an end to end SSL encrypted connection
- Built-in wizards that greatly simplify configuring the firewall for secure remote access to Exchange Server, which reduces the risk of configuration errors that could put the Exchange Server at risk
ISA Server 2004 makes possible what we like to call the "Outlook Just Works" scenario, and enables this scenario in a secure context. The Outlook Just Works scenario allows any version of Microsoft Outlook (97/98/200/2002/2003) to connect to Exchange from anywhere in the world using its native RPC application protocols. When Outlook uses its native protocols, it can use the entire array of Exchange features and any Outlook or Exchange add-ins. Just about all employees who use the full Outlook client in the office would prefer to also use it while on the road and not have to switch to another e-mail client or have to use OWA, neither of which provides as robust an experience as the full Outlook client.
How Outlook Just Works works
Consider these ways users work in the "Outlook Just Works" scenario:
- An employee uses the full Outlook client while in the office. The user might have a desktop computer with Outlook loaded on it, or a laptop that moves between the office and locations outside the office. Many organizations are now standardizing on laptops and using docking stations for office use. Let's say the user has a notebook and uses the laptop to connect to Exchange. He starts up Outlook and connects to Exchange
- The user now takes the laptop to his home and plugs it into his home wireless network. He opens Outlook and it automatically connects to the office Exchange Server
- The user now has to go on a business trip and connects to a hotel broadband network. He opens his laptop computer, starts Outlook, and connects to the Exchange Server
The key to the Outlook Just Works scenario is that Outlook just works and the user doesn't need to be cognizant of his location. He doesn't have to reconfigure Outlook based on his location, he doesn't need to start a VPN connection to connect to the Exchange Server, and there's no need to use another e-mail client application or OWA just because he's not in the office.
This scenario can be played out using any version of Outlook. All versions of Outlook can use RPC to connect to the Exchange Server, and Outlook 2003 can use either native RPC or RPC over HTTP. ISA Server 2004 can enable secure remote access for all versions of Outlook via Secure Exchange RPC Publishing or Secure Web Publishing for RPC over HTTP. In this article, we'll focus on configuring secure Exchange RPC publishing.
The challenge of Secure Exchange RPC Remote Access
Secure Exchange RPC Publishing uses the ISA Server 2004 Secure Exchange RPC Filter. This filter provides an RPC proxy between the Outlook client and the Exchange Server. The RPC proxy is a critical component to a secure remote access solution using the native Outlook/Exchange RPC protocols because of the number of ports required and because the actual RPC communications need to be statefully inspected to make sure they pass protocol conformance testing.
To understand the challenge of enabling secure remote access for the native Outlook RPC protocols, you need to understand how the process works. In a nutshell, it works like this:
- When the Exchange Server starts, multiple RPC services each register a dynamic port on which they receive connections. Each of these services is associated with a Universally Unique Identifier (UUID).
- When the full Outlook MAPI client initiates a connection to the Exchange Server, the first connection is to the RPC endpoint mapper, which is on TCP port 135 on the Exchange Server.
- The Exchange Server sends back to the Outlook client the high-number ports on which the Exchange RPC services listen on.
- The Outlook client then connects to multiple RPC services on multiple ports on the Exchange Server, based on the ports associated with the services and UUIDs associated with the Exchange Server's RPC services.
The problem with enabling remote access for the full Outlook MAPI client through a conventional firewall is that when the Exchange RPC services start, they can associate themselves with any high port in the range of 1025-65535. This means you have to leave all ports within that range inbound through the conventional firewall to the Exchange Server. This is an unacceptable security configuration.
However, there is an option to reduce the number of required ports inbound by binding the Exchange RPC services to specific ports. Details on how to do this can be found at Microsoft's Knowledgebase. However, you still need to allow these ports to be statically opened, and the conventional firewall doesn't perform RPC protocol validation, so that the connections are not confirmed to be the specific Exchange services UUIDs and that the RPC communications are not confirmed to be valid Exchange RPC communications.
Securing Remote Exchange RPC Access with the ISA Server 2004 Secure Exchange RPC Filter and the HTTP Security Filter
The ISA Server 2004 Secure Exchange RPC solves these problems by opening RPC communications ports dynamically, so that no ports are left statically open. When the Outlook client ends its session with the Exchange Server, the RPC ports are closed on the ISA firewall. In addition, the ISA firewall performs deep application layer inspection on the RPC communications between the Outlook client and Exchange Server, to make sure the connections are to the correct UUIDs and that the commands and data are well-formed and not part of a potential exploit against the Exchange RPC services.
In addition, the ISA Server 2004 Secure Exchange RPC Filter can enforce encryption between the Outlook client and Exchange Server. This prevents information exchanged between the Outlook client and Exchange Server from moving "in the clear" and potentially being intercepted by an intruder who is listening on the wire or over a wireless link.
Advantages of the Outlook 2003 Client
Outlook 2003 clients can use both the native RPC protocols to connect to the Exchange Server, or RPC over HTTP. The Outlook 2003 client can take advantage of the Secure Exchange RPC filter to connect to the Exchange Server form remote locations. If the Outlook 2003 client is located behind a firewall that doesn't allow the RPC endpoint mapper and the required high ports outbound, it can wrap the native RPC protocols in an HTTP header and send the connection through the default SSL port number, TCP 443.
Using SSL to SSL Bridging and HTTP Security Filters
ISA Server 2004 can help secure the remote access connection from the RPC over HTTP client by using both its SSL to SSL bridging and HTTP Security Filter features. SSL to SSL bridging allows the ISA firewall to perform stateful application layer inspection on the contents of the SSL stream. The ISA firewall does this by terminating the SSL connection from the RPC over HTTP client on its external interface and then decrypting the SSL connection. The ISA firewall then establishes a second SSL link between its internal interface and the RPC over HTTP proxy on the corporate network. The ISA firewall acts as a "bridge" where the HTTP commands and data within the SSL stream are encrypted in the firewall's memory and exposes this information to the protocols scrubbing performed by the HTTP security filter.
The HTTP Security Filter can be configured to insure that the HTTP application layer "transport" protocol (not a true transport protocol, but a "transport" for the native application layer protocol, which is Outlook/Exchange RPC) conforms to what is considered legitimate and valid for RPC over HTTP connections to the RPC over HTTP proxy on the corporate network. This enables the ISA firewall to block commands and data that could be used to potentially exploit the RPC over HTTP proxy, which then might be used as a launch point for attacks against the rest of the corporate network.
Configuring ISA Server 2004 Secure Exchange RPC Publishing
Creating the Secure Exchange RPC Publishing Rule is easy. ISA Server 2004 includes a Mail Server Publishing Wizard that walks you through the process. One thing that you do need to take care of in advance is configuring a split DNS infrastructure if you want to support the entire range of native Outlook clients. The split DNS infrastructure will enable the Outlook client to resolve the name of the Exchange Server to the correct IP address regardless of location.
For example, if the NetBIOS name of the Exchange Server on the corporate networks is EXCHDALLAS, then the Outlook client on the internal network should be able to resolve this name to the Exchange Server's internal address. When the Outlook client is located on an external network, it should be able to resolve this name to the IP address used on the ISA firewall to accept the incoming connections from the Outlook clients. In addition, the client computer should be configured with a default domain name that it can use to append to the unqualified NetBIOS name.
Once you get your DNS house in place, you're ready to configure the Secure Exchange RPC Server Publishing Rule on the ISA Server 2004 firewall computer. Open the Microsoft Internet Security and Acceleration Server 2004 management console, expand the server name in the left pane of the console and click the Firewall Policy node. In the right pane of the console (referred to as the "Task pane"), click the Tasks tab and then click the Publish a Mail Server link.
On the Welcome to the New Mail Server Publishing Rule Wizard page, enter a name for the secure Exchange RPC Server Publishing Rule. In this example we'll call it Secure Remote Exchange RPC Access and click Next. On the Select Access Type page, shown in Figure A, select the Client access: RPC, IMAP, POP3, SMTP option and click Next.
|Select the type of access the mail server will provide for clients.|
On the Select Services page, shown in Figure B, select the Outlook (RPC) option under the Standard ports column. When you select this option, it automatically binds the Secure Exchange RPC Filter to the Server Publishing Rule. Click Next.
|Select the services you are publishing on the mail server.|
On the Select Server page, shown in Figure C, enter the IP address of the Exchange Server that you want to publish. If you have multiple Exchange Servers in your organization, then you'll need to create multiple Secure Exchange RPC Server Publishing Rules. Keep in mind that you'll need an IP address on the external interface of the ISA firewall for each RPC Server Publishing Rule you create. If the ISA firewall is a member of the Active Directory domain to which the Exchange Server belongs, you can use the Browse button to search the Active Directory for the name of the Exchange Server. Click Next.
|Specify the IP address for the server you're publishing.|
On the IP Addresses page, you select the ISA firewall Network on which the ISA firewall should listen for incoming connections. In most cases, the ISA firewall will listen for incoming connections from full Outlook clients on its External Network interface. Put a checkmark in the checkbox next to the External entry and then click the Address button.
This exposes the External Network Listener IP Selection dialog box, shown in Figure D. Since we only want the ISA firewall to listen on a single IP address per Secure Exchange RPC Server Publishing Rule, we want to select the Specified IP addresses on the ISA Server computer in the selected network option. Next, click on the IP address you want the ISA firewall to listen for incoming Exchange RPC connections to, from the Available IP Addresses list, then click Add. Click OK to bind this address to the RPC listener and then click Next on the IP Addresses page.
|Specify the IP addresses on which the listener should listen for requests.|
Click Finish on the Completing the New Mail Server Publishing Rule Wizard page. Right click the Secure Exchange RPC Publishing Rule you created and click Configure Exchange RPC. In the Configure Exchange RPC policy dialog box, shown in Figure E, put a checkmark in the Enforce Encryption dialog box. When this option is enabled, only Outlook clients configured to use a secure connection to the Exchange Server will be able to connect. Unsecured connections from Outlook clients are blocked and the connection will be allowed only after the Outlook client is configured to use encrypted connections to the Exchange Server
|Configure the policy to enforce encryption.|
Locking down Exchange and making Outlook work
Some of the security technologies included with ISA Server 2004 enable it to provide a secure remote access solution for the full Outlook MAPI client to Microsoft Exchange Servers and services. The unique combination of the Secure Exchange RPC filter, SSL to SSL bridging and the HTTP Security Filter enables the ISA firewall to provide secure remote access for all versions of the full Outlook client, including the Outlook 2003 RPC over HTTP special feature. Configuring a Secure Exchange RPC Server Publishing Rule allows all versions of Outlook to have full client access to Exchange Servers from any location, without requiring client reconfiguration or VPN connections.