Entra Connect im Detail: Sync-Architektur und Troubleshooting

Was Entra Connect eigentlich tut

Wenn du im Alltag ueber “Entra Connect” sprichst, meinst du meistens die ganze Kette vom lokalen Active Directory bis zum Benutzerobjekt in Microsoft Entra ID. Technisch steckt dahinter eine kleine Pipeline mit drei Stationen:

1. Import – der Active-Directory-Connector liest Objekte aus deiner Domaene in den sogenannten Connector Space (eine lokale Kopie der AD-Attribute, kein Live-Zugriff bei jedem Sync).
2. Synchronisation – die Metaverse genannte zentrale Datenbank fuehrt die Objekte aus allen Connectoren zusammen, wendet Sync Rules an und berechnet, was am Ende bei Entra ID ankommen soll.
3. Export – der Entra-ID-Connector schreibt die berechneten Attribute per Microsoft-Graph-API-Aufrufe in den Tenant.

Der eigentliche Sync-Dienst heisst im Hintergrund immer noch miiserver.exe (Erbe aus dem Forefront Identity Manager / MIM-Stammbaum) und laeuft als Windows-Dienst “Microsoft Azure AD Sync” bzw. neuerdings “Microsoft Entra Connect Sync”. Diese Herkunft erklaert, warum die Konzepte Connector Space, Metaverse und Sync Rules eins zu eins aus der MIM-Welt uebernommen wurden – wer schon mal mit Identity Manager gearbeitet hat, fuehlt sich hier sofort zuhause.

Sync-Topologien: Express vs. Custom

Beim Setup fragt dich der Installer als Erstes, ob du Express Settings oder Custom Settings willst. Das ist keine kosmetische Wahl, sondern legt die gesamte spaetere Architektur fest.

In der Praxis bei Schweizer KMU triffst du Express fast nur bei Neuinstallationen mit exakt einer Domaene und ohne Altlasten an. Sobald du eine zweite Domaene, eine Exchange-Hybrid-Migration, gesperrte Service-Accounts oder unterschiedliche UPN-Suffixe hast, fuehrt kein Weg an Custom Settings vorbei.

Bei Multi-Forest-Szenarien gilt eine wichtige Grundregel: Ein einzelner Entra-Connect-Server kann mehrere Forests bedienen, solange er alle Forests per Netzwerk erreicht und mindestens einer Domaene innerhalb dieser Forests beigetreten ist. Es ist explizit nicht unterstuetzt, zwei unabhaengige Entra-Connect-Server aktiv gegen denselben Tenant exportieren zu lassen – das fuehrt zu Duplikaten und widerspruechlichen Attribut-Updates.

Password Hash Sync, Pass-Through Authentication oder Federation?

Die Wahl der Anmeldemethode ist die wichtigste Architekturentscheidung im ganzen Hybrid-Setup. Alle drei Verfahren laufen technisch ueber Entra Connect, unterscheiden sich aber massiv in Abhaengigkeiten und Ausfallverhalten.

Microsofts eigene Empfehlung ist unmissverstaendlich: Password Hash Sync ist die Standardwahl, ausser es gibt einen konkreten Grund dagegen. Und selbst wenn du PTA oder Federation einsetzt, solltest du PHS zusaetzlich als Backup-Authentifizierungsmethode aktivieren – dann kann Entra ID bei einem kompletten On-Prem-Ausfall auf die zuletzt synchronisierten Hashes zurueckfallen. Wichtig: Dieser Failover passiert nicht automatisch. PTA faellt bei Ausfall aller Agenten nicht von selbst auf PHS zurueck – du musst im Entra Connect Assistenten unter “Zusaetzliche Aufgaben” bewusst umschalten.

Aktivierst du PHS als Backup, geschieht das nicht per PowerShell-Cmdlet gegen den Tenant, sondern lokal am Entra-Connect-Server: Im Installationsassistenten unter “Zusaetzliche Aufgaben” -> “Benutzeranmeldung aendern” die Option “Password Hash Synchronization” zusaetzlich aktivieren, ohne die primaere Methode (PTA oder Federation) zu aendern. Danach kannst du im Ernstfall ueber denselben Assistenten die primaere Anmeldemethode auf PHS umstellen. Ob PHS bereits als Backup laeuft, pruefst du direkt am Sync-Server:

# Pruefen, ob Password Hash Sync aktuell aktiviert ist (unabhaengig von PTA/Federation)
Get-ADSyncAADCompanyFeature | Select-Object PasswordHashSync

# Aktuellen Scheduler- und Sync-Status abrufen, um Sync-Aktivitaet zu bestaetigen
Get-ADSyncScheduler

Filtering und OU-Scoping

Nicht jedes Objekt in deinem AD soll in der Cloud landen – Service-Accounts, Testkonten oder Objekte aus einer stillgelegten Zweigstelle gehoeren typischerweise nicht in Entra ID. Entra Connect kennt dafuer drei Filterebenen, die in dieser Reihenfolge ausgewertet werden:

1. Domain-based Filtering – ganze Domaenen aus dem Forest komplett ausschliessen.
2. OU-based Filtering – einzelne Organisationseinheiten pro Domaene ein- oder ausschliessen (basiert auf dem DistinguishedName der OU).
3. Group-based Filtering – nur Mitglieder einer bestimmten Sicherheitsgruppe synchronisieren (praktisch fuer Pilotphasen).
4. Attribute-based Filtering – ueber Custom Sync Rules gezielt einzelne Objekte anhand eines Attributwerts ausschliessen (z. B. extensionAttribute15 = "NoSync").

Wichtig fuer die Praxis: Wenn du Gruppen-basierte Filterung nutzt, muss die OU, in der sich die Filter-Gruppe selbst befindet, ebenfalls im Scope sein – OU-Filterung wird vor der Gruppenfilterung ausgewertet und kann sie sonst komplett aushebeln.

Ein haeufiges KMU-Szenario: Ihr habt eine OU OU=ServiceAccounts,DC=kmu,DC=ch mit technischen Konten, die nie in der Cloud auftauchen sollen. Statt die ganze OU per Installer-Filter auszuschliessen (was bei jeder Struktur-Aenderung bricht), ist eine attributbasierte Sync Rule robuster:

Bedingung (Scoping Filter) in der Synchronization Rules Editor:
  extensionAttribute15 EQUALS "NoSync"
  -> Aktion: Objekt wird nicht in den Metaverse uebernommen (Out-of-scope)

Attribute-Mapping und Custom Sync Rules

Die Out-of-the-Box-Regeln decken den Standardfall gut ab: sAMAccountName zu mailNickname, userPrincipalName zu userPrincipalName, proxyAddresses fuer Exchange und so weiter. Sobald du aber eigene Anforderungen hast – zum Beispiel ein firmenspezifisches Attribut fuer Kostenstellen, eine abweichende UPN-Berechnung oder das Zusammensetzen des Anzeigenamens aus mehreren AD-Feldern – brauchst du Custom Sync Rules.

Die goldene Regel dabei: Nie die Standardregeln direkt bearbeiten. Jedes Update von Entra Connect ueberschreibt die Default-Regeln kommentarlos. Stattdessen klonst du die betroffene Regel, deaktivierst im Klon alle Attribute ausser dem einen, das du aendern willst, und vergibst eine niedrigere Precedence (Standardregeln starten bei 100 – ein Wert von 90 gewinnt bei einem Konflikt).

Ablauf fuer eine Custom Sync Rule (Synchronization Rules Editor):
1. Regel "Out to AAD - User Join" oeffnen -> "Edit" klicken
2. Editor klont die Regel automatisch und deaktiviert das Original NICHT
3. Im Klon: alle Attribut-Zuordnungen entfernen ausser der einen, die du anpasst
4. Precedence auf einen Wert kleiner als 100 setzen, z. B. 95
5. Scoping Filter setzen, falls die Regel nur fuer bestimmte Objekte gelten soll
6. Speichern -> Full Synchronization ausloesen, damit die Regel greift

Ein reales Beispiel: Ihr wollt, dass der Anzeigename in Entra ID immer als “Nachname, Vorname” statt “Vorname Nachname” erscheint. Die Expression-Sprache im Sync Rules Editor erlaubt das direkt:

Zieldattribut: displayName
Ausdruck:      Trim(IIF(IsPresent([sn]), [sn] & ", " & [givenName], [givenName]))

Oder ein Fall aus dem SQL-/ERP-Umfeld: Die Personalnummer aus einem Custom-AD-Attribut soll als employeeId in Entra ID landen, aber nur wenn sie numerisch und nicht leer ist:

Zieldattribut: employeeId
Ausdruck:      IIF(IsPresent([employeeNumber]) && IsNumeric(Trim([employeeNumber])), Trim([employeeNumber]), Error("Ungueltige Personalnummer"))

Falls du aus Versehen eine Standardregel direkt veraendert hast (kommt vor, wenn jemand im Editor auf die falsche Regel klickt), erkennst du das ab Entra-Connect-Version 1.3.7.0 sofort im Synchronization Rules Editor: Modifizierte Standardregeln zeigen ein Warnsymbol vor dem Namen, und daneben erscheint zusaetzlich die deaktivierte Original-Standardregel. Der korrekte Reparaturweg ist rein GUI-basiert: Die veraenderte Regel loeschen, die zugehoerige Original-Standardregel wieder aktivieren, deine gewuenschte Anpassung stattdessen als eigene geklonte Regel mit eigener Precedence nachbauen, und danach einen vollen Sync-Zyklus ausloesen. Vor jeder solchen Aenderung lohnt es sich, den Scheduler kurz zu pausieren:

Set-ADSyncScheduler -SyncCycleEnabled $false

Staging Mode und Failover-Server

Staging Mode ist der wichtigste Baustein fuer Change-Management und Disaster Recovery bei Entra Connect. Ein Server im Staging Mode fuehrt Import und Synchronisation ganz normal durch, exportiert aber nichts – weder zu Entra ID noch (bei Passwort-Aenderungen) zurueck ins AD. Du siehst also exakt, was passieren wuerde, ohne produktive Auswirkung.

Typische Einsatzzwecke:

• Testen von Konfigurationsaenderungen: Neue Custom Sync Rule zuerst auf dem Staging-Server pruefen, bevor sie live geht.
• Zweiter Server fuer Hochverfuegbarkeit / DR: Ein baugleicher Server steht bereit und kann bei Ausfall des Primary-Servers innerhalb von Minuten aktiviert werden.
• Versions-Upgrades: Den neuen Server erst im Staging Mode installieren, konfigurieren und validieren, dann umschalten.

# Aktuellen Status pruefen
Get-ADSyncScheduler | Select-Object StagingModeEnabled, SyncCycleEnabled

# Manuellen Sync-Zyklus auf dem Staging-Server anstossen, um Ergebnisse zu pruefen
Start-ADSyncSyncCycle -PolicyType Delta

Den Staging Mode selbst schaltest du nicht per Cmdlet um, sondern ueber den Installationsassistenten (Zusaetzliche Aufgaben → Staging-Modus konfigurieren). Das ist bewusst so gebaut, damit die Umschaltung nicht versehentlich per Skript passiert.

Ablauf fuer einen sauberen Failover:

1. Sicherstellen, dass der Staging-Server exakt dieselbe Konfiguration hat wie der Primary (Export/Import der Konfiguration ueber AzureADConnect.exe /? bzw. den offiziellen Konfigurations-Export im Assistenten).
2. Primary-Server stoppen oder vom Netz trennen, damit er unter keinen Umstaenden noch exportieren kann.
3. Auf dem Staging-Server im Assistenten Staging-Modus deaktivieren waehlen und “Synchronisierung sofort starten” ankreuzen.
4. Ersten Delta-Sync beobachten (Synchronization Service Manager, siehe naechster Abschnitt).

Ein oft uebersehener Punkt: Passwort-Synchronisation arbeitet mit einem Watermark (Zeitstempel des letzten verarbeiteten Passwort-Events). War der Staging-Server lange inaktiv, kann das Nachholen aller in der Zwischenzeit geaenderten Passwoerter nach der Aktivierung mehrere Stunden dauern – in dieser Zeit funktionieren frisch geaenderte Passwoerter in der Cloud noch nicht.

Troubleshooting mit dem Synchronization Service Manager

Das zentrale Debugging-Werkzeug ist miisclient.exe, standardmaessig unter C:\Program Files\Microsoft Azure AD Sync\UIShell\miisclient.exe. Es hat zwei wichtige Reiter:

• Operations: Historie aller Import-/Sync-/Export-Laeufe pro Connector, inklusive Fehlerzahl je Lauf.
• Connectors: Erlaubt das direkte Durchsuchen des Connector Space (z. B. “finde das AD-Objekt fuer m.mueller”) und das Nachvollziehen der Attribut-Fluesse bis in die Metaverse und weiter zu Entra ID.

Typischer Debugging-Ablauf, wenn ein Attribut nicht ankommt:

1. Im AD-Connector nach dem Objekt suchen (Distinguished Name oder sAMAccountName).
2. Pruefen, ob das Attribut im Connector Space ueberhaupt den erwarteten Wert hat (Import-Problem vs. Sync-Problem unterscheiden).
3. Rechtsklick → Preview → Full Synchronization, um zu sehen, welche Sync Rules greifen und welchen Wert sie in die Metaverse schreiben.
4. Vom Metaverse-Objekt aus per Export Attribute Flow in Richtung Entra-ID-Connector weiterverfolgen.

# Aktuellen Status aller Connectoren abfragen
Get-ADSyncConnectorRunStatus

# Gezielt ein Objekt im Connector Space suchen (per DN)
Get-ADSyncCSObject -ConnectorName "kmu.ch" -DistinguishedName "CN=Max Muster,OU=IT,DC=kmu,DC=ch"

# Passwort-Sync fuer ein einzelnes Objekt gezielt diagnostizieren (ADSyncDiagnostics-Modul)
Invoke-ADSyncDiagnostics -PasswordSync -ADConnectorName "kmu.ch" -DistinguishedName "CN=Max Muster,OU=IT,DC=kmu,DC=ch"

Die haeufigsten Fehlerbilder in der Praxis:

Sicherheit und Best Practices im KMU-Kontext

Entra Connect ist aus Sicherheitssicht ein hochsensibler Server: Wer den AD-DS-Connector-Account kompromittiert, kann im schlimmsten Fall Passwort-Hashes abziehen oder ueber DCSync-aehnliche Rechte eskalieren. Ein paar Punkte, die in der Praxis regelmaessig uebersehen werden:

• Least Privilege fuer das Connector-Konto: Nach der Installation kannst du die initial recht weitreichenden AD-Rechte des Sync-Kontos gezielt einschraenken.

Import-Module "C:\Program Files\Microsoft Azure AD Sync\Bin\ADSyncConfig\ADSyncConfig.psm1"
$cred = Get-Credential   # Enterprise- oder Domain-Admin-Konto
Set-ADSyncRestrictedPermissions -ADConnectorAccountDN "CN=svc-entraconnect,OU=ServiceAccounts,DC=kmu,DC=ch" -Credential $cred

• Tier-Modell beachten: Der Entra-Connect-Server gehoert logisch auf Tier 0, weil er ueber Passwort-Hash-Sync faktisch Zugriff auf alle synchronisierten Konten hat. Er darf nicht von Tier-1- oder Tier-2-Admins verwaltet werden und braucht dieselbe Haertung wie ein Domain Controller.
• Staging-Server aktiv pflegen: Ein Staging-Server, der nie aktualisiert wird, ist im Ernstfall nutzlos, weil seine Konfiguration vom Primary abgedriftet ist. Konfigurationsexport regelmaessig synchron halten.
• Backup des Verschluesselungskeys: Entra Connect verschluesselt sensible Konfigurationsdaten mit einem lokalen Schluessel. Ohne Backup dieses Schluessels (Export ueber den Installationsassistenten) ist eine Wiederherstellung nach einem Server-Totalausfall deutlich aufwendiger.

Entscheidungsbaum: Welche Konfiguration passt?

Nur eine Domaene, keine Filterung noetig, PHS reicht?
  -> JA:  Express Settings
  -> NEIN: Custom Settings
       |
       +-- Regulatorische Vorgabe / Smartcard / bestehender SAML-Verbund?
       |     -> JA:  Federation (AD FS) + PHS als Backup
       |     -> NEIN weiter
       |
       +-- On-Prem-Kontosperren/-Ablauf muessen sofort greifen?
       |     -> JA:  Pass-Through Authentication + PHS als Backup
       |     -> NEIN: Password Hash Sync
       |
       +-- Mehrere Forests, Sonder-Attribute, Exchange Hybrid?
             -> Custom Sync Rules + OU-/Gruppen-Filterung
             -> Staging-Server fuer DR und Change-Testing einplanen

Wenn du dir bei der Wahl unsicher bist: Starte mit PHS und Custom Settings, aktiviere Filterung nur dort, wo wirklich noetig, und baue erst danach komplexere Sync Rules ein. Jede zusaetzliche Custom-Regel ist eine zusaetzliche Fehlerquelle bei jedem zukuenftigen Upgrade – Einfachheit gewinnt hier fast immer gegen theoretische Eleganz.

Weiterlernen

• Microsoft Entra Connect: Supported topologies – offizielle Uebersicht aller unterstuetzten Topologien
• Authentication for Microsoft Entra hybrid identity solutions – Entscheidungsgrundlage PHS/PTA/Federation
• Microsoft Entra Connect Sync: Configure filtering – Domain-, OU- und Gruppenfilterung im Detail
• How to customize a synchronization rule – Custom Sync Rules Schritt fuer Schritt
• Microsoft Entra Connect: Staging server and disaster recovery – Staging Mode und Failover offiziell erklaert
• Troubleshoot an object that is not syncing – Troubleshooting-Leitfaden fuer den Synchronization Service Manager

Videos

YouTube