Hybrid Identity: Sync-Topologie, Auth-Methoden, die Trust-Grenze on-prem ↔ Cloud
Einführung · 10 Abschnitte · ~9 Min Lesezeit · Stand
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.
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.
- On-prem AD (Source of Authority)
- Entra Connect (Sync-Engine)
- Entra ID (Spiegel synchronisierter Objekte)
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.
Kurzcheck
Ein Admin ändert im Entra-Portal den Anzeigenamen eines **synchronisierten** Nutzers, doch nach kurzer Zeit steht wieder der alte Wert da. Warum?
- On-prem AD ist die Source of Authority für synchronisierte Objekte; der nächste Sync-Zyklus überschreibt die Cloud-Änderung mit dem on-prem-Wert.
- Ein Replikationsfehler zwischen zwei Domain Controllern hat die Änderung verworfen.
- Dem Konto fehlt eine Lizenz, deshalb speichert Entra Attributänderungen nicht.
Genau. Synchronisierte Attribute werden on-prem gepflegt — die Cloud ist ihr Spiegel, nicht ihr Eigentümer.
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.
Kurzcheck
Beim Aufsetzen der Synchronisation schlägt jemand vor, „einfach alles zu syncen, auch die Admin-OUs — dann ist nichts vergessen“. Wo ist der Denkfehler?
- Synchronisierte on-prem Tier-0-Konten vergrößern die Cloud-Angriffsfläche und koppeln on-prem- und Cloud-Kompromittierung; privilegierte Konten sollten per Scoping ausgeschlossen bleiben.
- Alles zu syncen ist korrekt; man muss den Admin-Konten danach nur ein sehr langes Passwort geben.
- Der einzige Nachteil ist der höhere Lizenzverbrauch durch mehr synchronisierte Objekte.
Richtig. Vollständigkeit ist hier keine Tugend — jedes synchronisierte Tier-0-Konto ist ein zusätzlicher Pfad zwischen den Ebenen.
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. |
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).