Best practices for securing Exchange ActiveSync
Sure, ActiveSync is easy to set up and administer, but how comfortable are you with its security? These best practices will go a long way toward protecting your CAS.
It is relatively easy to set up ActiveSync in both Exchange Server 2007 and Exchange 2010, but you should follow some best practices to ensure that ActiveSync is used in a secure manner.
These four tips will help you protect your client access server.
1. Use a dedicated CAS
ActiveSync is available through the client access server (CAS) role. Although it’s possible to install the CAS role on the same Exchange server as the mailbox, hub transport, or unified messaging role, it’s better from a security standpoint to run the CAS on a dedicated server.
One way to secure the CAS is by reducing the server’s attack surface. An Exchange server that hosts a single role has a smaller attack surface than a server running multiple roles. Furthermore, when you use a dedicated CAS, you limit the amount of damage an attacker can do in the event that the server is compromised. For example, if someone hacks a CAS, he won’t automatically gain access to the mailbox database if the mailbox server role is running on a different server.
2. Use a reverse proxy
You can also improve ActiveSync security using a reverse proxy. The basic idea behind a reverse proxy -- such as Microsoft ForeFront -- is to hide Internet-accessible servers from the Internet. In an Exchange Server environment, the reverse-proxy server sits behind your perimeter firewall but in front of your CAS.
In this configuration, ActiveSync clients do not directly connect to your CAS as they normally would. Instead, they establish a session with the reverse-proxy server. Mobile devices send ActiveSync requests to the reverse proxy server and the reverse proxy server forwards those requests to the CAS. Mobile clients are completely unaware of the reverse proxy server’s existence.
With this setup, clients cannot send HTTP or HTTPS packets directly to the CAS. The reverse proxy server intercepts all inbound traffic, inspects the packets and then communicates with the CAS on behalf of the mobile users.
3. Only use fully provisionable devices
Both Exchange Server 2007 and Exchange 2010 include an ActiveSync Mailbox Policy setting that lets you allow or restrict non-provisionable devices (Figure 1).
Figure 1. Exchange gives you the option to restrict the use of non-provisionable devices.
Microsoft defines a provisionable device as a device that fully supports all the security settings that can be included in an ActiveSync mailbox policy. Thus, a non-provisionable device might be unable to handle some or even all of your ActiveSync mailbox policy settings.
This brings up another point. ActiveSync mailbox policies are the centerpiece of ActiveSync security and you should use them to enforce password policies for your mobile devices. You should also use ActiveSync mailbox policies to control the types of items that are synchronized to your users’ mobile devices. Additionally, you can use them to disable individual device features like cameras or infrared ports based on your corporate security policy. There is a good TechNet article that details all the individual policy settings.
Exchange also lets you create multiple ActiveSync mailbox policies. So, you can create policies for individual users to meet their needs without being overly permissive.
4. Use SSL encryption
Another important practice is to require SSL encryption for all ActiveSync communications. Exchange automatically provisions client access servers with a self-signed certificate, but you must use a permanent SSL (X.509) certificate with ActiveSync.
Microsoft gives you the option to either use a commercial certificate or to generate your own certificate in house. This can be done using a Windows server that’s configured to act as an enterprise certificate authority (CA). You can save a few bucks by generating your own certificate, but it’s better to use a commercial SSL certificate.
Most mobile devices are configured to automatically trust certificates that have been issued by well-known commercial CAs. The same cannot be said for certificates that are generated in house. If you are going to use a home-grown certificate, then you must provision each mobile device with a CA certificate that lets the device trust your CA, as well as the certificates it generates.
ABOUT THE AUTHOR:
Brien Posey is an eight-time Microsoft MVP with two decades of IT experience. Before becoming a freelance technical writer, Brien worked as a CIO for a national chain of hospitals and healthcare facilities. He has also served as a network administrator for some of the nation’s largest insurance companies and for the Department of Defense at Fort Knox.
