# Hybrid Identity (Entra / Entra Connect)

> Der Capstone des AD-Tracks: on-prem Active Directory und Microsoft Entra ID sicher verbinden. Sync-Topologie und Source of Authority, die Auth-Methoden PHS, PTA und Federation mit ihren Trade-offs und ihrem Ausfallverhalten, was Password Hash Sync wirklich synchronisiert, das Risiko des Seamless-SSO-Kontos, Sync-Scoping und warum Tier-0 nie in die Cloud gehört, der Entra-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).

Track: [Active Directory](https://physar.tech/learn/active-directory)  
Kanonische Fassung: https://physar.tech/learn/active-directory/hybrid-identity  
Stand: 2026-07-27  
Interaktiver Teil: 14 Checks (nur im Browser)

## Hybrid Identity: Sync-Topologie, Auth-Methoden, die Trust-Grenze on-prem ↔ Cloud

### 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.

> **Merksatz:** Hybrid Identity vergrößert die Angriffsfläche in **beide** Richtungen. Die zentrale Frage ist nicht „wie synce ich?“, sondern „**wer kontrolliert was — und wo fließt eine Kompromittierung hin?**“

### 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.

> **Konsequenz für den Betrieb:** Eine versehentliche Löschung on-prem **propagiert** in die Cloud. Die Trust-Grenze wirkt in Fluss­richtung: Ein Fehler an der Quelle wird zum Fehler im Spiegel.

**Kurzcheck:** Ein Admin ändert im Entra-Portal den Anzeigenamen eines **synchronisierten** Nutzers, doch nach kurzer Zeit steht wieder der alte Wert da. Warum?

- [x] 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.

> **Resilienz-Praxis:** Auch mit PTA oder Federation kann PHS als **geplanter** Notfallweg vorbereitet werden. Prüfe und übe den Umschaltprozess: PTA fällt **nicht automatisch** auf PHS zurück. Ohne eine bewusst vorbereitete Alternative nimmt ein DC- oder Agent-Ausfall die Cloud-Anmeldung gleich mit.

### 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.

> **Trotzdem Tier-0:** „Kein Klartext“ heißt **nicht** „harmlos“. Der Entra-Connect-Server **liest** die on-prem-Hashes aus, um sie zu synchronisieren — dafür braucht er hochprivilegierte Rechte. Der Schutz liegt beim **Server und Sync-Konto**, nicht bei den übertragenen Hashes.

### 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.

> **Prinzip:** `AZUREADSSOACC$` ist ein **Tier-0-Geheimnis für die Cloud**. Behandle es wie `krbtgt`: regelmäßig rotieren, streng schützen — und wenn Seamless SSO nicht wirklich gebraucht wird, ist Abschalten die kleinere Angriffsfläche.

### 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.

> **Merksatz:** Halte die **privilegierten Ebenen getrennt**: on-prem Tier-0 bleibt on-prem, Cloud-Admins bleiben cloud-only. Alles, was diese Trennung aufhebt, koppelt zwei Blast-Radien zu einem.

**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?

- [x] 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.

> **Merksatz:** Behandle den Entra-Connect-Server wie einen Domain Controller. Er ist kein „Sync-Kästchen im Server-VLAN“, sondern hält die Schlüssel zur ganzen Domäne.

### 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.

> **Prinzip (evergreen):** Golden SAML ist eine **Trust-Anchor-Kompromittierung** — dieselbe Klasse wie ein gestohlener CA-Schlüssel. Die Abwehr ist nicht das Nachjagen einzelner Anmeldungen, sondern das **Entwerten des Schlüssels**: Token-Signing-Zertifikat(e) rotieren/widerrufen, Vertrauen neu aufbauen, AD FS als Tier-0 schützen — und wo möglich **weg von Federation** hin zu Cloud-Authentifizierung.

### 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. |

> **Warum das ein Sicherheitsthema ist:** Soft-Match bindet über Attribute, die jemand mit on-prem-Schreibrechten setzen kann. Ein on-prem Objekt mit passendem UPN/SMTP kann so ein bestehendes (auch privilegiertes) Cloud-Konto **an sich binden**. Für sensible Konten daher **kontrollierter Hard-Match** und Verifikation vor dem ersten 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).

> **Gleich im Check:** Du entscheidest für konkrete Situationen die beste Auth-Methode, Reaktion oder Konfiguration — und in einer Sortier-Mission ordnest du zu, welche Kontrolle **on-prem**, welche **in der Cloud** und welche **geteilt** liegt. Jede Option zeigt, warum sie die Trust-Grenze richtig trifft oder aus welchem benannten Grund nicht.

## Quellen

- Microsoft Learn — What is password hash synchronization with Microsoft Entra ID? / Implement password hash synchronization (MD4 + Salt + PBKDF2/HMAC-SHA256, 1000 Iterationen; NT-Hash verlässt on-prem nicht)
- Microsoft Learn — Choose the right authentication method for Microsoft Entra hybrid identity (PHS vs. PTA vs. Federation, Ausfallverhalten, PHS als Backup)
- Microsoft Learn — Microsoft Entra Connect: Design concepts / sourceAnchor, msDS-ConsistencyGuid, immutableID; soft-match vs. hard-match (userPrincipalName/proxyAddresses vs. sourceAnchor)
- Microsoft Learn — Microsoft Entra seamless single sign-on: technical deep dive und Rollover des Kerberos-Entschlüsselungsschlüssels für AZUREADSSOACC$
- Microsoft Learn — Protecting Microsoft 365 from on-premises attacks / Securing privileged access: Entra-Connect-Server als Tier-0, privilegierte Konten nicht synchronisieren
- CyberArk / Mandiant — Golden SAML: Forging SAML tokens via stolen AD FS token-signing certificate (Trust-Anchor-Kompromittierung, umgeht MFA)
- Microsoft Learn — Microsoft Entra Connect design concepts and source of authority
- Microsoft Learn — Microsoft Entra Connect accidental deletion prevention
- Microsoft Learn — sync design concepts
- Microsoft Learn — Implement password hash synchronization
- Microsoft Learn — Microsoft Entra Connect user sign-in options
- Microsoft Learn — password hash synchronization
- Microsoft Learn — Pass-through Authentication FAQ
- Microsoft Learn — PTA technical deep dive
- Microsoft security guidance — federation security
- Microsoft Learn — Microsoft Entra seamless single sign-on technical deep dive
- Microsoft security guidance — protect privileged access in hybrid identity
- Microsoft Learn — Entra Connect filtering
- Microsoft security guidance — securing Microsoft Entra Connect server
- Microsoft Learn — password hash synchronization permissions
- Microsoft Learn — Microsoft Entra Connect permissions
- Microsoft security guidance — AD FS token-signing certificate rollover
- Mandiant — Golden SAML
- Microsoft Learn — Microsoft Entra Connect sourceAnchor and msDS-ConsistencyGuid
- Microsoft Learn — Microsoft Entra Connect matching users
- Microsoft Learn — sourceAnchor design
- Microsoft Learn — Entra Connect design concepts
- Microsoft security guidance — hybrid identity