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.

Quarantine

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
 –AdminMailRecipients administrator@domain.com

This will cause any connection requests to be initially denied, and an emailing flagging the connection request to be sent to 'administrator@domain.com'. 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 jamesl@domain.com –ActiveSyncAllowedDeviceIDs 
BC2DD3AE37CE0CB225D6D0BDBFECCC69

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
User=administrator&DeviceId=BC2DD3AE37CE0CB225D6D0BDBFECCC69&DeviceType=PocketPC&
Log=LdapC21_LdapL48_Error:
UserDisabledForSync_Budget:(D)Conn%3a1%2cAD%3a%24null%2f%24null%2f0%25%2cCAS
%3a%24null%2f%24null%2f1%25%2cAB%3a%24null%2f%24null%2f0%25%2cRPC%3a%24null
%2f%24null%2f0%25%2cFC%3a%24null%2f0%2cHash%3a51198184_
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

For example.

IIS web logs can also be parsed automatically within the Exchange Management Powershell. Issuing the following command:

export-activesynclog -Filename:"C:\inetpub\logs\logfiles\w3svc1
\u_ex091115.log" -outputpath:"c:\temp\logs\"

(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:

• Hourly
• PolicyCompliance
• Servers
• StatusCodes
• UserAgents
• Users

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:

Get-ActiveSyncOrganizationSettings

It is also possible to create rules using Microsoft ISA server without having to mess about at the command line, but this is beyond the scope of this article - largely because I don't currently have an ISA server set up! Read the MobilityDojo web site for more details.

Addendum

With the release of Exchange 2010 Service Pack 1, this process has been facilitated through the addition of Exchange ActiveSync Policy Rules in the Exchange Control Panel web interface.

If a user has attempted to synchronise with Exchange 2010 from their mobile device via Exchange ActiveSync, and you wish to create a policy for all other devices of that same type, you can now do so quickly and easily.
Log into Outlook Web Access with an administrative account and select the option to Manage My Organisation. Browse to Users & Groups. Edit the user with the device you wish to create a policy for:

Expand the Phone & Voice features options and select the option to Edit the ActiveSync policy:

All devices that the user has synchronised with Exchange will be listed. Select the option to Edit the policy for the target device:

Specify what action you wish to assign to the device type, be it "Allow", "Block" or "Quarantine". Save the new device access rule.

Once saved, the new rule will be listed:

From now on, any new devices that attempt to synchronise with Exchange will have the new device access rule applied to them (provided that they appear to Exchange as being the same device type):

Should a device be quarantined, as before you will receive notification that your device has been quarantined, as will the administrator, who will be able to unblock the device if desired, within the web interface: