As Microsoft licenses the Exchange Server ActiveSync protocol to a wider range of device manufacturers and software companies including Apple, Nokia, Google, IBM, Dataviz among others, users can enjoy push-based mailbox synchronisation from a wider range of devices - which is good for the user, but potentially a nightmare for the network administrator who needs to ensure that all of these devices conform to corporate security and usage policies.
In this article I shall look at the different ways the administrator can control which devices can access Exchange mailbox data.
This article was written with considerable reference to similar articles featured on the MobilityDojo web site - http://mobilitydojo.net/2009/09/28/restricting-exchange-activesync-access/ and http://mobilitydojo.net/2009/10/27/restricting-exchange-activesync-acces...
My intent is largely to do it for myself, but also to hopefully convey the ideas discussed in more accessible terms.
There are a number of reasons why administrators may wish to restrict the type of client device employed by users to access the myriad of features offered by Exchange 2010:
- Email and PIM data
- Free / Busy lookup
- Unified Messaging access
- Remote file share / Sharepoint access
- SMS message synchronisation
Not least because some devices may not support corporate security policies including on-device encryption and strong password usage, or offer the ability to have elements of their hardware disabled remotely such as Bluetooth, or some devices may simply claim to support the Exchange ActiveSync protocol but may not yet have been fully tested to the administrator's satisfaction.
There are a number of ways of restricting access to an Internet-facing Exchange "Client Access Server" (CAS). These range from simply making it difficult unless you have the required information (SSL certificates, IP address) to using Exchange's own EAS policy capabilities, to barring all devices until specifically approved by the administrator.
Using Self-Signed SSL Certificates
SSL Certificates 'guarantee' the identity of a server by assigning a certificate to a server that comprises a digital hash value calculated by running the server's name through a complex algorithm. When requesting content from a server, the server presents its certificate, containing the hash value. Should the requesting machine perform a calculation on that hash value and come up with anything other than the expected server name, the connection is flagged as insecure. That is a massive simplification, but you get the idea. In order to be able to perform the calculation, the requesting server needs to be able to access the algorithm. If the server was assigned a root-trusted certificate, (by providers such as VeriSign, or Thawte), that algorithm is preinstalled on the device already. When using a self-signed certificate, your CA is not automatically trusted by the client device, so your root CA certificate (that contains the algorithm) needs to be installed onto devices manually before any certificates issued by that CA can be trusted. In a nutshell, in order to be able to trust a certificate, the root certificate of the CA that issued that certificate needs to be installed on the device.
Using self-issued certificates is normally a cost-saving measure: root-trusted certificates cost money and need to be regularly updated. But they can also offer a line of security purely based on the fact that some devices will not connect to servers that they do not trust - meaning that the administrator can control which devices have access by only installing the appropriate cert onto those devices they want to connect.
This only applies to certain devices, including Windows Mobile and Nokia Mail for Exchange clients: Android devices will warn the user about the nature of the certificate, but also offer an option to 'Continue Anyway'.
I have blogged previously about how to use a self-signed SSL certificate with Microsoft Exchange 2003 SP2 - http://blog.brightpointuk.co.uk/configuring-exchange-2003-activesync-usi...
Some customers have had trouble identifying, having run through this procedure, the appropriate root SSL certificate to export and install onto client devices. Microsoft have released a tool to help you correctly isolate and export the certificate to use - http://blog.brightpointuk.co.uk/microsoft-sslchainsaver
Using self-signed SSL certificates does mean that even approved devices may not be able to connect until the appropriate certificate is installed onto them - which may at the least require that the certificate be made available for download, or worse connected to a PC and the certificate copied to it via the appropriate desktop sync software - not ideal.
Using Exchange 2010's ActiveSync Device Policies
The device configuration policies in Exchange 2010 are unchanged from Exchange 2007: administrators can define, on a per-user or per-group basis, how client devices can be used, including:
- Enforce password usage and strength
- Password entry attempts
- Synchronisation size limits
- Disable removable storage
- Disable camera
- Disable WiFi
- Disable Infrared
- Disable remote desktop from device
- Disable desktop synchronisation
- Disable Bluetooth
- Disable Browser
- Disable POP/IMAP email
- Disable application installation
- Whitelist and blacklist applications
(Click on images to view a larger version)
The extent to which client devices can have these policies applied to them varies and depends on the device or software manufacturer, but these built-in policies can be used to ensure that devices are used only in a manner that corresponds to corporate usage policies.
Using Exchange 2010 Powershell CommandLets
Exchange 2010 includes a collection of new CommandLets that can be run by the administrator at the PowerShell command line to define access control policies to the Exchange ActiveSync service, granting "Allow", "Block" and "Quarantine" access.
Should the administrator wish to quarantine all devices, preventing access to the Exchange ActiveSync service before explicitly approved by the administrator, this can be achieved by issuing the following command:
Set-ActiveSyncOrganizationSettings –DefaultAccessLevel Quarantine
This will cause any connection requests to be initially denied, and an emailing flagging the connection request to be sent to 'firstname.lastname@example.org'. An example mail would look like this:
The user would see the following error message on their device:
The administrator, making note of the DeviceID in the email, can enable the device for access for the specific user with the following command:
Set-CASMailbox –Identity email@example.com –ActiveSyncAllowedDeviceIDs
The user will then be informed that access has been granted:
Block and Allow
Quarantining all users and requiring that they be approved manually may constitute an unacceptable administrative overhead, and may not be required if certain device types are to be allowed access as a matter of course.
Access Policies can be defined based on specific client device properties, including:
- Device Model
- Device Type
- Device OS
- Device User Agent
Enabling the administrator to block, allow or quarantine at varying levels down to specific device models, types or operating systems.
Should you wish to allow all PocketPC devices, for example, you might issue a command of:
New-ActiveSyncDeviceAccessRule –QueryString PocketPC –Characteristic
DeviceType –AccessLevel Quarantine
And to block all Nokia E71 devices, you might issues a command of:
New-ActiveSyncDeviceAccessRule –QueryString NokiaE71 –Characteristic
DeviceModel –AccessLevel Block
Multiple rules can be defined, and rules operate on 'most-permissive' basis, so if you were to quarantine all devices, but explicitly allow Pocket PC devices, those devices would be allowed.
This does require that you know the correct details to enter. One way to do this is to allow a device to synchronise and then view its entry in Outlook Web Access:
Because Exchange ActiveSync uses the HTTP protocol to access Exchange, all access requests can be audited within the Exchange server's IIS web logs:
2009-11-14 19:34:04 192.168.0.100 OPTIONS /Microsoft-Server-ActiveSync/default.eas
443 domain\administrator 192.168.0.2 MSFT-PPC/5.2.1403 403 0 0 27633
In the above example access request:
- Device IS - BC2DD3AE37CE0CB225D6D0BDBFECCC69
- Device Model
- Device Type - PocketPC
- Device OS
- Device User Agent - MSFT-PPC/5.2.1403
IIS web logs can also be parsed automatically within the Exchange Management Powershell. Issuing the following command:
(where you may need to substitute the path to the IIS log files and the specific log file name, and also ensure that the target output directory exists)
Will create several CSV files:
The UserAgents and Users files will list conveniently all access requests including device type and platform:
To display a list of configured policies, issue a Get command: