ActiveSync Inside

Achtung
Die Ausgaben beziehen sich auf Exchange 2007 mit Windows Mobile 6.0. Offensichtlich überträgt EAS die Nutzdaten nun nicht mehr als XML-Daten sondern irgendwie binär und nutzt auch nicht mehr die OPTIONS-Befehle.

Wer einen ActiveSync Server im Internet bereit stellt, stellt natürlich auch die Frage, wie er diesen HTTPS-Zugang gut absichern kann. Nur kleine Firmen werden den IIS mit Exchange direkt aus dem Internet per Reverse NAT auf Port 443 erreichbar machen. Die meisten Firmen haben einen Reverse Proxy davor, der den SSL-Tunnel aufbricht und in die URLs und den Content hinein schaut. Leider gibt es dazu aber fast keine öffentliche Dokumentation so dass ich selbst einfach mal meine ActiveSync-Verbindung mit NetMon ohne SSL mitgeschnitten habe.

Sicherheit:
Ein solcher Mitschnitt ist nicht möglich, wenn die Verbindung vom Mobilgerät zum Exchange Server per HTTPS durchgehend verschlüsselt ist. Sie können aber über einen Reverse Proxy natürlich die SSL-Verschlüsselung als Betreiber aufbrechen und dann auch die Inhalte ohne SSL an den Exchange weiter geben. Diese Konfiguration ist aber nicht ratsam.

Seit Exchange 2010 kann ein Anwender über OWA selbst über das Exchange Control Panel eine "Diagnose" einstellen. Sobald ein Gerät den ersten "Request" mit erfolgreicher Anmeldung generiert hat, ist es dort sichtbar. Dies hilft also nicht bei generellen Problemen der Erreichbarkeit oder falschen Anmeldedaten oder Zertifikaten.

ActiveSync unterstützt mehrere Befehle und ich habe mich hier auf eine Auswahl beschränkt.

Erster Kontakt und Provisioning

Ausgehend von einem "Problem" einen Nokia Lumina 920, welches mit Windows Phone 8 sich nicht anmelden konnte, habe ich folgenden Trace auf dem Exchange Server gezogen. Ich habe die Ausgabe etwas um nicht weiter relevante Abschnitte "gekürzt".

  • Die erste Anfrage
    Sie sehen hier, dass das Gerät das erste Mal eine Anfrage stellt. Die Tatsache, dass dieser Request im Log sichtbar ist sagt, dass die Erreichbarkeit und die Verbindung per SSL möglich und die Anmeldung erfolgreich war.
    Ich habe natürlich die DeviceID und Rufnummer unkenntlich gemacht. Es ist aber gut zu sehen, dass das Nokia anscheinend die Rufnummer nicht sauber im E.164-Format sendet. Statt +0152 müsste da ein +49152 stehen.
    Es ist auch gut zu sehen, das das Nokia Lumina 920 kein SMS-Versand über ActiveSync erlaubt.
    Im Header ist gut zu sehen, dass das Feld "X-MS-PolicyKey" noch auf 0 steht.
RequestHeader : 
POST /Microsoft-Server-ActiveSync//ult.eas?Cmd=Provision&DeviceId=xxxxxxxxxxx&DeviceType=WP8 HTTP/1.1
Cache-Control: no-cache
Connection: Keep-Alive
Pragma: no-cache
Content-Length: 182
Content-Type: application/vnd.ms-sync.wbxml
Accept-Language: de
Authorization: ********
Host: owa.netatwork.de
Reverse-Via: NAWTMG
MS-ASProtocolVersion: 14.1
X-MS-PolicyKey: 0

RequestBody : 
<?xml version="1.0" encoding="utf-8" ?>
<Provision xmlns="Provision:">
	<DeviceInformation xmlns="Settings:">
		<Set>
			<Model>RM-821_eu_euro2_248</Model>
			<IMEI>imeiimeiimeiimeiimei</IMEI>
			<FriendlyName>Lumia 920</FriendlyName>
			<OS>Windows Phone 8.0.9903</OS>
			<OSLanguage>German</OSLanguage>
			<PhoneNumber>+0152xxxxxxxx</PhoneNumber>
			<USERAgent>MSFT-WP/8.0.9903</USERAgent>
			<EnableOutboundSMS>0</EnableOutboundSMS>
		</Set>
	</DeviceInformation>
	<Policies>
		<Policy>
			<PolicyType>MS-EAS-Provisioning-WBXML</PolicyType>
		</Policy>
	</Policies>
</Provision>
  • Die Antwort darauf zeigt mehrere Dinge:
    Das Gerät also solches ist schon mal "erlaubt", d.h. keine Quarantäne oder globale Geräterichtlinie verbietet in dem Fall dem Windows Phone 8 Nokia den Zugang. Aber es enthält auch eine Antwort auf die Policy-Anforderung als "MS-EAS-Provisioning-WBXML". Dort ist auch der PolicyKey enthalten und 42bytes im Log nicht weiter aufgeschlüsselte Einstellungen.
AccessState : Allowed
AccessStateReason : Global

ResponseHeader : 
HTTP/1.1 200 OK
MS-Server-ActiveSync: 14.2

ResponseBody : 
<?xml version="1.0" encoding="utf-8" ?>
<Provision xmlns="Provision:">
	<DeviceInformation xmlns="Settings:">
		<Status>1</Status>
	</DeviceInformation>
	<Status>1</Status>
	<Policies>
		<Policy>
			<PolicyType>MS-EAS-Provisioning-WBXML</PolicyType>
			<Status>1</Status>
			<PolicyKey>3809543132</PolicyKey>
			<Data bytes="42"/>
		</Policy>
	</Policies>
</Provision>
  • Zweite Anfrage
    Das Gerät sollte nun die Policy bekommen haben. Der Anwender musste eventuelle Änderungen an den Einstellungen bestätigen. Wenn dies erfolgreich war, dann kommt schon die nächste Anforderung, die einen "Sync" anfordert.
    In diesem Request sieht man nun auch den Hostname und sogar den "Proxy" also "Reverse-Via"
RequestHeader : 
POST /Microsoft-Server-ActiveSync/default.eas?Cmd=FolderSync&DeviceId=xxxxxxxxxxx&DeviceType=WP8 HTTP/1.1
Cache-Control: no-cache
Connection: Keep-Alive
Pragma: no-cache
Content-Length: 13
Content-Type: application/vnd.ms-sync.wbxml
Accept-Language: de
Authorization: ********
Host: owa.netatwork.de
Reverse-Via: NAWTMG
MS-ASProtocolVersion: 14.1
X-MS-PolicyKey: 0

RequestBody : 
<?xml version="1.0" encoding="utf-8" ?>
<FolderSync xmlns="FolderHierarchy:">
	<SyncKey>0</SyncKey>
</FolderSync>
  • Erfolgreich und doch erfolglos
    In der Antwort erkennen Sie den "200 OK", der dem Gerät meldet, dass die Anfrage als solches schon richtig verarbeitet wurde. Allerdings Enthält die Information auch den Status 142 und ein "Blocked:Policy". Das Gerät sendet also einen Sync obwohl es die Policy nicht angewendet hat. Exchange prüft dies aber nur anhand des Feldes "X-MS-PolicyKey: 0" im Request.
AccessState : Blocked
AccessStateReason : Policy

ResponseHeader : 
HTTP/1.1 200 OK
MS-Server-ActiveSync: 14.2

ResponseBody : 
<?xml version="1.0" encoding="utf-8" ?>
<FolderSync xmlns="FolderHierarchy:">
	<Status>142</Status>
</FolderSync>

Auch wenn dieser Trace die erfolglose Verbindung eines Nokia Lumina 920 unter Windows Phone 8 mit Exchange 2010 beschreibt, so zeigt dieser Trace gut die Fehlerursache auf und dass ein "200 OK" eben keine Garantie für "alle in Ordnung" ist. Das Problem scheint nicht ganz unbekannt zu sein.

Bei dem Lumina 920 Case hat es geholfen, das Gerät mit einem "Factory Reset" zurück zu setzen.

Foldersync

Wenn mein Gerät bereits "Synchron" ist und ich manuell eine weitere Synchronisation anstoße, dann sehen Sie im Mitschnitt genau den angeforderten "FolderSync" mit den Anmeldedaten und den allerdings binären Nutzdaten.

In Blau ist dann die Antwort ersichtlich, auf die eine weitere rote Anfrage folgt, die wohl mit "GetItemEstimate" Informationen über die Menge abruft um vermutlich eine Basis für die Anzeige des Fortschritts zu haben.

Inhalte wurden mit diesem Paket aber nicht synchronisiert.

Synchronisation einer Mail

Um eine kleine Mail abzugleichen, habe ich per SMTP eine rudimentäre Mail an mein Postfach zugestellt und die Pakete dazu mitgeschnitten. Die Mail hatte nur folgenden Inhalt:

Diese Mail habe ich per ActiveSync manuell auf meinen Client synchronisiert. Sie erkennen die "POST" Anfrage mit dem Befehl "Sync" und weiteren Daten, die ich mal als "bis hier bin ich gekommen" interpretiere. Der Exchange Server schaut dann nach den Änderungen und sendet die Ergebnisse in einer binären Antwort an den Client.

Sie können auch so in der Antwort zumindest den Absender, den Betreff, einen Zeitstempel, den "Body" und die Nachrichtenklasse erkennen. Weitere Details zum Aufbau einer "vnd.ms-sync.wbxml"-Antwort habe nicht aber auch nicht

Hier mal ein Detail der binären Daten.

Nur ein "PING" bitte

Nach dem Abschluss der Synchronisation sendet der Client wieder ein "PING" an den Server, so dass der Server sich mit seiner Antwort Zeit lassen kann.

Die Antwort habe ich aber nun nicht mehr abgewartet, sondern umgehend die SSL-Verschlüsselung wieder aktiviert.

Weitere Links