Ausgangslage: Ein Sync-Server verbindet zwei Identitätswelten

Microsoft Entra Connect wird im Betrieb leicht als Infrastruktur-Helfer eingeordnet: ein Windows Server, ein Synchronisationsdienst, alle 30 Minuten ein Lauf. Tatsächlich steht das System an einer der kritischsten Vertrauensgrenzen der Umgebung. Es liest Identitätsdaten aus Active Directory, schreibt Objekte und Attribute nach Microsoft Entra ID und kann – abhängig von den aktivierten Funktionen – Passworthashes, Geräte, Gruppen oder Kennwortänderungen verarbeiten.

Für diese Aufgaben nutzt Entra Connect mehrere Identitäten: ein AD-DS-Connector-Konto, das ADSync-Dienstkonto und eine Connector-Identität in Entra ID beziehungsweise bei aktuellen Installationen eine anwendungsbasierte Identität. Die benötigten Rechte unterscheiden sich deutlich. Reine Verzeichnissynchronisation braucht weniger als Password Hash Synchronization, Password Writeback oder weitere Writeback-Funktionen.

Der Server speichert Connector-Konfiguration und geschützte Zugangsdaten in seiner Synchronisationsdatenbank. Die Verschlüsselung verhindert kein Risiko durch einen lokalen Administrator, der Dienst, Datenbank und Host kontrolliert. Wer den Entra-Connect-Server administriert, sitzt deshalb nicht auf einem normalen Member Server, sondern an der Brücke zwischen lokaler und cloudbasierter Identität.

Genau hier entstehen typische Schwächen: Installation auf einem Domain Controller, jahrelang ungepatchte Versionen, dauerhafte lokale Administratoren, zu breite Connector-Rechte, ungeprüfte Synchronisationsregeln, fehlende Export-Schutzschwellen und ein einzelner Server ohne getesteten Wiederanlauf. Jede dieser Abkürzungen spart kurzfristig Aufwand und erhöht langfristig Ausfall- oder Kompromittierungsrisiko.

Zielbild: Der Connector ist Teil der Control Plane

Ein belastbarer Zielzustand ist konkret:

  1. Entra Connect läuft auf einem dedizierten, unterstützten Windows Server. Der Host übernimmt keine weiteren Anwendungen, ist kein Domain Controller und dient nicht als allgemeine Admin- oder Sprungmaschine.
  2. Administrative Zugriffe folgen dem Tier-0-Modell. Nur getrennte privilegierte Konten und gehärtete Admin-Arbeitsplätze erreichen den Server; normale Benutzerkonten, E-Mail und Web-Browsing bleiben außen vor.
  3. Jede Connector-Berechtigung ist an eine aktiv genutzte Funktion gebunden. Password Hash Sync, Password Writeback, Group Writeback, Device Writeback und Exchange-Hybrid-Rechte werden getrennt bewertet.
  4. Die Synchronisationsfläche ist bewusst definiert. Domänen, OUs, Objekttypen und Attribute haben Owner; privilegierte oder rein technische Konten werden nicht reflexartig in die Cloud synchronisiert.
  5. Exporte haben Leitplanken. Regel- und Scope-Änderungen werden vor dem Export geprüft, der Schutz vor Massenlöschungen bleibt aktiv und Freigaben für große Löschungen folgen einem Vier-Augen-Prozess.
  6. Ein Staging-Server und eine aktuelle Konfigurationssicherung sind vorhanden. Nur ein Server exportiert aktiv; der Umschaltprozess ist dokumentiert und getestet.
  7. Betrieb und Änderungen sind sichtbar. Version, Sync-Zustand, Exportfehler, Zertifikate, Admin-Aktionen und lokale Berechtigungsänderungen werden überwacht.

Das Ziel ist nicht, den Server durch möglichst viele Kontrollen unwartbar zu machen. Das Ziel ist eine schmale, nachvollziehbare Betriebsfläche mit klarer Wiederherstellung.

Umsetzung: Host, Identitäten und Exportpfad gemeinsam härten

1) Version und Topologie zuerst erfassen

Vor Änderungen braucht es eine belastbare Bestandsaufnahme: aktive und Staging-Server, Windows-Version, Entra-Connect-Version, SQL-Variante, verbundene Forests, aktivierte Features, Authentifizierungsmethode und letzter erfolgreicher Export.

Auf dem Sync-Server liefern diese Abfragen einen sicheren Startpunkt, ohne die Konfiguration zu verändern:

Import-Module ADSync

Get-ADSyncScheduler |
  Select-Object SyncCycleEnabled, StagingModeEnabled,
    NextSyncCyclePolicyType, NextSyncCycleStartTimeInUTC

Get-ADSyncAutoUpgrade

$uninstallRoots = @(
  'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*'
  'HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*'
)

Get-ItemProperty -Path $uninstallRoots -ErrorAction SilentlyContinue |
  Where-Object DisplayName -Match 'Microsoft (Entra|Azure AD) Connect' |
  Select-Object DisplayName, DisplayVersion, InstallDate

Automatisches Upgrade ist hilfreich, aber kein Nachweis für Aktualität. Fehlgeschlagene Auto-Upgrades müssen im Eventlog und im Patch-Prozess sichtbar werden. Im Juli 2026 ist außerdem ein konkreter Termin relevant: Synchronisationsdienste unterhalb Version 2.5.79.0 sollen ab dem 30. September 2026 nicht mehr arbeiten. Das ist ein Mindeststand, keine Zielversion. Ziel bleibt die aktuell unterstützte, getestete Version.

Bei alten Installationen oder größeren Betriebssystemwechseln ist eine Swing Migration meist sauberer als ein In-place-Upgrade. Dabei entsteht ein neuer Server im Staging Mode, dessen Konfiguration und erwartete Exporte vor der Umschaltung verglichen werden.

2) Den Server wie einen privilegierten Identitätshost behandeln

Entra Connect gehört auf einen dedizierten, domänengebundenen Windows Server mit aktuellem Supportstand. Für Neuaufbauten sind Windows Server 2022 oder 2025 die naheliegende Basis. Betrieb auf einem Domain Controller oder gemeinsam mit AD CS, Management-Tools, Backup-Konsole oder Drittanbieter-Agenten vergrößert die Angriffs- und Ausfallfläche unnötig.

Die Host-Baseline sollte mindestens enthalten:

  • lokale Administratoren auf eine kleine, kontrollierte Gruppe begrenzen,
  • RDP und WinRM nur aus dem Tier-0-Adminnetz beziehungsweise von PAWs erlauben,
  • Windows Firewall mit dokumentierten eingehenden und ausgehenden Regeln betreiben,
  • Internetzugriff auf die benötigten Microsoft-Endpunkte, Update-, Zertifikats- und Monitoringpfade begrenzen,
  • EDR und zentrale Protokollierung ohne pauschale Prozess- oder Verzeichnisausnahmen betreiben,
  • Secure Boot, BitLocker und eine gehärtete Windows-Server-Baseline nutzen,
  • interaktive Anmeldung für normale Benutzer, Servicekonten und allgemeine Serveradministratoren verweigern,
  • NTLM zunächst überwachen und anschließend für diesen Host kontrolliert zurückbauen,
  • Backups, VM-Konsole und Hypervisor-Zugriff ebenfalls als Tier 0 behandeln.

Admin-Sitzungen verwenden ein getrenntes privilegiertes Konto. Für den Entra-Connect-Wizard reicht je nach Vorgang der Hybrid Identity Administrator; Global Administrator sollte keine dauerhafte Betriebsrolle sein. Moderne MFA- oder passwortlose Anmeldung schützt den interaktiven Konfigurationsvorgang, ersetzt aber nicht die Absicherung des lokalen Hosts.

3) Connector-Konten nach Funktion berechtigen

Die drei Kernidentitäten dürfen nicht zu einem unscharfen Sammelkonto werden:

  • AD-DS-Connector-Konto: ein normales AD-Benutzerobjekt mit den für den gewählten Funktionsumfang erforderlichen Rechten. VSA, MSA und gMSA werden für dieses Connector-Konto nicht unterstützt.
  • ADSync-Dienstkonto: führt den Sync-Dienst aus und greift auf die SQL-Datenbank zu. Seine lokalen Rechte und die DPAPI-geschützten Schlüssel gehören zum Schutzbereich des Hosts.
  • Entra-Connector-Identität: schreibt Synchronisationsänderungen nach Entra ID. Aktuelle Versionen unterstützen anwendungsbasierte Authentifizierung mit Zertifikat; Zertifikatsrotation und zugehörige Anwendung müssen überwacht werden.

Password Hash Synchronization benötigt Verzeichnis-Replikationsrechte im AD. Password Writeback und weitere Writeback-Funktionen brauchen zusätzliche Schreibrechte. Deshalb wird nicht pauschal ein hochprivilegiertes Konto hinterlegt. Zuerst wird pro Feature entschieden, ob es fachlich gebraucht wird; danach werden nur die dokumentierten Rechte delegiert.

Eine einfache Betriebsabfrage zeigt Dienstkonto und Connector-Namen, ohne Secrets auszugeben:

Get-CimInstance Win32_Service -Filter "Name='ADSync'" |
  Select-Object Name, State, StartMode, StartName

Import-Module ADSync
Get-ADSyncConnector |
  Select-Object Name, ConnectorTypeName

Die Ausgabe gehört in eine geschützte Betriebsdokumentation, nicht in ein öffentliches Ticket. Nach Migrationen werden alte Connector-Identitäten erst entfernt, wenn eindeutig feststeht, dass kein aktiver oder Staging-Server sie mehr nutzt.

4) Synchronisationsumfang und Writeback klein halten

OU-Filtering ist kein kosmetisches Detail. Wenn eine synchronisierte OU umbenannt oder aus dem Scope genommen wird, können Objekte beim nächsten Full Import als nicht mehr synchronisiert gelten und zur Löschung in Entra ID vorgemerkt werden. Änderungen am Scope brauchen deshalb dieselbe Sorgfalt wie Änderungen an Berechtigungen.

Für jedes aktivierte Feature sollte die Projektakte beantworten:

  • Welche Objekte und Attribute werden aus welchem Forest synchronisiert?
  • Welche Systeme benötigen Password Hash Sync, Password Writeback oder andere Rückschreibungen?
  • Welche AD-OUs enthalten Tier-0-, Service-, Test- oder technische Konten, die nicht in Entra ID gehören?
  • Welche Standardregeln wurden ergänzt und welche benutzerdefinierten Regeln existieren?
  • Wer verantwortet sourceAnchor, UPN- und ProxyAddress-Bereinigung?

Microsoft-Standardregeln werden nicht direkt verändert. Falls eine eigene Regel erforderlich ist, wird sie dokumentiert, mit eindeutiger Präzedenz angelegt und nach jedem Upgrade erneut geprüft. Privilegierte On-premises- und Cloud-Administration sollte grundsätzlich mit getrennten Konten erfolgen; cloud-only Notfallkonten dürfen nicht von der lokalen Synchronisationsbrücke abhängen.

5) Änderungen vor dem Export prüfen

Scope-, Filter- und Regeländerungen werden nie direkt in einen laufenden Export geschoben. Für planbare Wartung wird der Scheduler kontrolliert angehalten oder die Änderung auf dem Staging-Server aufgebaut. Danach werden Connector Space, Metaverse und ausstehende Exporte geprüft.

Import-Module ADSync
Set-ADSyncScheduler -SyncCycleEnabled $false

# Änderungen nur über unterstützte Assistenten und Werkzeuge durchführen.
# Ausstehende Adds, Updates und Deletes vor dem Export prüfen.

Set-ADSyncScheduler -SyncCycleEnabled $true
Start-ADSyncSyncCycle -PolicyType Delta

Das erneute Aktivieren gehört erst hinter eine dokumentierte Freigabe. Der Schutz vor versehentlichen Massenlöschungen bleibt aktiviert. Der Standardwert von 500 Objekten ist für einen kleinen Tenant oft zu hoch und für einen sehr großen Tenant nicht automatisch passend. Der Schwellenwert wird an Organisationsgröße, normale Änderungsvolumina und Reaktionszeit angepasst. Ein Überschreiten ist ein Stoppsignal zur Analyse, kein Grund, den Schutz reflexartig abzuschalten.

OU-Umbenennungen, Forest-Konsolidierungen, Exchange-Hybrid-Änderungen und neue Filter verdienen einen Full-Import-/Full-Sync-Test im Staging Mode. Entscheidend ist nicht nur, dass gewünschte Objekte erscheinen, sondern auch, welche Objekte unerwartet gelöscht, zusammengeführt oder aus dem Scope gedrängt würden.

6) Wiederanlauf ohne aktives Doppel-Export-System vorbereiten

Eine unterstützte Hochverfügbarkeitsstrategie besteht aus einem aktiven Entra-Connect-Server und mindestens einem Staging-Server. Der Staging-Server importiert und synchronisiert, exportiert aber nicht. Zwei gleichzeitig aktive Connect-Sync-Server für denselben Tenant sind kein sauberes Active-Active-Modell.

Die Konfiguration wird nach jeder relevanten Änderung über den Entra-Connect-Assistenten exportiert und geschützt abgelegt. Automatische JSON-Exporte unter %ProgramData%\AADConnect erfassen Wizard-Änderungen, aber nicht zwingend jede Änderung aus PowerShell, Synchronization Service Manager oder Rules Editor. Deshalb braucht es nach solchen Änderungen einen bewussten Export und einen Vergleich zur freigegebenen Sollkonfiguration.

Die JSON-Datei ist keine vollständige Sicherung aller Credentials und kein Ersatz für einen Wiederanlauftest. Ein sauberer Test umfasst:

  1. neuen unterstützten Server bereitstellen,
  2. Konfiguration importieren und Staging Mode bestätigen,
  3. Connector-Credentials kontrolliert neu setzen,
  4. Imports, Synchronisation und Exportvorschau vergleichen,
  5. Umschaltung und Rückfallentscheidung dokumentieren,
  6. alten Server erst nach stabiler Betriebsphase außer Betrieb nehmen.

Das Zurückrollen eines alten VM-Snapshots ist kein belastbares Recovery-Modell. Hostzustand, DPAPI-Schlüssel, Zertifikate, Datenbank und Connector-Credentials können dann nicht mehr zusammenpassen. Besonders bei anwendungsbasierter Authentifizierung und Zertifikatsrotation ist ein reproduzierbarer Neuaufbau sicherer als ein ungeprüfter Zeitstand.

7) Betrieb und Änderungen überwachen

Monitoring muss sowohl Ausfall als auch Manipulation erkennen. Relevante Signale sind:

  • kein erfolgreicher Import, Sync oder Export innerhalb des erwarteten Fensters,
  • unerwartet viele Adds, Updates oder Deletes,
  • neue Connector-, Scope- oder Synchronisationsregel,
  • Änderung von Staging Mode, Scheduler oder Authentifizierungsmethode,
  • Ablauf oder fehlgeschlagene Rotation des Connector-Zertifikats,
  • neue lokale Administratoren oder interaktive Anmeldungen,
  • gestoppter ADSync-Dienst, Datenbank- oder Proxyfehler,
  • veraltete Entra-Connect- oder Windows-Version,
  • Fehler in Password Hash Sync oder Writeback.

Aktuelle Versionen protokollieren administrative Änderungen als Entra Connect Admin Actions im Windows-Application-Log. Dieses Logging bleibt aktiviert, das Log erhält ausreichend Größe und sicherheitsrelevante Events werden an das SIEM weitergeleitet. Entra Connect Health ergänzt den lokalen Blick, ersetzt aber weder zentrale Windows-Logs noch einen Alarm auf ausbleibende Synchronisation.

Vorteile

  • Begrenzt einen kritischen Übergangspfad: Lokales AD und Entra ID sind nicht mehr über einen beliebig administrierten Member Server verbunden.
  • Reduziert stehende Privilegien: Connector-Konten erhalten nur die Rechte, die aktive Features tatsächlich benötigen.
  • Verhindert vermeidbare Massenänderungen: Staging, Exportvorschau und Löschschwelle bremsen fehlerhafte Scope- und Regeländerungen.
  • Verbessert Wiederherstellbarkeit: Ein aktueller Staging-Server und exportierte Sollkonfiguration reduzieren improvisierte Notfallarbeiten.
  • Macht Änderungen prüfbar: Admin-Audit, SIEM und Konfigurationsvergleiche schaffen nachvollziehbare Evidenz.
  • Vereinfacht spätere Modernisierung: Eine dokumentierte Topologie lässt sich realistischer auf Cloud Sync oder andere Hybrid-Identity-Modelle prüfen.

Nachteile und Grenzen

  • Tier-0-Betrieb kostet Ressourcen: Dedizierter Server, PAW-Zugriff, Staging-System und Monitoring brauchen Pflege und Verantwortliche.
  • Zu enge Rechte können Funktionen brechen: Password Writeback, Exchange Hybrid oder Gerätefunktionen fallen aus, wenn Delegationen ohne Funktionsmatrix entfernt werden.
  • Netzwerk-Allowlisting braucht Wartung: Microsoft-Endpunkte, Zertifikatsprüfung, Updates und Monitoring ändern sich über die Zeit.
  • Staging ist kein Active-Active: Umschaltung bleibt ein kontrollierter Betriebsprozess und muss geübt werden.
  • PHS, PTA und Federation behalten eigene Risiken: Die Härtung des Sync-Servers ersetzt keine Architekturentscheidung zur Authentifizierung.
  • Lokale Administratoren bleiben hochwirksam: EDR, BitLocker und DPAPI neutralisieren keinen vollständig kontrollierten Host.
  • Cloud Sync ist nicht immer ein Drop-in-Ersatz: Funktionsumfang, Topologie und Writeback-Anforderungen müssen vor einer Migration geprüft werden.

Typische Stolperfallen

  • Installation auf einem Domain Controller: Das vermischt Rollen, Berechtigungen, Patchfenster und Wiederherstellung unnötig.
  • Automatisches Upgrade mit Patchmanagement verwechseln: Ein konfigurierter Modus beweist nicht, dass Upgrades erfolgreich liefen.
  • Global Administrator dauerhaft verwenden: Installationsberechtigung wird zur normalen Betriebsidentität.
  • Connector-Konto pauschal überprivilegieren: Zusätzliche Writeback- oder Replikationsrechte bleiben nach deaktivierten Features bestehen.
  • OU-Filter im laufenden Betrieb ändern: Der nächste Full Import bereitet unerwartete Cloud-Löschungen vor.
  • Löschschwelle nur bei Alarm betrachten: Ein unpassender Standardwert schützt kleine oder sehr große Tenants nicht automatisch.
  • Zwei Server aktiv exportieren lassen: Aus vermeintlicher Hochverfügbarkeit entsteht ein nicht unterstützter Betriebszustand.
  • Nur die JSON-Datei sichern: Credentials, Zertifikate und nicht erfasste Regeländerungen fehlen beim Wiederanlauf.
  • Breite EDR-Ausnahmen setzen: Ein Identity-Control-Plane-Server verliert genau dort Erkennung, wo sie besonders wichtig ist.
  • Alte Server und Connector-Identitäten vergessen: Ruhende Konten und Apps bleiben als unklare Zugriffswege bestehen.
  • Privilegierte AD-Konten ungeprüft synchronisieren: On-premises- und Cloud-Administration werden unnötig gekoppelt.

Projekt-Checkliste

  • [ ] Aktiven Entra-Connect-Server, Staging-Server, Versionen, SQL-Modell und verbundene Forests dokumentieren.
  • [ ] Aktuelle Support- und Upgrade-Anforderungen prüfen; Mindestversion 2.5.79.0 vor dem 30. September 2026 sicher überschreiten.
  • [ ] Dedizierten Windows Server als Control-Plane-/Tier-0-System betreiben.
  • [ ] Lokale Administratoren, RDP, WinRM, Firewall, EDR, BitLocker, Backup und Hypervisor-Zugriff härten.
  • [ ] Getrennte privilegierte Admin-Konten mit MFA oder passwortloser Anmeldung verwenden.
  • [ ] AD-DS-Connector-, ADSync-Dienst- und Entra-Connector-Identität inventarisieren.
  • [ ] Rechte pro aktivem Feature prüfen und nicht mehr benötigte Delegationen kontrolliert entfernen.
  • [ ] Domänen-, OU-, Objekt- und Attribut-Scope mit fachlichem Owner dokumentieren.
  • [ ] Privilegierte, technische und Notfallkonten auf notwendige Synchronisation prüfen.
  • [ ] Benutzerdefinierte Regeln dokumentieren; Microsoft-Standardregeln nicht direkt verändern.
  • [ ] Schutz vor versehentlichen Löschungen aktivieren und Schwellenwert an den Tenant anpassen.
  • [ ] Scope- und Regeländerungen im Staging Mode mit Exportvorschau und Vier-Augen-Freigabe testen.
  • [ ] Aktuelle Konfiguration exportieren, geschützt sichern und mit dem Sollstand vergleichen.
  • [ ] Staging-Umschaltung und Neuaufbau mindestens jährlich praktisch testen.
  • [ ] Entra Connect Admin Actions, Sync Health, Exportfehler, Zertifikate und lokale Adminänderungen an das Monitoring anbinden.
  • [ ] Alte Server, Connector-Konten, Anwendungen und Zertifikate nach Migration kontrolliert entfernen.