Microsoft's Internet Security and Acceleration (ISA) Server 2006 is a firewall solution that augments Exchange 2003 and Exchange 2007. Because ISA Server is an Exchange-aware solution, it can be used as an application-level firewall. It is especially useful for mobile messaging security. This tip discusses deploying ISA Server to authenticate and encrypt ActiveSync synchronization between a mobile device and Exchange 2003 or Exchange 2007.
ISA Server is a software-based application that runs on top of the Windows Server operating system, which has inherent vulnerabilities. Although ISA Server offers the same functionality as most firewall appliances, it can be susceptible to attack if used alone. Therefore, when using ISA Server as a firewall for Exchange mobile messaging, I recommend placing ISA Server behind a firewall appliance, as shown in Figure 1.
Figure 1. ISA Server 2006 should be placed behind a firewall appliance.
In Exchange Server 2003 SP2 and Exchange 2007, ActiveSync maintains synchronization between mobile devices and Exchange mailboxes. When ActiveSync is used, mobile devices establish an HTTP or an HTTPS session with the Client Access Server (CAS). Assuming that HTTPS is being used, the session is established over port 443. The CAS uses a certificate to provide SSL encryption for a session that the mobile device has established.
When an ISA Server is added to the network, mobile devices can no longer communicate directly with the CAS. Instead, ISA Server receives a certificate and the mobile device establishes the HTTPS session with the ISA server, even though it appears to be connected directly to the CAS.
With this type of configuration, communications between the mobile device and ISA Server are SSL-encrypted. However, communications between the ISA server and the Client Access server must also be secured. Therefore, the ISA server uses a Remote Authentication Dial In User Service (RADIUS) server (or an IAS server) to authenticate mobile users.
Once users have been authenticated:
- The ISA server further checks the user's request to ensure that the packet is well-formed.
- The server establishes an HTTPS connection with the SSL-encrypted CAS.
- ISA Server acts as a proxy and forwards the user's request to the Client Access server.
- It relays the response back to the mobile user.
This isn't the only configuration architecture for deploying ISA Server, but I prefer this method for two reasons.
- ISA Server is can be a target for attacks. In this configuration, it isn't a domain member, and therefore, does not contain any domain information.
- The ISA server resides outside of an Active Directory forest, so domain administrators don't have management control over the server, unless you specifically grant them access.
Despite its benefits, this configuration can be tedious to implement and requires RADIUS or IAS servers. To simplify this, you can make ISA Server a member of a domain instead. This approach doesn't require a RADIUS server. As a domain member, ISA Server can still communicate with Active Directory and use an Active Directory database to authenticate mobile clients.
When ISA Server is a domain member, its location within the network plays an important role in its function. For example, if it is a domain member, but still resides at the network perimeter, you typically would have to create an IPSec tunnel that can be used to provide encrypted communications between the ISA server and the Client Access server.
However, if the ISA server is a domain member and exists within the private network, then it can communicate with the CAS just like other servers on your network. You don't have to create an IPSec tunnel -- although using IPSec encryption is still an option. I don't recommend placing a domain-member ISA Server at the network perimeter, because information about your domain potentially could be exposed.
About the author: Brien M. Posey, MCSE, is a four-time recipient of Microsoft's Most Valuable Professional Award for his work with Windows Server, Internet Information Server (IIS) and Exchange Server. Brien has served as CIO for a nationwide chain of hospitals and healthcare facilities, and was once a network administrator for Fort Knox. You can visit Brien's personal web site at www.brienposey.com.
Do you have comments on this tip? Let us know.
Please let others know how useful this tip was via the rating scale below. Do you know a helpful Exchange Server, Microsoft Outlook or SharePoint tip, timesaver or workaround? Email the editors to talk about writing for SearchExchange.com.
