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

• The protocol specification explains how devices and Exchange servers are supposed to talk to one another: which commands each can emit, which kinds of responses are legal for each command, and so on.
• Exchange implements EAS on the server side. Besides the code that actually sends and receives data using EAS, there's code that allows administrators to view and set EAS policies through the Exchange Management Console (EMC) and Exchange Management Shell (EMS), code for logging, and code for controlling which devices can connect and what they can do after connecting.
• Clients implement EAS, too. Their implementations are supposed to allow the clients to send and receive email, manipulate existing email items (with operations such as deleting or flagging messages), and accept and enforce policy settings that come from the server.

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:

1. Open Exchange Control Panel (ECP) and launch the Manage My Organization page.
2. Choose Users and Groups, find the user with the target device, and open the user properties.
3. Expand the Phone & Voice Features item, choose Exchange ActiveSync, and click Edit.
4. Choose the device for which you want to create a device access rule, then click Create a rule for similar devices, as Figure 1 shows.

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:

• In the device discovery state, the device has connected and requested synchronization. The device doesn't actually synchronize anything; the server treats the device as though it were quarantined.
• In the allow access state, the device is permitted to access and synchronize with the mailbox.
• In the block access state, the device receives an HTTP 403 Forbidden error. The user might receive an email message indicating that the device is blocked if the block is caused by an explicit ABQ setting. If the device is blocked because it didn't apply policies correctly or because it's a non-provisionable device, then the user isn't notified.
• In the quarantine access state, the device can't read any mailbox data, but it can post new calendar appointments, contacts, tasks, and notes to the mailbox. After the first sync attempt from a quarantined device, the user receives one email message indicating that the device is quarantined. This message appears both on the device and in the user's Inbox. You can configure a set of administrators who should receive email when a new device enters this state.
• The mailbox upgrade state is used when you move a mailbox from an older version of Exchange to Exchange 2010. A device that's associated with a moved mailbox can sync for as many as 7 days. If the device doesn't enter the allow, block, or quarantine state during that time, it loses all access.

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:

1. If EAS isn't enabled for the user's mailbox, the Client Access server returns an error to the device, and synchronization fails.
2. If the device doesn't meet the criteria for applying and enforcing the policy, it's blocked, and synchronization fails.
3. If the device is blocked by an explicit personal exemption, synchronization fails.
4. If the device is explicitly allowed by a personal exemption, it's granted full access.
5. If the device is blocked or quarantined by a device access rule, its state is changed accordingly and synchronization stops. (Note that the term "fails" would be inaccurate because no error is returned to the device.)
6. If the device is explicitly permitted by a device access rule, it's granted full access.
7. If the device state hasn't changed during any of the preceding steps, then the default access state that's set in the EAS organizational settings is applied.

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:

• When you want to block everyone from using all devices, with a few well-specified exceptions, set the organizational EAS policy to block devices, then add personal exceptions for the users and devices that you want to let synchronize.
• When you want to know before any user syncs any device, use the quarantine policy, which is made expressly for this kind of situation. Enable quarantine on the organizational EAS policy and every user who connects a device will be quarantined unless and until you release them.
• When you want to allow some (or all) users to use specified devices only, set the organizational EAS policy to block or quarantine devices, then create a device access rule to allow the devices and families that you want. If there are users you want to exclude, simply turn off EAS on their mailboxes.
• When you want to allow some (or all) users to sync with any kind of devices they want but require other users to get permission, set the organizational EAS permission to quarantine. When a previously unsynchronized device tries to join the party, it will be quarantined unless a personal exemption exists.

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.