Entra ID Connect verstehen Von FIM-Wurzeln bis zum Metaverse – ein praxisnaher Deep Dive

Wer heute eine hybride Identitätslandschaft betreibt, kommt an Microsoft Entra ID Connect (dem Nachfolger von Azure AD Connect) kaum vorbei. Das Tool sorgt dafür, dass Benutzer, Gruppen und – falls gewünscht – Geräte aus dem lokalen Active Directory zuverlässig in Microsoft Entra ID ankommen, dort konsistent bleiben und wieder zurückgeschrieben werden können, wo es sinnvoll und erlaubt ist. Ich habe das Thema hier aus unterschiedlichen Perspektiven schon mehrfach behandelt. Aufgrund einiger tiefergehenden Fragen im letzten Azure-Hybrid-Workshop, habe ich mich entschlossen, noch mal einen umfassenden Deepdive zu verfassen, allerdings in möglichst kompakter Form unter der Annahme, dass Sie das Tool zumindest rudimentär kennen und benutzen.

Unter der Oberfläche der Software arbeitet eine erwachsene Metaverzeichnis‑Engine: Daten werden aus angebundenen Verzeichnissen importiert, im sogenannten „Metaverse“ zu einer einheitlichen Sicht zusammengeführt und anschließend gemäß Regeln wieder exportiert – in die Cloud oder zurück ins AD. Genau dieses Import → Staging → Abgleich → Export ist der rote Faden, der das System so robust und erklärbar macht. Microsoft dokumentiert diese Architektur seit Jahren sehr detailliert; wer die Begriffe Connector, Connector Space, Metaverse und Attributfluss beherrscht, versteht 90 % aller Fehlerbilder schon beim ersten Blick in den Synchronization Service Manager.

Historische Wurzeln

Historisch wurzelt das Ganze in MIIS/FIM/MIM – also Forefront/Microsoft Identity Manager. Entra ID Connect erbt das Metaverzeichnis‑Prinzip nahezu unverändert: Jedes angebundene System wird über einen „Connector“ gesprochen, dessen „Connector Space“ als Staging‑Tabelle dient. Erst die „Synchronization“ bringt die Daten ins „Metaverse“, wo Join- und Projektionslogik entscheidet, ob ein neues Objekt entsteht oder ein bestehendes angereichert wird.

Der eigentliche Transport der Attribute – inbound wie outbound – passiert ausschließlich im Zuge dieser Synchronisationsläufe. Diese Trennung zwischen

• Import (Quelle → Connector Space)
• Sync (Connector Space ↔ Metaverse)
• und Export (Connector Space → Ziel)

ist nicht nur sauber, sie ist auch die Grundlage für reproduzierbares Troubleshooting.

Welche Funktionen deckt das Tool ab?

Funktional deckt Entra ID Connect alles ab, was man in hybriden Szenarien erwartet: die Synchronisation von Benutzern, Gruppen und Kontakten mit OU‑ und Attributfilterung; Passwort‑Hash‑Synchronisierung (PHS), die alle zwei Minuten Hash‑des‑Hash‑Werte in die Cloud überträgt; Pass‑Through‑Authentication (PTA), die Kennwörter on‑prem validiert; und – wenn benötigt – Federation mit AD FS.

Für Geräte gibt es „Hybrid Azure AD Join“ (HAADJ), damit Windows‑Clients nahtlos in Conditional Access, PRT‑basierte SSO‑Erlebnisse und moderne Verwaltung hineinfinden; optional lässt sich „Device Writeback“ für bestimmte ADFS‑Szenarien aktivieren. Bei all dem gilt: PHS authentifiziert in der Cloud und minimiert Abhängigkeiten, PTA hält die Validierung bewusst on‑prem, ADFS bietet maximale Token‑/Claim‑Kontrolle zum Preis zusätzlicher Infrastruktur.

Hinter den Kulissen

Technisch sitzt unter Entra ID Connect eine SQL‑Datenbank namens „ADSync“. Im Standard kommt eine SQL Server Express LocalDB mit, die für kleine bis mittlere Umfänge reicht; wer größer plant oder strikte DBA‑Vorgaben hat, nutzt eine vollwertige SQL‑Instanz – lokal oder remote. Seit Version 1.1.613.0 kann eine bestehende ADSync‑Datenbank wiederverwendet werden, was Wiederanläufe und DR‑Szenarien erheblich vereinfacht.

Zu den beteiligten Konten gehören das „AD DS Connector‑Konto“ (mit granularen Rechten statt Domain Admin), das „ADSync“‑Dienstkonto (lokaler Dienst, häufig als vSA/gMSA) und das Entra Connector‑Konto in der Cloud. Microsoft liefert mit dem „ADSyncConfig“‑Modul Cmdlets aus, die die exakten AD‑Berechtigungen für PHS, Password‑/Group‑/Device‑Writeback und ms-DS-ConsistencyGuid setzen – ein Muss, wenn man ein eigenes Servicekonto statt des automatisch erzeugten MSOL‑Kontos nutzt.

Der Synchronization Manager

Der „Synchronization Service Manager“ ist das Fenster in die Engine. In Tab „Operations“ sieht man jeden Lauf, von Delta Import/Sync bis Export, inklusive Status wie success, completed‑…‑errors oder stopped‑…. In „Connectors“ lassen sich Run‑Profiles starten und der „Connector Space“ durchsuchen.

Der Kniff beim Troubleshooting: Zuerst den betroffenen Lauf in Operations öffnen, dann im Connector Space ein Beispielobjekt mit Preview untersuchen – zeigt die Engine „will be projected“ oder „will join“, ist die Logik intakt; sieht man „scope‑filtered“ oder gar nichts, blockiert eine Regel oder der OU‑Scope. Im Zweifel hilft der Schritt ins Metaverse: Gibt es das Objekt? Wie sehen die verbundenen Connectoren aus? Diese Microsoft‑Route (Operations → CS → MV) wirkt erstaunlich oft; sie erklärt auch, warum „Import ok, aber Export passiert nicht“ nur die halbe Wahrheit ist – meistens scheitert die Projection/Join Stufe, nicht der Export.

Staging Modus

Aus der Praxis verschwinden viele Bauchschmerzen mit drei Prinzipien:

Erstens ein Staging‑Mode‑Server als kalte Reserve und Testbett. Er importiert und synchronisiert, exportiert aber nicht – ideal, um Regeländerungen und große OU‑Umbauten vorab zu validieren. Umschalten bedeutet im Kern: Staging auf dem Zweitserver aus, auf dem Primärserver an – oder umgekehrt.

Zweitens konsequente Least‑Privilege‑Berechtigungen für das AD‑Konto; die Cmdlets im ADSyncConfig‑Modul sind dabei Gold wert.

Drittens das Verständnis der „Profile“:

• Full Import füllt nur den Connector Space,
• Full Sync rechnet alles gegen das Metaverse durch,
• während Delta‑Varianten sich auf geänderte Objekte beschränken.

So wird klar, weshalb man nach Filter‑ oder Regeländerungen einen Initial‑Sync (Full Import + Full Sync) einplant, vor dem Export aber unbedingt auf dem Staging‑Server prüft, ob die Auswirkung korrekt ist.

Vergleich zu Entra Cloud Sync ?

Bekanntlich gibt es seit dem Jahr 2021 einen zweiten Synchronisation-Dienst, dessen Logik im Unterschied zu Entra ID Connect vollständig in der Cloud läuft. „Entra Cloud Sync“ wurde ursprünglich unter dem früheren Namen „Azure AD Cloud Sync“ eingeführt, bevor Microsoft 2023 Azure AD in Microsoft Entra ID umbenannt hat. Die Technologie basiert auf dem „Microsoft Entra Cloud Provisioning Agent“, der 2021 erstmals bereitgestellt wurde und sich deutlich von Azure AD Connect unterscheidet (leichtgewichtiger Agent, cloudseitige Steuerung).

Cloud Sync verlegt also die komplette die Orchestrierung in Microsofts Dienst: On‑prem bleibt nur ein leichtgewichtiger Agent, von dem man gleich mehrere für Hochverfügbarkeit ausrollen kann. Die Konfiguration liegt in der Cloud, Updates kommen automatisch.

Für viele Standardfälle – insbesondere mehrere, auch getrennte Forests – ist das die charmanteste Lösung. Wichtig und ein häufiger Showstopper ist allerdings die Einschränkung, dass Geräte nicht synchronisiert werden, sodass Hybrid Join dann weiterhin über Entra Connect laufen muss. Umgekehrt glänzt Cloud Sync mit einfacher HA und geringem Footprint, während Connect mit Metaverse‑Power, Gerätesync und ADFS‑Anbindung punktet. Folgende Tabelle destilliert die wichtigsten Unterschiede:

Authentifizierungsmethoden

Zum Schluss ein Blick auf Authentifizierung. Zur Verfügung stehen …

• PHS (Password Hash Synchronisation) – Default
• PTA (Passthrough Authentication)
• ADFS (Active Directory Federation Services)

PHS ist simpel, ausfallsicher gegenüber On‑Prem‑Störungen und in vielen Umgebungen „der Standard“. PTA ist die richtige Wahl, wenn Compliance fordert, dass Passwörter stets on‑prem validiert werden – der Preis ist die Abhängigkeit von Agent und DC‑Erreichbarkeit. ADFS bleibt die Königsdisziplin, wenn man erweiterte Token‑/Claim‑Szenarien oder komplexe Partner‑Föderationen braucht – dann aber bitte mit HA‑Design und sauberem Zertifikats‑Lifecycle. Das Schöne: Entra Connect unterstützt alle drei Optionen, die man je nach Phase oder Domänen‑Subset sogar im Staged Rollout.

ADFS – lohnt sich das noch, und was spricht wirklich dafür?

ADFS schreckt viele Unternehmen ab, weil ein Setup – sofern man den Beste Practises von Microsoft folgt – relativ komplex ist. Schon Standard‑Design setzt AD FS‑Server intern und WAP (Web Application Proxy) in der DMZ/Extranet voraus, und zwar „extern“ über HTTPS/443 erreichbar, intern TLS zum AD FS‑Farm‑VIP; dazu saubere Zertifikatsführung und Härtung. Microsofts Best‑Practices und Requirements führen diese Topologie explizit an und listen die notwendigen Sicherheits‑/Netzwerkrahmenbedingungen.

Gründe, die 2026 noch explizit für ADFS sprechen sind vor allem:

• Anspruchs‑/Token‑Feingranularität für SAML/OIDC‑Relying Parties, die Entra so nicht (oder nur mit Umwegen) abbildet; inkl. komplexer Transformationsregeln und Spezial‑Claims.
• On‑prem‑gebundene Authentifizierung: Policies, Smartcards/Zertifikate, kundeneigene MFA‑Server oder Integrationen, die eine lokale IdP‑Kontrolle verlangen.
• Partner‑/Mehrmandanten‑Föderation jenseits von Microsoft‑SaaS, wenn Dritt‑Services spezifische ADFS‑Endpunkte/Claims fordern.
• Strikte Compliance („Passwortvalidierung darf das Datacenter nicht verlassen“), die über PTA hinausgeht und volle IdP‑Souveränität fordert.

Dem stehen Aufwand und Risiko gegenüber: DMZ‑Bereitstellung mit WAP, Zertifikats‑Lebenszyklus, Load‑Balancing, Patching/Härtung und die Absicherung der notwendigen Ports/Protokolle (extern i. d. R. 443; intern zusätzlich Directory‑/Kerberos‑/RPC‑Kommunikation je nach Design).

Für reine Microsoft‑365/Standard‑Cloudlogins gewinnen heute meist PHS oder PTA (einfacher, resilienter). ADFS ist dann sinnvoll, wenn Claims‑/Protokoll‑Sonderwünsche oder on‑prem Zwangsbedingungen es erfordern.

Folgendes Diagramm visualisiert  abschließend die empfohlene Troubleshooting‑Route: Operations → Connector Space (Preview) → Metaverse Search. Das  hilft, Scope‑Filter/Join/Projection klar zu verorten.

Dieses Diagramm hilft bei der Fehlersuche.