Hybrid Identity (Entra / Entra Connect)

Zwei Verzeichnisse, eine Identität

In fast jeder gewachsenen Umgebung existiert das on-prem Active Directory neben Microsoft Entra ID (dem Cloud-Verzeichnis für Microsoft 365 und andere Cloud-Apps). Damit ein Nutzer nicht zwei getrennte Identitäten pflegen muss, verbindet Entra Connect (früher „Azure AD Connect“) beide: Es ist die Synchronisations-Engine, die on-prem Objekte in Entra ID spiegelt.

Der entscheidende Denkfehler, den dieses Modul ausräumt: Hybrid Identity ist keine bequeme Verzeichnis-Kopie, sondern eine neue Trust-Grenze. Der Connect-Server, das Sync-Konto, die Auth-Methode und das Federation-Signaturzertifikat sind allesamt Wege, mit denen eine on-prem-Kompromittierung in die Cloud (und umgekehrt) fließt. Wer diese Grenze nicht versteht, baut sich einen Eskalationspfad, den kein einzelnes Passwort mehr schützt.

Eine hybride Umgebung hat nicht einfach zwei Verzeichnisse, sondern eine Brücke dazwischen — und Brücken tragen in beide Richtungen. Die entscheidende Frage beim Entwurf lautet deshalb nicht, wie man beide Seiten härtet, sondern: Was kann jemand, der genau eine Seite kontrolliert, auf der anderen anrichten?

Von on-prem in die Cloud

Wer das lokale Verzeichnis kontrolliert, kontrolliert alles, was von dort synchronisiert wird — Konten, Gruppen und, bei Passwort-Hash-Synchronisierung, die Anmeldefähigkeit.

Von der Cloud nach on-prem

Funktionen wie Kennwortrückschreibung oder Geräteverwaltung geben der Cloud Schreibzugriff nach unten. Jede aktivierte Funktion ist eine zusätzliche Richtung.

Über den Verbindungsserver

Er hält die Anmeldedaten für beide Seiten. Wer ihn kontrolliert, braucht keine der beiden Seiten zu kompromittieren — er sitzt bereits in der Mitte.

Sync-Topologie: Objektfluss und Source of Authority

Entra Connect synchronisiert Nutzer, Gruppen, Kontakte und Geräte aus dem on-prem AD nach Entra ID. Der Fluss ist grundsätzlich einseitig: on-prem ist die Source of Authority (Quelle der Autorität) für synchronisierte Objekte. Das heißt konkret: Anlegen, Umbenennen, Deaktivieren und Löschen eines synchronisierten Kontos passiert on-prem — eine Änderung im Cloud-Portal an einem synchronisierten Attribut wird beim nächsten Sync-Zyklus überschrieben oder ist gar nicht erst erlaubt.

Es gibt bewusste Ausnahmen vom Einbahnfluss, sogenannte Writeback-Funktionen. Die wichtigste ist Password Writeback: Setzt ein Nutzer sein Passwort per Self-Service-Password-Reset (SSPR) in der Cloud zurück, schreibt Entra Connect die Änderung zurück ins on-prem AD. Solche Writebacks sind eng umrissene, absichtlich geöffnete Kanäle — nicht die Regel.

Auth-Methode: PHS vs. PTA vs. Federation

Die zweite große Achse ist die Authentifizierungsmethode: Wo wird das Passwort eines Hybrid-Nutzers eigentlich geprüft? Es gibt drei Grundmuster, und die Wahl bestimmt sowohl das Ausfallverhalten als auch die Angriffsfläche.

Password Hash Sync (PHS)

Ein Hash des Passworts wird nach Entra ID synchronisiert; die Prüfung passiert in der Cloud. Einfachste und widerstandsfähigste Variante — Anmeldungen funktionieren weiter, auch wenn das on-prem AD gerade nicht erreichbar ist. Kehrseite: Kontosperren oder Passwort-Policy-Änderungen wirken erst mit dem nächsten Sync-Zyklus, nicht in Echtzeit.

Pass-through Authentication (PTA)

Kein Passwort-Hash in der Cloud; die Anfrage kommt in die Cloud, wird aber über leichtgewichtige on-prem Agents in Echtzeit gegen das AD geprüft. Kehrseite: hängt an der Verfügbarkeit von on-prem AD und Agents — fallen sie aus, schlägt die Anmeldung fehl. PHS kann als geplanter Notfallweg vorbereitet sein, ist aber kein automatischer PTA-Failover.

Federation (AD FS)

Ein on-prem Identity Provider (typisch AD FS) authentifiziert und stellt signierte SAML-Token aus, denen Entra vertraut. Erlaubt komplexe Szenarien (z. B. Smartcard, on-prem-Bedingungen). Kehrseite: schwerste zu betreibende Variante, macht den IdP zu einer großen Tier-0-Angriffsfläche (siehe Golden SAML) und hängt an dessen Verfügbarkeit.

Die evergreen Leitlinie: Bevorzuge Cloud-Authentifizierung (PHS), außer eine konkrete Anforderung erzwingt PTA oder Federation. PHS ist am einfachsten, am robustesten gegen on-prem-Ausfälle und aktiviert obendrein die Erkennung geleakter Anmeldedaten in der Cloud. PTA und Federation kaufen Kontrolle mit zusätzlichen beweglichen Teilen und einer größeren on-prem-Abhängigkeit.

Was Password Hash Sync ist — und was nicht

Um PHS ranken sich hartnäckige Mythen („Microsoft bekommt unsere Klartext-Passwörter“). Technisch stimmt das nicht. PHS synchronisiert weder das Passwort noch den verwertbaren NT-Hash, sondern einen Hash des Hashes:

• Der on-prem NT-Hash (MD4) des Passworts wird mit einem benutzerindividuellen Salt versehen.
• Dieses Ergebnis läuft durch PBKDF2 mit HMAC-SHA256 über 1000 Iterationen zu einem 32-Byte-Hash.
• Nur dieser Hash (samt Salt und Iterationszahl) geht per TLS an Entra ID. Der ursprüngliche NT-Hash verlässt die Domäne nie.

Folge: Der in Entra gespeicherte Wert lässt sich nicht zurückrechnen und nicht für Pass-the-Hash gegen das on-prem AD verwenden — er ist sogar besser geschützt als der Hash im AD selbst. PHS ist damit die konservativere, nicht die riskantere Wahl.

Seamless SSO und das AZUREADSSOACC$-Konto

Seamless SSO (Desktop-SSO) meldet domänengejointe Rechner ohne erneute Passworteingabe an der Cloud an. Dafür legt die Einrichtung ein Computerkonto `AZUREADSSOACC$` im on-prem AD an, dessen Kerberos-Entschlüsselungsschlüssel mit Entra ID geteilt wird. Dieses Konto ist die kryptografische Brücke, über die Entra on-prem ausgestellten Kerberos-Tickets vertraut.

Das Risiko: Wer den Schlüssel bzw. Hash von AZUREADSSOACC$ erbeutet, kann Kerberos-Tickets fälschen (ein Silver-Ticket-Muster) und sich damit als beliebiger Nutzer an der Cloud anmelden — ohne gültige on-prem-Credentials. Verschärfend: Der Schlüssel dieses Kontos rotiert nicht automatisch. Microsoft empfiehlt, ihn regelmäßig (etwa alle 30 Tage) zu rollieren — analog zum krbtgt-Konto.

Sync-Scoping: Tier-0 gehört nicht in die Cloud

Standardmäßig würde Entra Connect breit synchronisieren. Sync-Scoping grenzt bewusst ein, welche Objekte fließen — meist per OU-Filtering (nur ausgewählte Organisationseinheiten) oder Gruppen-/Attribut-Filter. Das ist keine Kosmetik, sondern eine Sicherheitsentscheidung.

Die harte Regel: Synchronisiere keine on-prem Tier-0-Konten (Domain Admins, Enterprise Admins, andere privilegierte AD-Konten) nach Entra ID. Jedes synchronisierte privilegierte Konto vergrößert die Fläche, über die eine Cloud-Kompromittierung on-prem greift — und umgekehrt. Ebenso gilt die Umkehrung: Cloud-Administratoren sollten reine Cloud-Konten sein (nicht aus dem on-prem AD synchronisiert), damit eine on-prem-Kompromittierung nicht direkt die Cloud-Adminebene mitnimmt.

Der Entra-Connect-Server ist Tier-0

Der Server, auf dem Entra Connect läuft, ist kein gewöhnlicher Member-Server — er ist Tier-0, auf derselben Schutzstufe wie ein Domain Controller. Der Grund liegt in den Rechten, die die Synchronisation braucht:

• Für PHS besitzt das AD-Connector-Konto die Verzeichnisrechte `Replicating Directory Changes` und `Replicating Directory Changes All` — exakt die Rechte, die ein DCSync-Angriff missbraucht. Wer den Server oder dieses Konto kontrolliert, kann die Passwort-Hashes der gesamten Domäne abziehen.
• Der Server kennt bei Federation-nahen Szenarien und Seamless SSO sensible Schlüssel bzw. deren Handhabung.
• Kompromittierung des Connect-Servers = faktisch Domänen-Kompromittierung.

Daraus folgt für den Sync-Account: Least Privilege statt Bequemlichkeit. Ihm die Rolle Domain Admin oder Enterprise Admin zu geben, „damit es einfach läuft“, ist ein klassischer, schwerer Fehler — er braucht nur die spezifischen, delegierten Rechte der aktivierten Features. Doch selbst diese minimalen Rechte (DirSync-Replikation) machen ihn Tier-0. Der Server gehört daher gehärtet, von einer PAW administriert und nicht in eine niedrigere Tier-Ebene gejoint oder verwaltet.

Federation-Risiko: Golden SAML

Wer Federation (AD FS) einsetzt, macht den on-prem IdP zum Trust-Anchor der Cloud-Anmeldung. AD FS signiert die SAML-Token mit einem privaten Token-Signing-Zertifikat. Genau hier setzt Golden SAML an: Stiehlt ein Angreifer den privaten Schlüssel dieses Signaturzertifikats, kann er beliebige SAML-Token selbst signieren — für jeden Nutzer, inklusive Administratoren.

Weil diese Token kryptografisch gültig aussehen, verlässt sich die betroffene Relying Party auf eine kompromittierte Signaturkette statt auf das Passwort des Nutzers. Ob und wie zusätzliche Cloud-Policies den Zugriff noch begrenzen, hängt vom konkreten Trust- und App-Design ab; ein Passwort-Reset oder MFA-Neuregistrierung entwertet den gestohlenen Signaturschlüssel jedoch nicht. Ein krbtgt-Reset ist ebenfalls wirkungslos, denn die Trust-Kette läuft über das AD-FS-Zertifikat, nicht über Kerberos.

Source Anchor / immutableID: Hard- vs. Soft-Match

Damit ein on-prem Objekt dauerhaft mit seinem Cloud-Objekt verknüpft bleibt, braucht es eine stabile Klammer: den Source Anchor. In Entra ID heißt dessen Wert `immutableID`. Er muss unveränderlich und eindeutig sein — ändert er sich, bricht die Bindung, und es entstehen doppelte oder verwaiste Cloud-Objekte.

Deshalb ist der Standard-Anchor moderner Entra-Connect-Installationen `msDS-ConsistencyGuid` (typischerweise mit dem objectGUID befüllt) — ein Wert, der auch eine spätere Migration zwischen Forests überlebt. Ein veränderliches Attribut wie E-Mail-Adresse oder UPN als Anchor zu wählen ist ein Anti-Pattern: Sobald es sich ändert, reißt die Verknüpfung.

Hard-Match

Verknüpfung über den Source Anchor (immutableID). Die explizite, kontrollierte Bindung — Entra findet das zugehörige Objekt eindeutig über den unveränderlichen Wert.

Soft-Match

Findet Entra kein Objekt mit passender immutableID, versucht es, über `userPrincipalName` oder die primäre SMTP-Adresse ein bestehendes Cloud-Objekt zu treffen. Praktisch beim erstmaligen Verbinden bestehender Cloud-Konten — aber es matcht auf veränderliche Attribute und kann so das falsche Objekt treffen.

Was on-prem bleibt, wenn die Cloud ausfällt — und umgekehrt

Die Wahl der Anmeldemethode ist zugleich eine Entscheidung über Ausfallverhalten, und die wird beim Entwurf regelmäßig übersehen, weil sie erst im Ernstfall sichtbar wird.

Anmeldung in der Cloud

Die Cloud prüft selbst. Fällt die lokale Anbindung aus, melden sich Nutzer an Cloud-Diensten weiter an — die Synchronisierung steht still, aber niemand ist ausgesperrt.

Durchgereichte Anmeldung

Jede Anmeldung braucht einen erreichbaren lokalen Agenten. Fällt die Anbindung aus, ist die Anmeldung an Cloud-Diensten nicht mehr möglich — auch für Nutzer, die mit dem lokalen Netz gar nichts zu tun haben.

Föderation

Die Anmeldung läuft über einen lokalen Dienst. Dessen Verfügbarkeit ist damit die Verfügbarkeit sämtlicher Cloud-Anmeldungen — inklusive aller Abhängigkeiten dieses Dienstes.

Durchgerechnet: Was gehört überhaupt in den Sync?

Zusammenfassung — gleich im Check

Die Achsen dieses Moduls: Sync-Topologie (Objektfluss, Source of Authority, Password Writeback); die Auth-Methode PHS/PTA/Federation mit ihren Trade-offs und ihrem Ausfallverhalten; was PHS wirklich synchronisiert (Hash des Hashes, kein Klartext, kein Pass-the-Hash); das Seamless-SSO-Konto AZUREADSSOACC$; Sync-Scoping und die Trennung der privilegierten Ebenen; der Connect-Server als Tier-0 samt Rechten des Sync-Accounts; Golden SAML als Trust-Anchor-Kompromittierung; und die Bindung über Source Anchor / immutableID (Hard- vs. Soft-Match).