Managing Exchange ActiveSync Device Access

Since Microsoft introduced Exchange ActiveSync (EAS) as part of the old Microsoft Mobile Information Server, it has steadily become more widespread. A combination of smart business decisions and technical capability has made EAS the most commonly deployed mobile-device access protocol for Microsoft Exchange Server.

EAS differs from IMAP and POP by combining a protocol for mail access with device management and control. The EAS protocol specifications explain how to retrieve and send mail, perform searches, fetch and apply policies, and so on. (Fun fact: Do an Internet search for "EAS protocol" and you'll find more than you wanted to know about the US Government's Emergency Alert System; but I digress.)

Three EAS-related concepts form the basis of the solution (and understanding how to make it do what you want):

Exchange Server 2010 Service Pack 2 (SP2) implements EAS version 14.2. However, not every client can say the same. Because so many mobile devices support EAS, you can't assume that any particular device family supports a particular EAS version, or even all the features in that version. Microsoft started a Wiki page to document which specific EAS features various device and OS combinations support. It's a valuable reference because it tells you whether a given device will support an EAS policy or feature that you need. For example, Apple's iOS 5 and Google's Android Ice Cream Sandwich release both support the disable camera EAS setting, but other versions don't. These policy controls are useful, but what do you do to keep out devices that don't implement the policies that you want? That's what the Allow/Block/Quarantine (ABQ) functionality is intended to do.

EAS Policies

Before we talk about ABQ, we need to explore a few EAS policy concepts a bit more. When you install Exchange 2010, you get a default EAS policy that doesn't apply anything in the way of security controls. The policy is there just so that when new devices sync with the server, there's a policy to give them.

Many protocols provide some means of negotiation, whereby the client and server can agree on exactly how their communications should go. EAS isn't one of these protocols. When a device first synchronizes, the server and client negotiate which EAS version they'll use; they agree on the highest version that they both support. This happens when the client sends a provisioning request to the server and the server responds with a temporary synchronization key and a policy. The client should return an indication that it will enforce the server-supplied policy. The client then gets a permanent synchronization key, and there's no further checking or enforcement of what the client says. In an EAS conversation, the Exchange server presents a policy to the client, and the client is expected to honor it.

A mechanism exists to allow the client to indicate that it couldn't apply some parts of the policy in either of two ways: The client can indicate that part of the policy is irrelevant (e.g., disabling Bluetooth on a device that doesn't support it) or that the policy couldn't be applied (e.g., requiring device encryption that isn't supported). Beyond this mechanism, the server has no enforcement mechanism to verify that the client is telling the truth. For example, some versions of Apple iOS lie about whether they can enforce device encryption when the EAS policy is set to require it. Therefore, you might create a policy that's honored by only some of the devices that sync with your server, and you won't know unless you keep track of which devices you have and the specific policy features that they do and don't support.

The simplest way to apply a given set of EAS settings is to change the settings of the default policy to match the values that you want. You can create additional policies to assign to users or groups; each user mailbox can have zero or one EAS policy associated with it. (For more information about managing EAS policies, see "Managing Exchange ActiveSync Policies in Exchange 2010.")

This situation has led to the current ABQ feature set in Exchange 2010. Rather than expect the client to be truthful about its implementation, Microsoft has given us a set of tools to keep out clients whose EAS implementation doesn't conform to a given policy's requirements.

Exemptions, Rules, and Device Access States

One somewhat confusing aspect of Exchange 2010 is that you can sometimes apply a given setting in more than one way. This is definitely true of mobile-device access. You can allow or deny users mobile access to their mailboxes in three ways.

First, you can use the Set-CASMailbox cmdlet with the -ActiveSyncEnabled parameter to turn off EAS access for the user's mailbox. Of course, if you turn off EAS, the user won't be able to synchronize any device (which might be exactly what you want). As a security measure, many organizations disable EAS for all mailboxes and then enable it only for users who have permission to sync their devices.

Second, you can create explicit personal exemptions that either allow or block devices on a given mailbox. For example, you might set the CEO's mailbox so that she can sync her iPad and iPhone, but nothing else. These exemptions are set by using the Set-CASMailbox cmdlet with the -ActiveSyncAllowedDeviceIDs and -ActiveSyncBlockedDeviceIDs switches to allow and block devices, respectively. The device ID is unique to a given device; think of it as a globally unique identifier (GUID) specific to an individual gadget. The simplest way to get these IDs is to allow the device to synchronize and then use Get-CASMailbox, like this:

 Get-CASMailbox | select name, ActiveSyncAllowedDeviceIDs

That pipeline gives you a table of all the currently enabled devices and their IDs. If you just want the device IDs associated with a single mailbox, you can use the Get-ActiveSyncDeviceStatistics cmdlet, as shown it the following example:

Get-ActiveSyncDeviceStatistics -mailbox "paulr" 

The third way to allow or deny access is to create device access rules. This name is a little misleading; when most of us think of Exchange rules, we think of things such as Outlook rules or transport rules, which typically contain a condition, an action, and a set of exceptions. EAS ABQ rules specify a device family and a device model. The predefined families include the iPhone, iPad, iPod, Android, and Windows Phone. After a user has synchronized a device that you want to use as the basis for a device access rule, you can create one by performing the following steps:

Figure 1: Choosing a Device to Use as a Rule Basis 

You can also manipulate device access rules from EMS by using the *-ActiveSyncDeviceAccessRule cmdlet. You'll need to do this if you want to create access rules for devices that don't have family or device strings already created. Check the documentation for New-ActiveSyncDeviceAccessRule and you'll see how it's done: You specify the device name, the UserAgent string that the device delivers when it makes HTTP requests, the device model, and so on. Be aware, though, that the values you use here must exactly match what the device reports, so you might need to let a test device sync so that you can see which model, UserAgent, and so on the device actually reports.

The ABQ mechanism also relies on the fact that every EAS device that's associated with a server is in one of five possible access states:

How do devices move between states? All new devices (i.e., those that have never previously tried to sync with a mailbox in the organization) start in the device discovery state. This state is short-lived, though. The longest that a device can stay in this state is 14 minutes (1 minute less than the default EAS heartbeat timeout interval). After that, EAS uses a straightforward algorithm to determine which state to use. This algorithm technically begins with forcing the device to authenticate. (If the device can't authenticate, then it doesn't enter any state because the Client Access server won't talk to it.) After the device authenticates, here's how the algorithm works:

Speaking of organizational settings, the most important setting is the one that controls what happens when a device connects and doesn't have any ABQ settings in place. The default is to allow such devices to connect; that is, if the device isn't explicitly blocked, then it's allowed. If you want to change this behavior, you can do so by using the settings that Figure 2 shows.

Figure 2: Changing Default Device Behavior 

You'll see this dialog box when you click Edit on the ActiveSync Access tab of the Phone & Voice slab in ECP. The Allow access, Block access, and Quarantine – Let me decide to block or allow later radio buttons control what happens to devices when sync permissions aren't otherwise specified. The Quarantine notification e-mails list shows which administrators will receive email messages when a device is quarantined. The text field at the bottom of the dialog box allows you to add text that will appear in the default quarantine message that users receive when their devices are quarantined.

Blocking, Quarantining, and Allowing Devices

Now that you know how EAS ABQ is implemented, you're probably wondering how you actually set things up to control which devices can connect. You need to worry about only a few scenarios:

The Future of ABQ

The enterprise computing world is being swept by "bring your own device" mania. Most companies don't want to provide—or pay for—their employees' mobile devices, so they have instead refocused on how to control which devices are allowed to access company assets such as Exchange servers. In that light, the existing ABQ framework is quite useful: It provides tools for allowing or blocking device access based on who the device belongs to or the type of device.

The built-in Windows Mail application in Windows 8 uses EAS and can apply EAS policies. It's too early to tell whether EAS support is a trend, but a key irritation with Outlook Anywhere is that you can't easily control which machines users connect from. Having an EAS-based mechanism for applying security policies to computers running Outlook would be a major improvement, as would better Exchange tools for specifying criteria for allowing, blocking, or quarantining devices.

Despite the allure of these potential improvements, the existing Exchange 2010 EAS ABQ features are quite useful on their own. These features provide a solid foundation for controlling which devices users can use to sync their mailbox data.