Active Directory | Entra Connect Agenten statt klassischer Sync-Server ⏱ 5 Min.

Active Directory | Entra Connect Agenten statt klassischer Sync-Server

Die Evolution der Identitäts-Synchronisation: Entra Connect vs. Cloud Sync

In modernen hybriden IT-Infrastrukturen bilden Identitäten den zentralen Sicherheitsperimeter. Die Synchronisation zwischen dem lokalen Active Directory (AD) und Microsoft Entra ID ist dabei weit mehr als eine einfache Datenreplikation; sie ist das Fundament für Conditional Access, Zero Trust und die Integrität deiner gesamten Microsoft 365-Umgebung. Der klassische Synchronisations-Server (Entra Connect Sync) wird zunehmend von Cloud Sync abgelöst, doch die Wahl des richtigen Modells erfordert ein Verständnis der zugrunde liegenden Architektur.

Warum der Wechsel zum Agenten-Modell technisch zwingend ist

Der traditionelle Entra Connect Sync-Server ist ein monolithisches Konstrukt. Er benötigt eine lokale SQL-Instanz, eine aufwändige Installation und ist oft als Single Point of Failure (SPOF) konzipiert. Wenn dieser Server ausfällt oder durch ein fehlerhaftes Update instabil wird, steht der gesamte Identitätsabgleich still.

Im Gegensatz dazu verfolgt Microsoft Entra Connect Cloud Sync einen modernen, agentenbasierten Ansatz. Hierbei installierst du lediglich leichtgewichtige Agenten auf Windows Servern innerhalb deines Netzwerks. Die Synchronisationslogik selbst verlagert sich in die Cloud. Du kannst mehrere Agenten in einer Gruppe betreiben: Fällt ein Server aus oder wird er gewartet, erkennt Cloud Sync automatisch die verfügbaren Instanzen und verteilt die Last ohne manuellen Eingriff. Weil keine lokale SQL-Datenbank mehr für den Sync-Prozess erforderlich ist, entfällt der gesamte Overhead für deren Wartung und Backup. Die Konfiguration erfolgt zentral über das Entra Admin Center.

Der Agent baut dabei ausschließlich ausgehende HTTPS-Verbindungen auf Port 443 auf. Kein eingehender Port muss geöffnet werden, kein direkter DC-Zugriff über WAN ist erforderlich. Das macht Cloud Sync auch in restriktiven Netzwerkumgebungen und nach Firmenübernahmen ohne bestehende VPN-Verbindung einsetzbar.

Architektur-Analyse: PHS und die Sicherheit von Identitäts-Tokens

Viele Administratoren zögern bei der Nutzung von Password Hash Synchronization (PHS), da sie die Speicherung von Hashes in der Cloud fälschlicherweise für unsicher halten. Technisch betrachtet ist PHS jedoch die robusteste Methode. Wenn ein Benutzer sein Passwort lokal ändert, extrahiert der Synchronisationsdienst den Hash aus dem AD, erweitert diesen um ein per-user Salt, und unterzieht ihn 1000 Iterationen von HMAC-SHA256 (PBKDF2).

Dieser Prozess stellt sicher, dass selbst bei einer theoretischen Kompromittierung des Cloud-Identitäts-Speichers keine lokalen Passwort-Hashes ("Pass-the-Hash"-Angriffe) extrahiert werden können. PHS in Kombination mit Leaked Credential Risk Events ermöglicht es Entra ID zudem, proaktiv Konten zu sperren, falls die Anmeldedaten des Users in einem der bekannten Darknet-Leaks auftauchen.

Die technische Kette dahinter: Identity Protection bewertet das Risiko des Kontos in Echtzeit und setzt einen User Risk. Eine Conditional-Access-Richtlinie greift diesen Risk-Score auf und erzwingt automatisch eine Passwort-Änderung oder blockiert den Zugriff vollständig, ohne dass ein Admin manuell eingreifen muss. Voraussetzung ist eine Entra ID P2-Lizenz für risikobasierte CA-Policies.

Die Gefahr von Legacy-Architekturen: Warum AD FS ein Sicherheitsrisiko darstellt

Viele historisch gewachsene Infrastrukturen nutzen noch immer Active Directory Federation Services (AD FS) für Single Sign-On (SSO). Aus architektonischer Sicht ist AD FS ein Tier-0-Asset, das eine extrem hohe Schutzbedürftigkeit genießt. Ein AD FS-Server, der öffentlich erreichbar ist, stellt eine Einladung für Angreifer dar.

Das kritische Risiko bei AD FS ist die Kompromittierung des Token-Signing-Zertifikats. Gelingt es einem Angreifer, dieses Zertifikat zu entwenden, kann er sogenannte „Golden SAML“-Tokens erstellen. Da Entra ID diesen Tokens vertraut, kann der Angreifer jegliche Multi-Faktor-Authentifizierung (MFA) umgehen, da der Token bereits als „MFA-erfolgreich validiert“ signiert ist.

Der Umstieg auf PHS in Verbindung mit Seamless SSO ist daher die architektonisch sauberste Lösung. Sie eliminiert die lokale Abhängigkeit von hochsensiblen Federation-Servern und nutzt stattdessen die sicheren, cloud-eigenen Authentifizierungsdienste.

Seamless SSO funktioniert dabei über einen Kerberos-Mechanismus: Der Domain Controller stellt dem Browser des domain-joined Clients automatisch ein Ticket aus, das Entra ID als gültigen Identitätsnachweis akzeptiert. Der Benutzer gibt keine Credentials ein, der Anmeldevorgang läuft unsichtbar im Hintergrund ab. Voraussetzung ist lediglich, dass der Client Mitglied der Domäne ist und der Browser so konfiguriert wurde, dass er die Entra-ID-Endpunkte als Intranet-Zone behandelt.

Praxishinweise zur Hochverfügbarkeit und Versions-Drift

Eine häufige Fehlannahme ist, dass Cloud Sync automatisch "ausfallsicherer" sei, weil mehrere Agenten existieren. Das ist nur die halbe Wahrheit. Ein reales Problem in der Praxis ist die Agent-Versionsdrift. Wenn einer deiner Cloud Sync-Agenten automatisch aktualisiert wird und ein anderer auf einer veralteten Version hängen bleibt, können Inkonsistenzen in der Attribut-Synchronisation auftreten.

Du musst bei der Nutzung von Cloud Sync zwingend ein Monitoring für die Agenten-Statusmeldungen implementieren. Stelle sicher, dass die Agenten-Server regelmäßig auf ihren Update-Status überprüft werden, um sicherzustellen, dass alle Instanzen auf dem gleichen Release-Stand sind.

Fazit

Der Übergang zu einer agentenbasierten Synchronisation mittels Cloud Sync ist eine notwendige Evolution, um die Komplexität und Anfälligkeit lokaler Synchronisations-Server zu minimieren. Durch die Entkopplung der Synchronisationslogik vom Server hin zur Cloud-Orchestrierung erreichst du eine höhere Resilienz und vereinfachst das Patch-Management.

Allerdings darfst du dabei nicht in die Falle der "falschen Sicherheit" tappen. Ausfallsicherheit entsteht nicht durch die Software alleine, sondern durch das aktive Management der Agenten und die saubere Trennung der Verantwortlichkeiten. Wenn du zudem noch ein AD FS-Legacy-Monster im Keller hast, sollte deine Priorität nicht nur in der Umstellung auf Cloud Sync liegen, sondern in der kompletten Abschaltung der Federation-Infrastruktur zugunsten von PHS und Seamless SSO. Nur so schaffst du ein Fundament, das modernen Angriffen wie Golden SAML tatsächlich standhalten kann.

Glossar

FachbegriffDefinition & technische Relevanz
PHSPassword Hash Synchronization – Übertragung der kryptografisch gesalzenen Passwort-Hashes von On-Premises zu Entra ID.
AD FSActive Directory Federation Services – Lokale Serverrolle für Authentifizierung (SAML/WS-Fed).
PTAPass-Through Authentication – Authentifizierung findet lokal auf dem Domain Controller statt; Entra ID agiert nur als Vermittler.
Seamless SSOTechnologie, die Clients (domain-joined) ein Single Sign-On Erlebnis ermöglicht, ohne dass User Credentials erneut eingeben müssen.
Cloud SyncDer moderne Synchronisationsdienst via leichtgewichtigen Agenten; entkoppelt die Logik vom lokalen Server.
SAMLSecurity Assertion Markup Language – XML-Standard für Authentifizierung und Autorisierung; Kernstück vieler Federation-Setups.
Golden SAMLEin schwerwiegender Angriffstyp, bei dem ein gestohlenes AD FS-Zertifikat zur Token-Fälschung genutzt wird.


Teilen:
Noch keine Kommentare

Sei der Erste und starte die Diskussion mit einem hilfreichen Beitrag.

Kommentar hinterlassen

Dein Beitrag wird vor der Veröffentlichung kurz geprüft — fachlich, respektvoll und auf den Punkt ist hier genau richtig.

E-Mail Adresse wird nicht veröffentlicht.