Hybride Identität: Design-Notizen

Kontext

Hybride Identität entsteht meist nicht aus “Wunsch”, sondern aus Realität: bestehendes On-Prem AD, Legacy Apps, Geräte, Standorte und Compliance. Das Ziel ist, die Hybrid-Komplexität bewusst zu steuern – nicht sie wegzudiskutieren.

Kernentscheidungen

1) Authentifizierung: PHS vs PTA

• Password Hash Sync (PHS) ist operational oft robuster (weniger Abhängigkeiten), weil Anmeldungen nicht live auf On-Prem angewiesen sind.
• Pass-through Authentication (PTA) kann sinnvoll sein, wenn bestimmte Anforderungen es erzwingen, hat aber höhere Betriebsanforderungen (Agent Health, Netzwerkpfade, Outage-Risiko).

Entscheidend ist nicht das Feature, sondern dein Outage-Szenario: Was passiert, wenn On-Prem nicht erreichbar ist?

Praktische Konsequenz: Dokumentiere diese Antwort als Betriebsentscheidung. Viele Hybrid-Setups scheitern im Incident nicht an Technik, sondern daran, dass niemand weiß, welcher Teil gerade “single point of failure” ist.

2) UPN/Domain-Strategie

• Konsistente UPNs reduzieren Support und CA-Komplexität.
• Plane, wie du mit mehreren SMTP/UPN-Suffixen umgehst.

3) Geräteidentität

Für CA-Patterns ist Gerätestatus zentral:

• Hybrid Azure AD Join vs Entra Join
• MDM Enrollment/Compliance-Design
• Admin-Workstations (PAW) als eigenes Konzept

Betriebsrisiken und Guardrails

• Break-Glass Accounts für Entra (unabhängig vom On-Prem AD) sind Pflicht.
• Monitoring für Sync/Connect/Cloud Sync (Health, Errors, Latenzen).
• Dokumentierte Recovery: Was tun bei Sync-Fehlern, Token-Issues, CA-Lockouts?

Zusätzliche Guardrails, die in der Praxis helfen:

• Staging Mode / klarer Change-Prozess für Sync-Änderungen
• Monitoring mit Alarmierung (nicht nur “Health-Status existiert”)
• Regelmäßiger Test des Break-Glass-Pfads (kontrolliert, protokolliert)

Typische Anti-Patterns

• “Hybrid” ohne Ownership: niemand fühlt sich zuständig für den End-to-End Flow.
• CA-Policies ohne Verständnis von Geräte-/Join-Status.
• PTA ohne sauberes High Availability-Design.