Exchange 2003 Service Pack 2 (SP2) Remote Wipe functionality

Here is some fantastic information on SP2's Remote Wipe functionality from Salman Zafar

Remote Wipe is a new feature in E2K3 SP2 that will enable the Exchange admins to force a device to delete its contents remotely. This can come in very handy when an end user loses their device or if the device is stolen -- and there is a risk that someone could access personal or confidential data. I should point out that there are a number of other policy/security related features in E2K3 SP2 to help mitigate this risk. For example, an Exchange admin can also enforce the user to use a PIN, can enforce a length for the PIN, can enforce whether the PIN is numeric or alphanumeric, and can enforce a specific PIN timeout. This coupled with the local wipe capability -- which removes all data from the device when someone enters an incorrect PIN x number of times provides good risk mitigation when a device is lost of stolen. But, remote wipe is intended to provide an additional layer of security on top of all this.

Remote Wipe UI

There is an ASP.NET administration web page which will allow the admin to view the list of devices for a particular user at which point the admin can send wipe commands for a given user, delete old or unused partnership between devices and users or even cancel the wipe command issued for a particular device for that user.

The web page has a transaction log which can be viewed by any admin that accesses that webpage and it shows a list of all actions taken on a particular user and device partnership containing the Date and Time when the activity took place, the user name, the SMTP address, Device ID, Device Type and the action that was taken (e.g. Cancel Wipe, Delete).

The setup will only work for administrators. IIS6 is required for the install. With IIS5 we have an auth issue with the tool. The way we designed it is we wanted admins to be able to give permissions to other users to access the page if needed. For that requirement we had to use the System account the app pool runs under to do an admin logon to the BE. This works great in IIS 6 since the app pool runs as local system. However, in IIS 5 the settings are to run asp.net WP under IWAM_machinename which is a restricted account.

What gets installed when we run the setup

Once the setup is run, a vdir with the name "MobileAdmin" is created and only Network Service/ASP.NET or administrator have access to it. A directory called "Microsoft Exchange ActiveSync Administration" is also created under Program Files.

Using the MobileAdmin webpage

To view the website we require SSL. This might require a cert to be issued. If that is the case, it will be issued automatically. To view the webpage type

            https://<ServerName>/MobileAdmin

Note: since we require SSL you have to use HTTPS. If you use HTTP, you will get the following error message "The page must be viewed over a secure channel"

Once you enter the URL using https you might get the following security alert asking you if you want to install the cert if you don't have one already.

Note: You might or might not see this depending on if you need the cert to be installed or not.

At this time, either the admin or those users who have permission to view this page will be able to view the main page. The admin will be required to enter their credentials before proceeding.

To give a user permission to access this page you can either go to IIS Manager. Right click on MobileAdmin vdir and click on Permissions and add the user you want to give permissions to.

Alternatively, you can go to <installDrive>\Program Files. Right click on "Microsoft Exchange ActiveSync Administration". Select Sharing and Security and go to Security Tab and add the user here.

Click on Remote Wipe on main page to view partnerships for a particular user and to issue wipe, Cancel wipe and delete partnerships as shown:

The snapshot above shows all the partnerships for user Sync1. The admin issued a RemoteWipe for DeviceID=Device1 and DeviceType=PocketPC which was acknowledged by the device. The data shows when the Wipe was initiated, when it was sent to the device, when the device acknowledged it and the status of the wipe command which in this case is the wipe operation completed successfully.

Also note, that DeviceID=NSFJITNAA has not yet sent acknowledgement yet.

If a user does not exist or does not have any partnerships an error message will be displayed which will specify if user does not exist or mailbox is not enabled or no devices were found for that mailbox.

Using PROPPATCH to issue Remote Wipe

A remote wipe is requested by setting the "wipeinitiated" property on the mailbox of the user to a non-zero time value.  By "the mailbox", I really mean the folder where we store sync related stuff.  For a user of "salman", a device type of "smartphone", and a device id of "testdevice", that folder would be:

/exchange/salman/NON_IPM_SUBTREE/Microsoft-Server-ActiveSync/smartphone/testdevice

We can issue a PROPPATCH to set this property.

PROPPATCH /exchange/<mailbox>/NON_IPM_SUBTREE/Microsoft-Server-ActiveSync<DeviceType>/<DeviceID>

Host: <Server>

Brief: t

Accept-Language: en

Content-Type: text/xml

Content-Length: 406

Connection: Keep-Alive

 

<?xml version="1.0" encoding="utf-8"?>

<propertyupdate xmlns="DAV:" xmlns:A="AirSyncCustom:">

 <set>

  <prop>

   <A:wipeinitiated>2005-03-22T00:00:30.078Z</A:wipeinitiated>

  </prop>

 </set>

</propertyupdate>

The specific time isn't important -- the only thing that matters is that it is non-zero when mapped to a FILETIME, where zero means something like January 1, 1601.

What Happens at Protocol layer

At protocol level, the server determines the admin has scheduled the device for remote wipe and sends back HTTP 449 in response. The device then provisions and acknowledges receipt of the remote wipe and subsequently executes the Remote Wipe command.

When the admin schedules the device for remote wipe, and the user issues a provision command, it sends down a Remote Wipe element indicating that the recipient is to initiate the remote wipe sequence.

In the 2nd phase or Acknowledgement part of provision command, an acknowledgement is provided that the remote Wipe directive has been received. Upon receiving the remote Wipe from the server via Provision response, the client issues an acknowledgement indicating its success or failure in receiving it. The status of remote wipe should only indicate success if device processed command correctly and intends to execute a wipe of local contents.

When we process a PROVISION command for a device that is to be remote wiped, we consider the following:

Timestamp Value	Remote Wipe bit True?	State Description	Action
Sent:<time>	Yes	Client didn’t ack last time and is re-sending PROVISION (i.e. if PROVISION response from server was lost last time)	Issue PROVISION response with remoteWipe element
Default	Yes	Expected case.  Device is connecting for the first time after admin specified remote wipe	Issue PROVISION response with remoteWipe element
Ack:<time>	Yes	Error – implies that device ack’d but did not carry out remote wipe command.	Issue PROVISION command with remoteWipe element

This shows up on the webpage as: