AADConnect Kommunikation

Die Kommunikation von AADConnect erfolgt per HTTPS gegen Office 365. Ein Blick mit Fiddler zeigt, was da passiert:

Analyse-Setup

Damit ich die Verbindung des ADSync mit der Cloud mitschneiden kann, muss ich natürlich Fiddler in den Weg einschleifen, d.h. der ADSync-Prozess muss Fiddler als Proxy nutzen und dem Zertifikat vertrauen. Daher haben ich einfach mal schnell Fiddler mit auf dem System mit ADSync installiert. Die Proxy-Einstellungen, die Fiddler dabei macht, helfen aber nicht weiter, denn ADSync ist ein Systemprozess der zudem nicht die IE-Controls sondern das .NET-Framework ändert. Entsprechend muss ich in der machine.config der Windows Instanz den Proxy hinterlegen. Die Datei liegt in der Regel in "C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config\machine.config"

Hier müssen Sie folgenden Abschnitt unter "<configuration>" addieren, wenn er noch nicht vorhanden ist und Fiddler auf dem gleichen System gestartet ist

   <system.net>
        <defaultProxy>
            <proxy
            usesystemdefault="true"
            proxyaddress="http://localhost:8888"
            bypassonlocal="true"
            />
        </defaultProxy>
    </system.net>

Microsoft hat auf folgender Seite schön dokumentiert:

Allein das Speichern der Änderung scheint sofort aktiv zu werden. Sie sollten also Fiddler schon "gestartet" und die in Fiddler integrierte CA als "vertrauenswürdig" eingestuft haben.

Überblick

Ich habe dann aber doch vorher den ADSync-Prozess gestoppt und mit aktiven Fiddler dann gestartet. SO sehe ich, was er beim Start so alles macht. Hier eine Übersicht der ersten Verbindungsaufnahme, dem Update einer Beschreibung und des Updates der Kennwort. Ich habe nicht relevante Zeilen gelöscht, so dass die Paketnummern nicht aufsteigend sind.

Folgende Blöcke sind zu sehen:

  • Paket 3,4,6,8,10 - Initiale Verbindung
    Der miiserver verbindet sich und prüft die anstehenden Änderungen. Es gibt keine
  • Paket 12-26 - Änderung DisplayName
    Ich habe On-Prem bei meinem Benutzer den DisplayName geändert und die Replikation angestoßen
  • Paket 28-42
    Bei aktiviertem "Kennwort-Sync" habe ich lokal das Kennwort geändert und die Replikation nach Office 365 angeschaut.

Schauen wir uns ausgewählte Pakete mal genauer an

Der Anmeldeprozess

Allen drei Transaktionen ist gemeinsam, dass es Zugriffe auf "adminWebService.microsoftonline.com gibt aber davor immer ein paar Request auf login.windows.net erfolgen. Interessant dabei ist, dass die Spalte "Authorization" immer leer ist und es beim "Result" immer ein 200OK kommt. Die Anmeldung an der Schnittstelle erfolgt also nicht über die klassische WebAnmeldung, sondern aus Sicht des HTTP-Stacks ist es immer eine "anonyme Verbindung". Die Information bezüglich Anmeldung und Session sind allein im Payload zu finden. Die HTTP-Fehlercodes sind also kein Indikator mehr, ob eine Verbindung erfolgreich ist Probleme hat.

Das erste Paket ist eine erste Abfrage zu Details über den Benutzer und Tenant. Übermittelt wird der DirSync-Benutzername aber noch keine Anmeldedaten. Das ist eigentlich eine Art "Autodiscover"

Die JSON-Antwort liefert dann weitere Details. Kurz darauf sendet der Client den nächsten Request. Das ist diesmal ein Post

In der JSON-Antwort finden Sich nun entsprechende Tokens, die für die folgenden Zugriffen erforderlich sind. Im Header fehlt aber die wichtige Information. Der POST ist aber ein Hinweis, dass diese Daten im Body als Formulardaten übertragen werden. Also schaue ich mit den Body zum Request an:

Hier sehen ich dann den Benutzernamen und das Kennwort, welches bei mir 16 Zeichen lang ist und wirklich nicht "merkbar" ist. Dieses Verfahren nutzt also weder NTLM noch Kerberos oder eine andere "Sichere Authentifizierung". Es ist daher wichtig, dass solche Verbindungen möglichst durchgängig stark verschlüsselt sind.

Status auslesen

Mit der nächsten Anfrage stellt der MIIServer-Client die Frage, wie der Tenant konfiguriert ist. Leider ist das nun nicht mehr XML oder JSON, sondern Microsoft hat einen neuen Content-Type "application/soap-msbin1" definiert, der zwar grob lesbar ist, aber doch irgendwie eine teilweise binäre Information ist.

Ich kann in der Antwort schon erahnen, dass ich den Displayname des Tenant und Einstellungen zu Kennwortabgleich erhalten. Zudem git es wohl auch Informationen, wie viele Objekte addiert oder entfernt wurden.

Change schreiben

Da die Daten als solches ja nun eine schwer lesbares Binärformat ist, belasse ich es bei einer einzigen Transaktion, bei der ich meinen Displaynamen geändert habe. Man muss schon etwas suchen, aber kann schon erahnen, was da passiert. Natürlich ist vorher wieder die komplette Anmeldung und Statusabfrage gelaufen, ehe dieser Provision-Request stattfand.

Im Request ist das Feld "Description" mit einem Wert vom Typ "String" enthalten. Bei dem dritten Request war dort auch das Feld "PasswordLastChange" zu sehen. Aber ich habe zumindest nicht "lesbar" die Inhalte gesehen.

Erkenntnis

Auch AADConnect nutzt keine Geheimwissenschaften um das lokale Active Directory mit dem Office 365 Tenant zu synchronisieren. Es sind einfache HTTP-GET/POST-Request, die keine besondere Herausforderungen an Proxy-Server und Firewalls stellen. Allerdings verwendet Microsoft nur bei der Anmeldung "lesbare" Protokolle. Die eigentliche Datensynchronisation ist nur noch mühsam zu lesen.

Das Zwischenschalten eines Proxy-Servers zur Analyse ist einfach und schnell gemacht aber viel mehr als generelle Probleme z.B. bei der Anmeldung werden Sie über dieses Werkzeug kaum sehen. Hier sind das Eventlog, die Office 365 Fehlermeldungen und der DirSync Status eine viel bessere Quelle für die Fehlersuche.

Weitere Links