MobilityDojo.net

Index for the series:
Exchange ActiveSync Building Blocks – Intro

Background reading (not a pre-requisite):
[MS-ASCMD] Common Status Codes
[MS-ASPROV] Directing a Client to Execute a Remote Wipe
[MSDN] Provisioning, Policies, Remote Wipe, and ABQ in Exchange ActiveSync

In the previous installment in this series we looked at how security policies are pushed down to our Exchange ActiveSync clients, and how to deal with them, or for that matter circumvent them. Thus I thought that it would be suitable to cover a topic highly related to implementation of security policies – how to handle remote wipe

When dealing with the "wipe" concept there are two kinds of wipes we need to be aware of; local wipe and remote wipe.

A local wipe is one that is triggered on the device, usually without any contact with any servers or networks. The most common triggering mechanism would probably be that there’s a security policy in place stating that a failed password x number of times will result in the device hard resetting itself. This policy does not necessarily have to be enforced from Exchange, but in an enterprise scenario users usually aren’t configuring these settings themselves. (Many users don’t enable this setting on their device, and this makes no sense to me; I have content on my device that I don’t want everyone to read even though we’re not talking government level secrets.) Technically it would be a local wipe if you were to choose "reset" in the settings/configuration part of your device as well, but we can probably agree that that’s not relevant to this discussion

A remote wipe is one that is triggered from a central location/server, without any user interaction. For the sake of this article we assume that this server is an Exchange Server, but there are plenty of Mobile Device Management products that also implement this feature either through their own client or employing supporting features in the operating system of the device. A wipe could be triggered both by an SMS message or IP-level notification, but Exchange prefers IP. (There are scenarios where an SMS could trigger a wipe from Exchange as well, but we’re keeping that out of scope as it is not the default to use SMS.) Note that the implementation of this wipe comes in different forms – some ActiveSync clients might interpret the wipe to only remove the data related to the Exchange synchronization partnership, while others will do a full reset of the device. (The latter being the more common.)

Since the Exchange ActiveSync protocol is not the triggering factor in a local wipe, (even if EAS was responsible for deploying the policy), we will concern ourselves only with the remote wipe option.

Read more

Index for the series:
Exchange ActiveSync Building Blocks – Intro

Background reading (not a pre-requisite):
[MS-ASCMD] Common Status Codes
[MS-ASPROV] ActiveSync Provision Protocol Specification
[MSDN] Provisioning, Policies, Remote Wipe, and ABQ in Exchange ActiveSync

I hope you’ve all been following along and gained a deeper understanding of the Exchange ActiveSync protocol, and possibly had time to play with coding something yourself if you are so inclined. We should at this time be able to do the initial FolderSync with Exchange, and handle most errors thrown at us.

There are of course tons of things ActiveSync I haven’t covered yet, and it is a "one step at a time" journey.

If you’re testing against an Exchange Server where you do not have direct access to the admin console, and it is under the control of an Exchange admin who doesn’t permit just about anyone to sync you might have run into issues related to provisioning already, so the next step for us is to cover this very topic.

Provisioning is the mechanism which ensures that ActiveSync clients implement a given set of security policies. If necessary; Exchange Server will block devices that don’t implement the policy set.

Let’s first define a couple of terms:

The "Allow non-provisionable" setting
There is a setting called "Allow non-provisionable devices" in the “Exchange ActiveSync Mailbox Policy” properties that we have toggled on and off a couple of times now. The definition of non-provisionable device is an ActiveSync client which is not able to apply policies to the device.

This comes in two flavors – devices that do not support provisioning at all, and devices that do support policies, but not the specific policies you want to apply. (For instance a commonly unsupported policy is "Encryption".) The device might not serve up an understandable explanation why it will not sync, and Exchange might just say non-provisionable, but the difference can be seen by sniffing the traffic between the device and Exchange.
A provisionable device will request that the server sends down the policy, and will reply with a yes/no to each setting, whereas a non-provisionable device will not request the policies at all.

The corollary to this is that a provisionable device is one that not only accepts policies in general, but also the settings specific to your Exchange Server.

This means that whether you can call a specific device provisionable or not can only be seen in combination with your environment. (If we want to get nitpicklingly technical we could say that Windows Mobile 6.1 and 6.5 are the only "true" provisionable devices as they are the only devices that support all policies.)

If you check the "Allow" switch this means that all devices will be able to sync regardless of whether they support the policies or not. But a device which indicates itself as provisionable will request the policies and implement as many as it can even when it is not forced to do so. If you allow all devices the content of this article will be purely an academical exercise for you, and you’ll be able to sync as shown in previous code samples. You can still tag along if you find it interesting nonetheless of course

There are differences between Exchange 2007 and Exchange 2010 how the server side details are handled, and I will primarily describe the 2010 way of doing it. (My EAS MD utility handles it for ActiveSync protocol version 12.0 – 14.1 so don’t worry – source code can be provided for your specific scenario.)

Read more