Remotewipe im Detail

RemoteWipe funktioniert nur, solange ActiveSync noch funktioniert: d.h. das Löschen funktioniert nicht, wenn eine der folgenden Dinge zutrifft:

SIM-Karte wurde schon gesperrt -> keine GPRS Verbindung mehr möglich
Kennwort im AD geändert -> kein ActiveSync mehr möglich, Tipp: Zertifikate nutzen
GSM-Teil abgeschaltet.

Insofern sollten Sie ERST einen WIPE ausführen, ehe Sie die SIM-Karte sperren lassen und das AD-Konto deaktivieren.

Auf der Seite Exchange ActiveSync Server habe ich bereits die prinzipielle Funktionsweise von Active Sync über HTTP/HTTP erläutert. Eine genauere Betrachtung der HTTP Datenverkehre ist auf Always Up-to-date (AUTD) beschrieben. Eine wichtige Funktion des MSFP ist aber auch die Funktion "RemoteWipe". Als Administrator können Sie mittels dem MobileAdmin per Webbrowser einen "WIPE"-Befehl für ein Mobiles Endgerät einstellen, welches dann bei der nächsten Synchronisation das Endgerät löscht. Nur wie funktioniert das ?

Remote Wipe und Exchange 2003

Die Funktion, Mobilgeräte aus der Ferne zu löschen ist erst mit Exchange 2003 SP2 im Jahre 2005 eingeführt worden. Auch damals war die Verwaltung über einen Webbrowser zugänglich aber natürlich bei weitem nicht so elegant integriert wie mittlerweile bei Exchange 2010. Sie mussten dazu erst den "MobileAdmin" installieren, was de facto eine IIS-Applikation war.

Der Mobile Admin war aber nicht Bestandteil des Exchange 2003 SP2, sondern ein eigener Download:

Microsoft Exchange Server ActiveSync Web Administration Tool
http://www.microsoft.com/en-us/download/details.aspx?id=22243

Remote Wipe und Exchange 2007

Mit Exchange 2007 SP1 kann der Anwender nun sogar selbst per OWA auf dem Internet sein verlorenes Gerät löschen:

Remotewipe mit OWA2007

RemoteWipe und Exchange 2010

Auch bei Exchange 2010 kann der Anwender per Outlook Web App einfach sehen, welche Mobilgeräte mit dem Postfach verbunden sind und kann diese dort auch selbst zurücksetzen.

Neu ist bei Exchange 2010 die Bestätigung per Mail

Remote Wipe umgehen ?

Damit das zuverlässig funktioniert, sollte diese Logik nicht abschaltbar sein. Das ist aus meiner Sicht auf der Grund, dass das MSFP nicht als ein Windows Update Oder AddOn installiert werden kann, sondern das Betriebssystem selbst im Rahmen eines Firmware Update durch den Hersteller des PDAs erfolgen muss.

Allerdings ist die Funktion von ActiveSync über HTTP auch eine mögliche Variante als Anwender den WIPE-Befehl außer Kraft zu setzen. Ich kann mich mit einem eigenen Programm analog zu ActiveSync natürlich mit dem ActiveSync Server verbinden und die Werte wieder zurücksetzen. Die Einstellung ist ein Teil meines Postfachs und dort habe ich die Rechte darauf. Für den Anwender selbst ist dies aber nur schwer möglich, da es meines Wissens noch kein entsprechendes Programm gibt. Man müsste also schon selbst mit MFCMAPI und anderen Wege arbeiten. Aber selbst dann würde sich der Anwender nur selbst schaden, denn es ist ja sein Telefon, welches nicht mehr in seinen Händen ist.

Für einen Angreifer ist es auch nicht einfach möglich, da er sich natürlich am Webserver mit den gültigen Anmeldenamen und Kennwort authentifizieren muss. Diese Wege sind daher eher theoretischer Natur. Vermutlich ist es dann sogar einfacher die DeviceID des Endgeräts zu ändern oder über einen Proxy zu modifizieren.

Remote Wipe und Eventlog

Ein Fall bei einem Kunden hat mich vor die Frage gestellt, ob man denn auch nachvollziehen könnte. wer wann ein Gerät zum "Wipe "eingestellt hat und ob dieses auch gewiped wurde. Ich habe die Frage nur noch auf einem Exchange 2013 Server überprüfen können und folgendes gefunden

Log Name:      MSExchange Management
Source:        MSExchange CmdletLogs
Date:          12/13/2013 12:11:44 PM
Event ID:      1
Task Category: General
Level:         Information
Keywords:      Classic
User:          N/A
Computer:      NAWEX13.netatwork.de
Description:
Cmdlet suceeded. Cmdlet Clear-MobileDevice, parameters {Identity=WP§945A0F6BC08FF04969}.
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="MSExchange CmdletLogs" />
    <EventID Qualifiers="16384">1</EventID>
    <Level>4</Level>
    <Task>1</Task>
    <Keywords>0x80000000000000</Keywords>
    <TimeCreated SystemTime="2013-12-13T11:11:44.000000000Z" />
    <EventRecordID>4909</EventRecordID>
    <Channel>MSExchange Management</Channel>
    <Computer>NAWEX13.netatwork.de</Computer>
    <Security />
  </System>
  <EventData>
    <Data>Clear-MobileDevice</Data>
    <Data>{Identity=WP§945A0F6BC08FF04969}</Data>
    <Data>netatwork.de/Abteilung/Technik/Carius, Frank</Data>
    <Data>Local-ECP-Unknown</Data>
    <Data>10756 w3wp</Data>
  </EventData>
</Event>
Get-MessageTrackingLog -MessageSubject "Bestätigung der Remotegerätzurücksetzung"

EventId  Source   Sender                            Recipients                        MessageSubject
-------  ------   ------                            ----------                        --------------
HARED... SMTP     Frank.Carius@Netatwork.de         {Frank.Carius@Netatwork.de}       Bestätigung der Remotegerätzur...
RECEIVE  SMTP     Frank.Carius@Netatwork.de         {Frank.Carius@Netatwork.de}       Bestätigung der Remotegerätzur...
AGENT... AGENT    Frank.Carius@Netatwork.de         {Frank.Carius@Netatwork.de}       Bestätigung der Remotegerätzur...
SEND     SMTP     Frank.Carius@Netatwork.de         {Frank.Carius@Netatwork.de}       Bestätigung der Remotegerätzur...
DELIVER  STORE... Frank.Carius@Netatwork.de         {Frank.Carius@Netatwork.de}       Bestätigung der Remotegerätzur...
RECEIVE  STORE... Frank.Carius@Netatwork.de         {Frank.Carius@Netatwork.de, Fr... Bestätigung der Remotegerätzur...
SUBMIT   STORE... Frank.Carius@Netatwork.de         {Frank.Carius@Netatwork.de, Fr... Bestätigung der Remotegerätzur...

Allerding gibt es wohl keinen Weg zu erkennen, wann das Gerät denn auch den Wipe angenommen hat. Das wäre dann nur im Objekt im Postfach zu sehen, welches aber durch den Anwender auch entfernt werden kann. Insofern bleibt nur die Information, wann der "Clean-MobileDevice" aktiviert wurde.

Remote Wipe Intern

Die Funktion ist so einfach und trivial, aber effektiv. Der WIPE-Befehl ist eine Einstellung, die im Postfach des Anwenders hinterlegt wird. Wenn Sie mit MFCMAPI das Postfach eines Benutzers öffnen, welcher ein mobiles Endgerät hat, dann finden Sie in einem Systemordner einen Ordner "Microsoft-Server-ActiveSync" in dem es für jeden Client und der DeviceID einen Eintrag gibt.

Hier speichert sich ActiveSync einige Informationen ab, die für den Abgleich erforderlich sind. Wenn Sie über den MobileAdmin ein Gerät "Löschen" (DELETE) dann wird darüber einfach der dazugehörende Ordner gelöscht.

Mit diesem Wissen ist es nun natürlich einfach, die Daten dort einmal vor und einmal nach einen "WIPE" zu exportieren und zu vergleichen. Sie werden dann feststellen, dass ein nicht näher benanntes MAPI-Property vermutlich die entsprechenden Daten enthält. Die Daten könnten auch den Verdacht aufkommen lassen, dass hier auch Kennwortrichtlinien etc. hinterlegt sind, obwohl diese in der Exchange Organisation eingestellt werden.

Der RemoteWipe ist also keine versteckte Systemmail, die im Postfach des Benutzers abgelegt wird, sondern eine Systemeinstellung. ActiveSync liest diese Einstellung bei jeder Synchronisation noch vor der Übertragung von Nachrichten, Terminen oder Kontakten. Das habe ich z.B.: daran gemerkt, dass ich ein Gerät per "Remote Wipe" gelöscht und den WIPE nach dem Erfolg nicht wieder entfernt habe. Als ich dann das Gerät wieder einrichten wollte hat es sich gleich zu Anfang der Synchronisation gleich wieder gelöscht.

Diese Zugriffe sieht man auch im IISLog. Hier ein Auszug einer Protokolldatei. Zur Lesbarkeit wurden einige Informationen entfernt.

POST /Microsoft-Server-ActiveSync User=msxfaq\mobil01&DeviceId=IMEI000&DeviceType=NokiaE60&Cmd=Sync&Log=xx 443 msxfaq\mobil01 NokiaE60/1.0 200 0 0

PUT /exchange/mobil01@msxfaq.de/NON_IPM_SUBTREE/Microsoft-Server-ActiveSync/NokiaE60/IMEI000/220dc68-3302 201

PROPFIND /exchange/mobil01@msxfaq.de/NON_IPM_SUBTREE/Microsoft-Server-ActiveSync/NokiaE60/IMEI000 207

Die erste Zeile ist die Anforderung des Clients (POST mit "Cmd=Sync"), welche dann von der mobsync.dll in eine Anfrage an OWA selbst umgesetzt wird. Man sieht, dass zum einen mit einem PUT ein Eintrag im Ordner "Microsoft-Server-ActiveSync/NokiaE60/IMEI000/220dc68-3302" geschrieben wird. Aber viel interessanter ist das "Auslesen" von "/exchange/mobil01@msxfaq.de/NON_IPM_SUBTREE/Microsoft-Server-ActiveSync/NokiaE60/IMEI000". Dort steht z.B. die Information über RemoteWipe.

Das können Sie ebenfalls mit MFCMAPI wunderbar einsehen. Allerdings sind die Daten nicht wirklich in Klartext aber durchaus interpretierbar. Gehen Sie dazu auf die IMEI bzw. GUID des mobilen Geräts:

und wenn Sie dann das Property "0x361C0102" anzeigen, dann kann man vermuten, dass es sowohl die Einstellungen für den Wipe als auch die Richtlinien zu Kennworten etc. enthält.

Wenn sie mögen, können Sie ja die Werte per Exchange System Manager und MobileAdmin beeinflussen und analysieren.

Ich würde aber nicht direkt hier Änderungen durchführen. Im Zweifel sollten sie den kompletten Zweig löschen und die Partnerschaft mit dem mobilen Endgerät neu einrichten.

Über Exchange ActiveSync Server und Always Up-to-date wird der Client dann benachrichtigt, repliziert und erkennt, dass er sich löschen muss. Dass der Client die Anforderung erhalten hat als auch die Ausführung meldet er ebenfalls wieder zurück und schreibt die Werte dort hinein.

Inkonsistenzen mit Remote Wipe

Normalerweise sollte ein Gerät nicht einfach nur “Entfernt” werden, sondern erst mit einem „Clean-ActiveSyncDevice“ ein WIPE versucht werden und nach dem Erfolg das Gerät aus der Exchange Konfiguration entfernt werden. Ein neues ActiveSync Gerät wird in der Mailbox selbst als Partnerschaft eingetragen aber seit Exchange 2010 auch beim Benutzerobjekt als „Unterobjekt“. Damit können Commandlets wie „Get-ActiveSyncDevice“ oder „Get-CASMailbox seht schnell filtern. Gerade dieses AD-Objekt kann aber zu Störungen führen. Zwei Fälle sind mir bislang bekannt geworden

  1. Benutzer werden „Exchange deaktiviert“
    Damit verliert der Benutzer sein Postfach und damit auch die EAS-Partnerschaft darin. Das AD-Objekt bleibt aber bestehen. Das stört z.B. Get-ActiveSyncDevice, welches nach AD-Objekten der Klasse „msExchActiveSyncDevice“ sucht und damit auch diese Reste findet. Eine Weiterverarbeitung ist nicht schlimm, aber als Programmierer müssen Sie den Fall abfangen, dass dieser Anwender gar kein Postfachbenutzer hat und damit z.B. Get-ActiveSyncDeviceStatistics nicht funktioniert
  2. ADMT Move schlägt fehl
    Wer mit ADMT Objekte innerhalb des Forest verschiebt, kann diese Benutzer nicht verschieben, weil unter dem Benutzer nun auch die ActiveSync-Geräte angelegt werden: Hier ein Beispiel mit ADSIEDIT.MSC sichtbar gemacht:

    Eine ganze Menge von Partnerschaften sind hier noch vorhanden.
  3. Benutzer wird verschoben.
    Aber auch wenn ein Anwender innerhalb der Domäne in eine andere OU verschoben wird, dann kann das später zu Problemen führen, da Exchange bei der Anlage dieses AB-Objekts auch die ersten 64-Stellen den DN des Users in dem Feld msExchUserDisplayName füllt

    Dieser Eintrag wird NICHT aktualisiert, wenn der Benutzer samt den Unterobjekten in eine andere OU verschoben wird.

Die beiden ersten Punkte sind zwar nervig und unschön, aber stören nicht die Funktion von Exchange selbst. der dritte Punkt aber ist schon nerviger, da z.B. ein "Remove-ActiveSyncDevice" bei solchen Benutzer einen Fehler produziert

Genau dieser Fall wird von Microsoft auch in einem KB-Artikel behandelt: 2721428 Error message when you try to perform a remote wipe operation for a device in Exchange Server 2010: "The ActiveSyncDevice identity cannot be found". Die drei Lösungsvorschläge musste ich schon mit einem Schmunzeln lesen.

  1. Method 1: Move the user to the OU where the device was first synchronized
  2. Method 2: Rename the user account in AD DS
  3. Method 3: Use the Clear-ActiveSyncDevice cmdlet

Methode 1 ist ungeschickt, wenn es die QuellOU nicht geht gibt und kritisch, wenn auf dieser OU z.B. andere Gruppenrichtlinien wirken. Methode 2 könnte auch das ein oder andere "Provisioning-System" durcheinander bringen. Die Option3 hingegen ist eigentlich der richtige Weg: Ein Gerät sollte immer erst mit einem "Clear-ActiveSyncDevice" gelöscht werden, ehe die Partnerschaft aufgehoben wird.

Ich habe versucht eine sichere Lösung per Script zu bauen, aber da nirgendwo die internen Abläufe öffentlich dokumentiert sind, ist dies nicht zuverlässig. Rausgefunden habe ich:

Insofern sollte man wirklich am besten mit GEt-CASMailbox die Postfächer suchen, die mobile ActiveSync-Partnerschaften haben

$EASUserList = Get-CASMailbox `
   -resultsize unlimited `
   -ignoredefaultscope `
   -Filter {hasactivesyncdevicepartnership -eq $true -and -not displayname -like "CAS_{*" -and -not displayname -eq $Null} 

Dann können diese Objekte überprüft werden, ob deren msExchUserDisplayName "unpassend" ist. So kann zumindest ermittelt werden, welche Objekte später einmal nicht gelöscht werden können.

 

Weitere Links

Tags:EAS ActiveSync AUTD MobileAdmin RemoteWipe