Entra ID Sync – Praxisleitfaden für IT-Leiter und Admins

Management Summary

• Entra ID Sync als Schlüssel zur hybriden Identität: Mit Entra ID Sync verbinden Sie Ihre lokale Active Directory-Welt nahtlos mit der Cloud. Das Ergebnis ist ein konsistentes Benutzerkonto über alle Systeme hinweg, weniger manuelle Pflege und zufriedenere Anwender dank Single Sign-On und automatisierter Kontoverwaltung.
• Zwei Wege zum Ziel – Connect Sync oder Cloud Sync: Microsoft bietet zwei Varianten der Synchronisierung: die klassische Entra Connect Synchronisierung (Connect Sync) und die moderne Entra Cloud Synchronisierung (Cloud Sync). Beide erfüllen den gleichen Zweck, unterscheiden sich aber in Architektur und Einsatz: Connect Sync läuft auf einem eigenen Server und bietet maximale Kontrolle (inkl. Pass-Through-Authentifizierung), während Cloud Sync mit schlanken Agenten auskommt und Konfiguration bequem in der Cloud verwaltet – ideal bei verteilten Umgebungen oder M&A-Szenarien. Die Wahl hängt von Ihren Anforderungen an Funktionsumfang, Infrastruktur und Wartungsaufwand ab.
• Sicherheit als oberstes Gebot: Entra ID Sync bringt enorme Vorteile, doch ohne Sicherheitsmaßnahmen geht es nicht. Daher gehören Prinzipien wie Least Privilege (minimale Rechte für Dienstkonten), eine sichere Geheimnisverwaltung (Passwörter, Hashes und Zertifikate schützen), regelmäßige Updates sowie umfangreiche Audit-Logs und Überwachungen zu den Pflichtaufgaben. So bleibt Ihre Identitätsinfrastruktur robust gegenüber Angriffen und compliant mit Datenschutzvorgaben.
• Mehr als nur Kopieren – Rückschreiben als Turbo: Entra ID Sync kann nicht nur Daten hochladen, sondern auf Wunsch auch wieder zurückspielen. Funktionen wie Passwort-Rückschreibung ermöglichen Self-Service-Passwortreset für Mitarbeiter, und Group- oder Device-Writeback sorgen dafür, dass Cloud-Gruppen und Azure AD-registrierte Geräte auch On-Premises bekannt sind. Diese optionalen Features eröffnen neue Möglichkeiten für Hybrid-Szenarien – von einfacherer Geräteverwaltung bis zu modernen HR-Provisionierungsprozessen über SCIM.
• Mit Plan zum Erfolg – der grobe Fahrplan: Die Einführung von Entra ID Sync gelingt am besten Schritt für Schritt. Zuerst steht die Konzeptionsphase an (Anforderungen klären, Topologie wählen, Accounts vorbereiten), gefolgt von einer Pilotierung im kleinen Kreis. Danach erfolgt die Umsetzung in der Produktion mit sauberer Konfiguration, Tests und schrittweisem Rollout. Abschließend sorgen ein durchdachtes Betriebskonzept mit Monitoring, Notfallplänen und klaren Verantwortlichkeiten dafür, dass der Synchronisierungsservice langfristig stabil und zuverlässig läuft.

Einordnung und Ziele

Bevor wir ins Eingemachte gehen, lohnt sich eine kurze Begriffsklärung rund um Entra ID Sync und dessen Ziele. Microsoft Entra ID (bis 2023 bekannt als Azure Active Directory) ist Microsofts cloudbasiertes Identitätsverzeichnis – das Herz von Microsoft 365, in dem Benutzer, Gruppen und Rechte in der Cloud verwaltet werden. Mit Entra ID Sync bezeichnet man die generelle Synchronisierung zwischen der lokalen Windows Server Active Directory (AD) und der Cloud (Entra ID). Microsoft stellt hierfür zwei Werkzeuge bereit: Entra ID Connect Sync (das klassische Azure AD Connect Tool) und Entra ID Cloud Sync (ein moderner Cloud-verwalteter Synchronisierungsdienst). Beide sorgen dafür, dass lokale Konten, Gruppen und weitere Objekte im Entra ID auftauchen und aktuell bleiben, unterscheiden sich aber in Technik und Einsatzszweck (dazu gleich mehr).

Daneben begegnen uns weitere Fachbegriffe im Kontext hybrider Identität. Password Hash Synchronization (PHS) meint das Synchronisieren eines Hash-Werts der AD-Passwörter in die Cloud – so können sich Benutzer in Entra ID mit dem gleichen Kennwort anmelden, ohne dass das Klartextpasswort die Firma verlässt. Pass-Through Authentication (PTA) hingegen lässt Entra ID Anmeldeversuche in Echtzeit an einen lokalen Agent weiterreichen, der das Passwort direkt gegen AD prüft. Federation bezeichnet föderierte Anmeldungen, klassischerweise via Active Directory Federation Services (AD FS): Hier vertraut Entra ID auf einen externen Identity Provider (z.B. AD FS), der die Authentifizierung übernimmt – oft genutzt, um ein Single Sign-On zu erreichen, ohne Passwörter in die Cloud zu geben. Und dann ist da noch SCIM (System for Cross-domain Identity Management), ein offener Standard für die automatisierte Benutzerprovisionierung. SCIM spielt im Entra-ID-Umfeld eine Rolle, wenn es darum geht, Benutzerdaten zwischen unterschiedlichen Systemen auszutauschen, etwa von einem Cloud-HR-System in die Entra ID oder zu Drittsystemen.

Typische Ziele: Unternehmen setzen Entra ID Sync ein, um ein einheitliches Identity Management zwischen On-Premises und Cloud zu schaffen. Dadurch müssen Benutzer und Admins sich nur noch um ein Konto pro Mitarbeiter kümmern, unabhängig davon, ob jemand sich am PC anmeldet, auf Outlook in Microsoft 365 zugreift oder eine Cloud-App nutzt. Single Sign-On (SSO) wird Realität: Einmal am Morgen am Windows-PC angemeldet, können Mitarbeiter z.B. Teams, SharePoint oder andere Cloud-Dienste nutzen, ohne ständig Passwörter einzugeben. Auch die Automatisierung steht im Vordergrund: Neue Mitarbeiter erhalten automatisch ein Cloud-Konto mit Lizenz, sobald im AD ein Benutzer angelegt wird, Berechtigungsänderungen oder Sperrungen (z.B. beim Firmenaustritt) greifen systemübergreifend. Das spart Aufwand, reduziert Fehler und unterstützt die IT-Sicherheit und Compliance – man denke an das schnelle Deaktivieren von Zugängen oder das konsistente Durchsetzen von Passwortpolicies.

Abgrenzung zu Drittanbieter-Tools: Natürlich ist Microsoft nicht allein auf weiter Flur im Identity- & Access-Management. Es gibt Drittanbieter wie Okta, One Identity, Ping oder Tools wie SailPoint und sogar den betagten Microsoft Identity Manager (MIM), die teils ähnliche Ziele verfolgen: Identitäten über Systemgrenzen hinweg synchron halten. Der Unterschied: Entra ID Sync (also Connect Sync und Cloud Sync) ist speziell für die Kopplung von AD mit Entra ID konzipiert, quasi „aus einem Guss“ mit Microsoft 365 integriert und für diese Aufgabe kostenlos nutzbar. Drittanbieter-Lösungen kommen meist ins Spiel, wenn sehr heterogene Umgebungen oder zusätzliche Systeme jenseits von Azure/Microsoft 365 angebunden werden sollen, oder wenn komplexe Workflows und Genehmigungsprozesse (Identity Governance) benötigt werden. Für die Synchronisation von klassischem AD zu Entra ID sind die Microsoft-Tools jedoch in der Regel der schnellere, einfachere und auch kosteneffizientere Weg – und sie werden von Microsoft direkt unterstützt. Kurz gesagt: Bevor man zu externen Provisionierungstools greift, sollte man prüfen, ob Entra ID Sync nicht bereits 100 % der Anforderungen abdeckt. In den meisten Fällen lautet die Antwort: ja, das tut es, und zwar mit weniger Komplexität.

Architektur & Topologien

Eine erfolgreiche Entra ID Synchronisierung muss zur vorhandenen Infrastruktur passen. Hier schauen wir uns typische Topologien an – von einer einzigen AD-Gesamtstruktur bis zu komplexen Multi-Forest-Umgebungen – und die Anmeldemethoden (PHS, PTA, Federation) mit ihren Vor- und Nachteilen. Außerdem klären wir, wie man Hochverfügbarkeit erreicht und was im Notfall (Fallback) zu tun ist.

Single-Forest vs. Multi-Forest – was passt zu Ihrer Umgebung?

Single-Forest-Topologie: Die einfachste Variante ist eine einzelne AD-Gesamtstruktur mit ggf. mehreren Domains, die mit einem einzelnen Entra ID Tenant verbunden wird. In diesem Fall reicht ein Entra Connect Sync Server, der alle Objekte aus dieser Forest in die Cloud synchronisiert. Diese Konstellation ist quasi der „Standardfall“ und wird von Microsofts Express-Einstellungen in Azure AD Connect direkt unterstützt. Wichtig ist hier vor allem, den Sync-Server zentral zu platzieren (idealerweise in einem gut angebundenen Rechenzentrum) und zu entscheiden, ob Password Hash Sync oder Pass-Through bzw. Federation fürs Login genutzt werden soll (dazu gleich mehr). Für viele Unternehmen mit einem einzelnen AD ist diese Topologie problemlos umzusetzen.

Multi-Forest-Topologien: Viele Unternehmen haben jedoch mehrere AD-Forests – sei es historisch gewachsen, durch Fusionen/Übernahmen oder durch Aufteilung in Account- und Ressourcenforest (z.B. separater Exchange-Forest). Grundsätzlich gilt: Mit dem klassischen Entra Connect Sync lässt sich ein einziger Sync-Server pro Tenant betreiben (von einer Ausnahme gleich abgesehen), der aber Zugriff auf alle AD-Forests haben muss, die synchronisiert werden sollen. Das heißt, die Forests müssen entweder miteinander vertraut sein (Trust) oder zumindest netzwerktechnisch vom Sync-Server erreichbar sein. Azure AD Connect bietet im erweiterten Setup Optionen, Benutzer aus mehreren Forests zu konsolidieren – etwa um einen Mitarbeiter, der in Forest A ein Konto und in Forest B ein Postfach hat, als eine einzige Person in Entra ID darzustellen. Diese Szenarien (Stichwort Account-Resource-Forest oder GALSync) sind komplexer, werden aber unterstützt. Wichtig ist eine saubere Planung der Attributquellen (welcher Forest „gewinnt“ für welches Attribut) – dazu im nächsten Kapitel mehr.

Disconnected Forests: Was aber, wenn die AD-Forests komplett getrennt sind, also keine direkte Verbindung zum zentralen Sync-Server möglich ist? Hier kommt Entra ID Cloud Sync ins Spiel: Mit Cloud Sync können Sie in jedem Forest einen leichten Agent installieren, der sich separat mit Entra ID verbindet. Alle Agenten synchronisieren in denselben Tenant, ohne dass Sie die Forests untereinander verbinden müssen. Dieses Modell eignet sich hervorragend bei Unternehmenszukäufen, bei denen das erworbene Unternehmen seine Benutzer zunächst behalten soll – ein Cloud Sync Agent dort kann die wichtigsten Objekte hochschieben, ohne gleich eine AD-Vertrauensstellung einrichten zu müssen. Eine Besonderheit im Multi-Forest-Betrieb: Standardmäßig erwartet Entra ID pro Benutzer genau ein Konto aus einem Forest. Wenn dieselbe Person in zwei getrennten Forests existiert, kann Azure AD Connect diese Identitäten normalerweise nicht abgleichen (ohne Trust). Cloud Sync bietet hier experimentelle Lösungen mittels eines gemeinsamen Identifikators (ms-DS-ConsistencyGuid), um Daten aus zwei getrennten Quellen zu mergen – aber das ist hohe Kunst und noch im Preview-Stadium. In der Praxis sollte man für ein und denselben Benutzer möglichst eine Quelle definieren und Überschneidungen vermeiden.

Mehrere Azure AD Tenants? Apropos Topologie: Manche Firmen haben mehr als einen Entra ID (Azure AD) Tenant – z.B. getrennte Clouds für verschiedene Geschäftsbereiche. Ein einzelner AD-Benutzer kann jedoch immer nur in einen Tenant synchronisiert werden. Microsoft unterstützt out-of-the-box keine Synchronisation eines Accounts auf mehrere Tenants. Wer so etwas braucht, muss Objekte aufteilen (z.B. per OU-Filter unterschiedliche Benutzer in unterschiedlichen Tenants synchronisieren, mit zwei getrennten Sync-Servern) oder auf Speziallösungen setzen. Die meisten bleiben jedoch bei der Empfehlung: pro Benutzer ein Konto und ein Tenant.

Authentifizierung: PHS, PTA oder Federation?

Neben der Frage „wie kommen meine Benutzerkonten in die Cloud?“ stellt sich gleich die nächste: „wie sollen sich die Benutzer dort anmelden?“. Entra ID unterstützt hier drei Modelle – die Entscheidung wirkt sich auf Architektur, Sicherheit und Verfügbarkeit aus. Die gute Nachricht: Man kann zwischen diesen Modellen wechseln oder auch Kombinationen fahren (z.B. PHS als Fallback parallel zu PTA). Im Folgenden eine kurze Gegenüberstellung:

Kriterium	Password Hash Sync (PHS)	Pass-Through Authentication (PTA)	Federation (AD FS)
Wo wird authentifiziert?	In der Cloud (Entra ID prüft den Passwort-Hash selbst)	On-Premises (Entra ID leitet Passwortprüfung ans lokale AD weiter)	On-Premises, aber über einen föderierten Dienst (AD FS)
Infrastruktur	Kein zusätzlicher Server außer dem Sync-Service. Hashes werden per AD Connect hochgeladen.	Leichter PTA-Agent (Teil von AD Connect oder separat) auf einem Server; Internetverbindung für Anfragen nötig.	AD FS-Farm nötig (mind. 2 AD FS + 2 Web Proxies für HA), plus SSL-Zertifikate, publizierte Endpunkte usw.
Login bei Internetausfall	Ja – Nutzer können sich weiterhin an Microsoft 365 anmelden (da Cloud die Hashes hat).	Nein – kein Login möglich, wenn keine Verbindung zur lokalen AD besteht (Abhängigkeit).	Nein – wenn die Föderationsserver nicht erreichbar sind (oder Internet weg), geht nichts mehr.
Security & Features	Cloud prüft Anmeldungen inkl. Risk-Detection (erkennt z.B. geleakte Passwörter). Unterstützt Azure AD Domain Services.	Keine Passwörter in der Cloud gespeichert (Compliance-Vorteil). Aber keine Risk-Detection durch Entra ID möglich.	Vollständige Kontrolle beim Unternehmen; komplexe MFA- oder Claims-Regeln möglich. Keine Passwortspeicherung in der Cloud.
Komplexität & Aufwand	Einfach – aktiviert per Klick, kaum Wartung.	Mittel – zusätzlicher Agent, aber weniger Aufwand als AD FS.	Hoch – dedizierte Infrastruktur, hoher Einrichtungs- und Wartungsaufwand.
Empfohlen für	Die meisten Szenarien – Standard für geringe Komplexität und hohe Zuverlässigkeit.	Spezielle Compliance-Anforderungen, die Cloud-Passwortspeicherung verbieten, aber ohne den Aufwand einer Federation.	Organisationen, die bereits AD FS nutzen oder sehr spezifische Anforderungen (z.B. komplexe SSO mit Drittanwendungen) haben.

Wie man sieht, ist Password Hash Sync oftmals die pragmatische Wahl: einfach aufzusetzen, robust und mit Vorteilen wie der Erkennung kompromittierter Accounts (wenn z.B. ein Passwort in einem Leak auftaucht, kann Microsoft das nur erkennen, wenn der Hash in der Cloud liegt). Pass-Through Auth bietet sich an, wenn Passwörter absolut nie die Cloud – nicht einmal als Hash – berühren dürfen. Hierbei gilt es aber, die Abhängigkeit von der eigenen Infrastruktur zu bedenken: Fällt die Verbindung oder der PTA-Service aus, kommen Benutzer nicht mehr in ihre Cloud-Apps. Federation via AD FS schließlich ist der „Platinweg“, der jedoch nur noch selten neu aufgebaut wird, weil er sehr komplex ist. Viele Unternehmen mit AD FS im Einsatz denken inzwischen über einen Wechsel zu PHS/PTA nach, um die Umgebung zu vereinfachen (dazu später mehr im Migrationskapitel).

Hochverfügbarkeit, Fallback und Staging-Server

Niemand möchte, dass die Synchronisierung oder gar die Anmeldung ausfällt, nur weil ein Server Probleme hat. Daher stellt sich die Frage nach Hochverfügbarkeit (High Availability, HA) und Fallback-Optionen.

Entra ID Connect Sync (AADC) Hochverfügbarkeit: Azure AD Connect (heute Entra Connect Sync) unterstützt technisch immer nur einen aktiven Sync-Server pro Tenant. Versuche, zwei aktive Server parallel auf denselben Tenant zu synchronisieren, werden von Microsoft als nicht unterstützt eingestuft und führen meist zu Chaos (doppelte Objekte etc.). Die offiziell vorgesehene HA-Lösung ist der Staging Mode: Dabei wird ein zweiter Server als „Warm-Standby“ eingerichtet. Dieser zweite Server läuft im Staging-Modus, d.h. er importiert und verarbeitet alle Änderungen aus dem AD, exportiert aber nicht ins Entra ID. Er hält sich und seine Metaverse-Datenbank quasi bereit. Fällt der erste Server aus, kann man den Staging-Server innerhalb weniger Minuten aktivieren (auf „aktiv“ schalten) und damit die Synchronisierung nahtlos fortführen. Wichtig: Damit das funktioniert, müssen beide Server identisch konfiguriert sein. Microsoft empfiehlt, bei jeder Konfig-Änderung (z.B. neue OU-Filters, zusätzliche Attribute) die Änderung auch auf dem Staging-Server durchzuführen. Ein Staging-Server lässt sich auch für geplante Wartung nutzen – man kann z.B. einen aktualisierten neuen Server als Staging bereitstellen und dann zum Hauptserver machen (Zero-Downtime-Upgrade).

Entra ID Cloud Sync Hochverfügbarkeit: Bei Cloud Sync ist HA noch einfacher gelöst: Hier können Sie mehrere Agenten installieren (am besten auf unterschiedlichen Servern). Alle Agenten einer Konfig arbeiten aktiv im Verbund. Fällt einer aus, übernehmen die verbleibenden automatisch seine Last. Microsoft empfiehlt mindestens zwei Agent-Installationen pro Forest für Produktion. Die Agenten sind zustandslos – sie beziehen die Konfiguration aus der Cloud und führen die Synchronisierung gemeinsam aus. Durch diese aktive Lastverteilung erreicht Cloud Sync von Haus aus eine hohe Ausfallsicherheit, ohne dass der Admin manuell eingreifen muss.

PTA-Agent Hochverfügbarkeit: Ähnlich wie Cloud Sync lassen sich auch mehrere PTA-Agenten bereitstellen. In der Praxis installiert man Pass-Through-Authentifizierungsagenten auf zwei oder mehr Servern (z.B. dem AAD Connect Server und einem zweiten Member-Server). Azure leitet dann Login-Anfragen an alle registrierten Agenten; antwortet einer nicht, versucht es der nächste. So kann ein einzelner Ausfall aufgefangen werden. Wichtig ist, die Agenten aktuell zu halten – sie aktualisieren sich zwar automatisch über Microsoft Update, aber nur, wenn man es nicht deaktiviert hat.

Federation HA: In föderierten Setups mit AD FS ist Hochverfügbarkeit ein Muss und von Anfang an mitzudenken: Typischerweise werden mindestens zwei AD FS-Server in einer Farm betrieben und zusätzlich zwei Web Application Proxies in der DMZ, damit kein Single Point of Failure existiert. Diese müssen hinter Load Balancern liegen, Zertifikate müssen rechtzeitig erneuert werden etc. – man merkt, der Aufwand ist beträchtlich. Wer AD FS betreibt, sollte unbedingt auch das Thema Monitoring/Alerting ernst nehmen (z.B. ADFS-Events überwachen, Zertifikatsablaufwarnungen einrichten).

Fallback-Szenarien: Ein Wort zum Fallback im Sinne der Anmeldemethoden: Microsoft ermöglicht es, Password Hash Sync parallel zu PTA oder Federation zu aktivieren. So können Sie im Notfall umschalten, falls Ihr primärer Authentifizierungsweg versagt. Beispiel: Ihre AD FS-Farm ist komplett offline aufgrund eines Fehlers – wenn Sie PHS bereits eingerichtet haben, können Sie Ihre Domain in Entra ID von „Federated“ auf „Managed (PHS)“ umstellen und die Benutzer weiterhin anmelden lassen, bis AD FS wieder läuft. Ähnliches gilt für PTA: Hier kann PHS als Backup dienen, allerdings erfolgt die Umschaltung nicht automatisch, sondern manuell via Admin Center oder PowerShell. Wichtig ist: planen Sie solche Szenarien im Voraus! Legen Sie fest, wann der Fallback aktiviert wird und wie Sie danach wieder auf den Normalbetrieb zurückkehren. Mit vorbereiteten Skripten und klaren Verantwortlichkeiten kann der „Schalter umlegen“-Prozess in wenigen Minuten erfolgen – und genau diese Minuten könnten bei einem Ausfall entscheidend sein.

Identitätsdaten & Attributfluss

Wer ist der „Master“ für welche Daten? Diese Frage steht im Zentrum des Identity Synchronization Designs. Der Grundgedanke von Entra ID Sync ist, dass Ihre lokale AD-Umgebung die Source of Authority für Benutzer und Gruppen bleibt. Das heißt: Ein in AD angelegter Benutzer wird zur „Quelle der Wahrheit“ – die Cloud-Kopie erhält ihre Informationen primär aus dem lokalen AD. Ändert man z.B. den Nachnamen oder die Abteilung im lokalen User-Objekt, so wird diese Änderung ins Entra ID übertragen. Umgekehrt sind bestimmte Attribute bei synchronisierten Objekten in Entra ID gesperrt für Änderungen, um nicht in Konflikt mit der lokalen Quelle zu geraten. Wichtig: Erstellen Sie Benutzer, die im AD existieren, nicht manuell parallel in Entra ID, das führt zu Duplikaten! Im Zweifelsfall immer im AD anlegen und per Sync hochziehen lassen (oder einen bestehenden Cloud-Account per Matching verknüpfen, siehe unten).

Source Anchor (Quellanker): Damit ein Objekt in AD eindeutig seinem Pendant in Entra ID zugeordnet werden kann, wird beim Synchronisieren ein sogenannter Source Anchor verwendet. Das ist ein Attribut des AD-Objekts, das sich nie ändert und einzigartig ist. Standardmäßig nutzt Azure AD Connect den ObjectGUID eines AD-Benutzers als Anchor – dieser 128-Bit-Wert ist unique und bleibt für das Leben des Objekts konstant (außer man verschiebt das Konto in eine andere Forest). Neuerdings empfiehlt Microsoft, lieber das Attribut ms-DS-ConsistencyGuid als Anchor zu nehmen. Das ist ein frei beschreibbares GUID-Feld am AD-Objekt, das man z.B. vorab mit dem ObjectGUID befüllen kann. Vorteil: Sollte ein Benutzer mal zwischen Domains oder Forests wandern (z.B. Firmenumstrukturierung), kann man seinen ConsistencyGuid mitnehmen und somit die Cloud-Identität beibehalten. Azure AD Connect (seit Version 1.1.553) bietet im Setup direkt die Option, ms-DS-ConsistencyGuid als SourceAnchor zu nutzen. In Entra ID selbst wird der Anchor als ImmutableID gespeichert. Wenn Sie also mal im Entra ID PowerShell/Graph bei einem User ImmutableId sehen – das ist der kopierte Quellanker aus dem AD.

Matching und Zusammenführen von Identitäten: Ein häufiger Fall in Projekten: Es existiert bereits ein Cloud-Benutzer (vielleicht angelegt vor der Hybrid-Ära oder via anderer Prozesse) und nun soll dieser mit dem AD-Benutzer „zusammengeführt“ werden, damit er künftig aus dem AD synchronisiert wird. Azure AD Connect nutzt für solche Fälle ein Matching-Verfahren. Standardmäßig erfolgt ein sogenanntes Soft-Match über die UPN (User Principal Name) oder SMTP-Adresse: Wenn ein synchronisierter AD-Benutzer in Entra ID einen bestehenden Cloud-Benutzer mit identischem UPN oder E-Mail findet, nimmt der Sync diesen als das gleiche Objekt an und übernimmt ihn unter die Fittiche des Syncs. Voraussetzung: Der Cloud-Account darf bisher nicht durch einen anderen AD-Account gematcht worden sein. Alternativ gibt es den Hard-Match: Dabei setzt man im bestehenden Entra ID Konto manuell das ImmutableID auf den Wert des AD-Accounts (z.B. via PowerShell). So zwingt man praktisch die Verknüpfung. Dieses Vorgehen kommt z.B. bei Migrationen zum Einsatz. Wichtig zu wissen: Das Matching richtet sich nach Konfiguration – in Multi-Forest-Szenarien kann man festlegen, welche Attributkombination zur Identitätsvereinigung genutzt wird (z.B. Mail-Attribut). Durch sorgfältiges Matching vermeidet man Dubletten. Falls doch mal doppelte Benutzer entstehen (ein „John Doe“ aus AD und ein vorhandener „John Doe“ Cloud-only), sollte man entscheiden, welchen man behält und den anderen bereinigen. Im schlimmsten Fall: Cloud-Benutzer löschen (oder umbenennen), damit der Sync das AD-Konto neu in die Cloud schreibt – aber besser, es gar nicht so weit kommen lassen und im Vorfeld matchen.

Attributfluss und Normalisierung: Entra ID Connect bringt von Haus aus eine Menge vordefinierter Synchronisierungsregeln mit, die festlegen, welches Attribut aus AD wohin in Entra ID fließt. Beispiel: givenName (Vorname), sn (Nachname) und userPrincipalName werden standardmäßig übernommen. Zusätzlich können Attribute transformiert oder normalisiert werden. Ein klassisches Beispiel ist die Normalisierung der User Principal Names: Viele Firmen haben in AD UPNs in Groß-/Kleinschreibung gemischt – Azure AD macht daraus meist alles klein (da Logins oft case-insensitive sind, will man Konsistenz). Auch Umlaute oder Sonderzeichen in Loginnamen werden bereinigt (z.B. „Müller“ wird zu „Mueller“ in der Cloud-UPN, wenn die Domäne keine Umlaute unterstützt). Es ist ratsam, schon im AD auf konsistente Namensstrategien zu achten: etwa Format „vorname.nachname@firma.com“ für den UPN und die Haupt-E-Mail. Azure AD Connect übernimmt per Default die Mail-Adresse aus dem AD (falls vorhanden) als Proxy-Adresse in der Cloud. Wenn das AD keine Mail-Adresse führt, generiert Entra ID auf Basis des UPN eine Standard-Mailadresse (@<tenant>.onmicrosoft.com), was meist nicht wünschenswert ist. Daher sollte man vor dem ersten Sync prüfen, dass alle User einen gültigen UPN-Suffix haben, der der E-Mail-Domäne entspricht, und idealerweise eine Mail-Adresse im AD eingetragen ist.

Namenskonflikte und -strategien: In einem Unternehmen mit mehreren „Max Mustermann“ muss sichergestellt werden, dass Benutzer eindeutig benannt sind. Strategien wie das Anhängen von Ziffern oder der zweite Vorname als Initiale (MaxM2 für den zweiten Max Mustermann) sollten definiert sein – das verhindert Kollisionen bei UPN/Email. Azure AD Connect selbst hat keine Magie, um Namenskonflikte aufzulösen; es synchronisiert was im AD steht. Stoßen zwei identische UPNs auf einen Tenant, wird einer der beiden nicht synchronisiert und als Fehler protokolliert. Daher: Einheitliche Richtlinien im AD für BenutzerIDs wirken sich direkt auf eine saubere Cloud-Synchronisierung aus.

Schemaerweiterungen und zusätzliche Attribute: Oft kommt die Frage auf: „Wir haben benutzerdefinierte AD-Attribute – können wir die auch synchronisieren?“ Die Antwort: Ja, Azure AD Connect lässt zu, sog. Directory Extensions zu synchronisieren (beliebige Schema-Attribute, die nicht standardmäßig vorgesehen sind). Bis zu 100 weitere Attribute können als „Erweiterungen“ in Entra ID übertragen werden, wo sie dann bei Bedarf über Graph API oder andere Anwendungen ausgelesen werden können. Beispiel: Mitarbeiternummer, Kostenstelle oder sonstige Meta-Daten. Cloud Sync unterstützt zumindest die gängigen Erweiterungsattribute 1-15 und einige custom Attribute, ist aber (Stand 2025) noch nicht so flexibel wie der klassische Connect, wenn es um völlig frei definierte Mappings geht. Generell sollte man sich jedoch fragen: Welche Daten sollen wirklich in der Cloud landen? Aus Compliance-Sicht ist weniger oft mehr. Persönliche Daten, die in M365 keinen Nutzen haben, müssen nicht synchronisiert werden. Daher: Attributfluss bewusst planen und ggf. Filter einsetzen (Azure AD Connect erlaubt z.B. das Filtern anhand von Attributwerten, Cloud Sync noch nicht in dem Umfang). Ein Beispiel für Filter: Nur Nutzer mit employeeID gesetzt synchronisieren, oder Konten mit adminDescription=SyncToCloud aufnehmen – solche Filter können definieren, welche Objekte überhaupt hochwandern.

Konfiguration & Betrieb

Die Theorie sitzt – jetzt wird’s praktisch: Wie richtet man Entra ID Sync ein, und was ist im laufenden Betrieb zu beachten? Hier geben wir einen Überblick als Schritt-für-Schritt-Anleitung sowie kleine „Runbooks“ für gängige Aufgaben. Außerdem zeigen wir, wie sich vieles per Skript und Automation erledigen lässt, damit der Betrieb effizient bleibt.

Schritt-für-Schritt: Einrichtung von Entra ID Connect Sync

Die klassische Variante, Entra ID Connect Sync (Azure AD Connect), wird mit einem Installationsassistenten eingerichtet:

1. Vorbereitung: Stellen Sie sicher, dass Sie ein Windows-Server-System bereit haben (VM oder physisch, kein Muss aber empfohlen: kein Domänencontroller, sondern Mitgliedsserver). Installieren Sie die neueste Version von Azure AD Connect (Download von Microsoft-Seite). Überlegen Sie vorab, welches AD-Konto der Sync verwenden soll – Standard ist, Azure AD Connect erstellt ein lokales SA-Konto, besser ist ein gMSA (Group Managed Service Account) mit minimalen Rechten. Prüfen Sie auch, dass in Entra ID ein globaler Administrator-Account für die Konfiguration zur Verfügung steht und alle nötigen Domänen in Entra ID als „verified“ eingetragen sind (DNS-Bestätigung).
2. Installation starten: Führen Sie den Azure AD Connect Installer aus. Wählen Sie Benutzerdefinierte Installation (Custom), außer Ihr Szenario ist wirklich das einfache Single-forest/PHS, dann ginge auch Express.
3. Domains und Forests anbinden: Geben Sie die Zugangsdaten für Ihre AD-Forest(s) an. Bei mehreren Forests fügen Sie alle hinzu. Azure AD Connect überprüft die Konnektivität und Berechtigungen. Legen Sie fest, ob Sie ein bestehendes AD-Konto nutzen oder Azure AD Connect ein neues Dienstkonto anlegen soll. Nutzen Sie hier bevorzugt die Option für verwaltete Dienstkonten (gMSA).
4. Anmeldemethode wählen: Der Assistent fragt, welche Sign-In-Methode Sie einsetzen wollen – Password Hash Sync, Pass-Through Auth oder Federation (wie zuvor besprochen). Wählen Sie die gewünschte Option und aktivieren Sie ggf. Seamless Single Sign-On (bequemes SSO via Kerberos-Ticket, empfohlen bei PHS/PTA). Bei Federation werden Sie später durch zusätzliche Schritte zum Einrichten der AD FS Farm geführt (inkl. Zertifikatsangaben).
5. Sync-Scope festlegen: Wählen Sie aus, welche OUs oder Domänen synchronisiert werden sollen. Standardmäßig wird alles synchronisiert, was Benutzer, Gruppen und Kontakte betrifft. In vielen Fällen will man aber System- und Service-Accounts oder bestimmte OUs ausschließen – hier können Sie Häkchen setzen. Bei Cloud Sync würde man an ähnlicher Stelle im Portal die OU-Filter definieren.
6. Optional: Attributfilter & Erweiterungen: Im Custom Setup können Sie weiter klicken zu „Optional Features“. Hier lassen sich z.B. Exchange Hybrid Mode, Passwort Writeback, Gruppen-Writeback etc. einschalten, falls benötigt (mehr dazu im Kapitel Zusatzfunktionen). Sie können auch Directory Extension-Attribute zum Sync auswählen. Treffen Sie Ihre Auswahl bewusst – was jetzt aktiviert wird, landet später in der Cloud.
7. Konfiguration abschließen: Nachdem alle Einstellungen getroffen sind, führen Sie die Installation aus. Azure AD Connect konfiguriert den Synchronisierungsdienst, legt den Initial-Export an und startet direkt eine vollständige Synchronisierung (Initial Sync). Im Anschluss können Sie im Synchronization Service Manager (der GUI des Sync-Dienstes) oder im Azure Portal (Azure AD > Azure AD Connect) prüfen, ob die Synchronisierung erfolgreich war. Typische Dauer des ersten Syncs hängt von der Objektzahl ab – ein paar Tausend Objekte gehen in Minuten, Zehntausende dauern ggf. Stunden.
8. Überprüfen und anpassen: Sind alle gewünschten Benutzer in Entra ID sichtbar? Haben sie den richtigen UPN und E-Mail? Jetzt ist Zeit für Feintuning: Vielleicht müssen weitere OUs einbezogen werden oder ein Attribut angepasst. Änderungen lassen sich nachträglich im Azure AD Connect Wizard vornehmen (Stichwort „Rekonfiguration“). Kritische Änderungen besser zuerst am Staging-Server testen (falls vorhanden).
9. Staging-Server einrichten (optional): Für Hochverfügbarkeit richten Sie einen zweiten Server mit Azure AD Connect im Staging Mode ein (gleicher Ablauf bis auf letzten Schritt „aktivieren als Staging“). Dieser bleibt passiv bereit, bis ein Ausfall passiert oder Sie manuell umschalten.

Schritt-für-Schritt: Einrichtung von Entra ID Cloud Sync

Die Cloud-Variante erfordert ein etwas anderes Vorgehen, verteilt zwischen lokalem Agent und Azure Portal:

1. Vorbereitung: Stellen Sie pro AD-Forest mindestens einen Windows-Server bereit (kann ein Domain Controller sein, aber ein Member-Server ist oft besser aus Sicherheitsgründen). Dieser Server braucht Internetzugang, um mit Entra ID zu kommunizieren. In Entra ID sollte ein globaler Admin verfügbar sein. Legen Sie in AD am besten ein gMSA für den Cloud Sync Agent an (der Installations-Assistent kann das auch automatisch, wenn Sie möchten).
2. Agent-Installation: Melden Sie sich im Azure Portal an und navigieren zu Entra ID > Azure AD Connect > Cloud Sync. Dort erstellen Sie eine neue Cloud Provisioning-Konfiguration. Der Assistent fordert Sie auf, den Provisioning Agent herunterzuladen. Installieren Sie den Agent auf dem vorbereiteten Server. Während der Installation werden Sie aufgefordert, sich mit Entra ID Admin-Rechten anzumelden, um den Agent beim Tenant zu registrieren. Weisen Sie dem Agent im Installationsdialog das gMSA-Konto zu (oder lassen Sie ihn ein Dienstkonto erstellen).
3. Konfiguration in der Cloud: Nach erfolgreicher Installation erscheint der Agent im Azure Portal als „verbunden“. Nun können Sie im Cloud Sync Konfigurationsassistenten die Details festlegen: Wählen Sie den AD-Connector (der Agent, bzw. die AD-Quelle), definieren Sie die Scoping-Filter (also welche Domains/OUs synchronisiert werden – ähnlich wie bei AD Connect). Standardmäßig werden alle Benutzer, Gruppen und Kontakte aus dem gesamten Forest synchronisiert; schränken Sie es hier auf benötigte OUs ein, um z.B. Test- und Servicekonten auszuklammern.
4. Attribut-Mapping prüfen: Der Cloud Sync Assistent zeigt eine Mapping-Liste aller Attribute, die synchronisiert werden. In vielen Fällen genügt die Standardzuordnung. Sie können aber Anpassungen vornehmen, z.B. bestimmte Attribute vom Sync ausschließen. Beachten Sie: Cloud Sync bietet (noch) nicht die volle Flexibilität von Azure AD Connect, aber die gängigsten Mappings sind editierbar.
5. Optionen setzen: Aktivieren Sie ggf. zusätzliche Features wie Password Writeback, falls Ihre Lizenz das hergibt und Sie es nutzen möchten, oder Group Writeback (in Cloud Sync evtl. Preview-Funktion). Auch hier kann Exchange Hybrid Writeback relevant sein – wenn Sie Exchange Online im Einsatz haben, belassen Sie das Mapping dafür auf aktiviert.
6. Starten und überwachen: Speichern Sie die Konfiguration. Die Cloud beginnt nun, die Synchronisierung durchzuführen. Im Azure Portal sehen Sie unter Entra ID > Provisioning den Status der Cloud Sync. Es wird auch angezeigt, wann der letzte Zyklus lief, wie viele Objekte verarbeitet wurden und ob Fehler auftraten. Der initiale Sync kann ein paar Minuten dauern. Nutzen Sie die Zeit, um schon einmal einen zweiten Agent auf einem anderen Server zu installieren (für HA). Dieser zweite Agent wird automatisch der bestehenden Konfiguration hinzugefügt – im Portal sehen Sie dann beide als aktiv.
7. Validieren: Kontrollieren Sie wie bei Azure AD Connect, ob die erwarteten Objekte in Entra ID erscheinen. Cloud Sync arbeitet typischerweise kontinuierlich (alle 2-3 Minuten ein Cycle für Änderungen), so dass neue Objekte ziemlich schnell in der Cloud auftauchen sollten. Wenn etwas fehlt, überprüfen Sie die Filter und Mapping-Einstellungen. Häufige Stolpersteine: falsche OU ausgewählt oder Attribut wie UPN nicht passend (z.B. UPN-Suffix nicht verifiziert in Entra).
8. Betrieb aufnehmen: Die Cloud Sync Lösung erfordert nach dem Setup wenig lokale Pflege – der Agent aktualisiert sich automatisch. Sie sollten jedoch wie bei Connect Sync alle Änderungen am AD-Schema oder größeren Umstrukturierungen im Auge behalten, da diese Auswirkungen auf den Sync haben können.

Mini-Runbooks: Häufige Aufgaben im Betrieb

Im laufenden Betrieb tauchen immer wieder Routineaufgaben auf. Hier ein paar Beispiele inklusive Tipp, wie man sie bewältigt:

• Neue OU in den Sync aufnehmen: Ihre AD-Admins haben eine neue OU für Benutzer angelegt und nun sollen diese Accounts auch in M365 erscheinen. Vorgehen: Öffnen Sie auf dem Azure AD Connect Server die Synchronisierungs-Konfiguration (Azure AD Connect Wizard), gehen Sie zu „Verzeichnisse verbinden“ > „OU-Filters“ und setzen Sie ein Häkchen bei der neuen OU. Beenden Sie den Wizard – dadurch wird automatisch ein Delta-Sync angestoßen. Bei Cloud Sync navigieren Sie im Portal zur entsprechenden Konfiguration und fügen die OU im Scope-Filter hinzu. Speichern, und der Cloud-Provisioning-Dienst kümmert sich um den Rest.
• Synchronisierung manuell anstoßen: Normalerweise laufen alle 30 Minuten (Azure AD Connect) bzw. alle paar Minuten (Cloud Sync) automatische Sync-Zyklen. Manchmal will man aber sofort Änderungen hochspielen (z.B. wenn man nicht auf den nächsten Turn warten kann). Vorgehen für Connect: Melden Sie sich am Sync-Server an und starten Sie PowerShell mit Admin-Rechten. Führen Sie den Befehl Start-ADSyncSyncCycle -PolicyType Delta aus. Damit erzwingen Sie eine Delta-Synchronisierung (nur Änderungen). Für eine vollständige Synchronisierung nutzen Sie -PolicyType Initial. Bei Cloud Sync gibt es die Option „Provision on demand“ über Graph-API bzw. im Portal den Button „Provision Now“ in der Preview UI.

# Delta-Synchronisierung manuell starten (Azure AD Connect Sync Server)
Start-ADSyncSyncCycle -PolicyType Delta

• Benutzer vom Sync ausschließen: Gelegentlich soll ein bestimmtes Konto nicht mehr via Entra ID Sync verwaltet werden (z.B. ein Sonderaccount). Vorgehen: Der saubere Weg ist, das Objekt aus der Sync-Range zu entfernen – also entweder in eine OU zu verschieben, die nicht synchronisiert wird, oder ein Attribut-Filter zu nutzen. In Azure AD Connect kann man z.B. eine Regel definieren: „wenn extensionAttribute15 = NoSync dann filtere Objekt raus“. Setzen Sie dieses Attribut im AD bei dem Benutzer und führen Sie einen Sync aus. Das Objekt wird daraufhin in Entra ID als „entfernt“ behandelt (sprich: gelöscht, sofern es nicht mehr in einem anderen Scope auftaucht). Vorsicht: Gelöscht heißt in Entra ID „recycled“ – es ist 30 Tage im Papierkorb. Falls der Ausschluss ein Versehen war, können Sie also innerhalb von 30 Tagen den User einfach wieder ins Sync aufnehmen und er „lebt“ wieder auf.
• Wechsel der Authentifizierungsmethode: Ihre Geschäftsleitung beschließt, dass zukünftig kein AD FS mehr betrieben werden soll – man möchte auf PHS umstellen. Vorgehen: In Azure AD Connect Wizard können Sie die Sign-In-Option ändern. Falls Sie von Federation zu Cloud-Auth wechseln, müssen Sie auch die Domänen in Entra ID „entföderieren“. Azure AD Connect hilft dabei (es gibt die Option „Konfiguration der Benutzeranmeldung ändern“). Alternativ per PowerShell: Mit Convert-MsolDomainToStandard -DomainName firma.com -SkipUserConversion $true -PasswordFile users.txt (für Wechsel zu PHS) oder Convert-MsolDomainToFederated (für zurück zu ADFS) können Sie umschalten. Immer daran denken, parallel PHS schon aktiviert zu haben, damit der Wechsel reibungslos ist.
• Update & Wartung von Sync-Servern: Microsoft bringt regelmäßig Updates für Azure AD Connect heraus (v2.x). Planen Sie ein, diese alle paar Monate einzuspielen, insbesondere wenn Sicherheitsupdates dabei sind. Vorgehen: Führen Sie das Upgrade-Paket auf dem Staging-Server zuerst aus; prüfen Sie, ob alles läuft. Schalten Sie dann um (Staging wird aktiv) und aktualisieren den ehemals aktiven Server. Bei Cloud Sync Agents erfolgt das Update automatisch via Microsoft Update – hier genügt es zu überwachen, dass die Agenten die neueste Version haben (im Portal sichtbar). Achten Sie auch darauf, dass sich Service-Accounts (sofern kein gMSA) rechtzeitig ändern lassen: Azure AD Connect’s AD-Konto kann per Synchronization Service Manager unter „Connectors“ -> Properties -> „Connect to AD Forest“ angepasst werden, falls das Passwort ausläuft.

Automatisierung: PowerShell, CLI & Graph im Einsatz

Gerade in größeren Umgebungen lohnt es sich, wiederkehrende Aufgaben zu automatisieren. Microsoft bietet hierfür mehrere Werkzeuge:

• Azure AD PowerShell Module / Microsoft Graph PowerShell: Viele Einstellungen in Entra ID lassen sich per PowerShell skripten – etwa das Aktivieren von Passwort-Rückschreibung, das Auslesen der Synchronisierungsstatistiken oder das Onboarden neuer Benutzer mit Lizenzen. Beispiel: Mit dem Cmdlet Get-MsolUser -SynchronizationStatus -eq „PendingImport“ (im alten MSOnline-Modul) konnte man Benutzer abfragen, die noch nicht vollständig synchronisiert sind. Inzwischen wandert vieles zur Graph API: Das Microsoft Graph PowerShell SDK erlaubt z.B. Abfragen wie:

Connect-MgGraph -Scopes „User.Read.All“
Get-MgUser -Filter „onPremisesSyncEnabled eq true“ -Property „displayName,onPremisesLastSyncDateTime“

Dieser Befehl würde alle synchronisierten Benutzer mit ihrem letzten Sync-Zeitstempel auflisten. Solche Informationen kann man nutzen, um etwa einen Alert zu senden, wenn schon länger kein Sync mehr bei bestimmten Objekten stattfand.

• Azure CLI / REST-API: Für einige Aspekte (z.B. das Management von Entra ID Cloud Sync Konfigurationen) gibt es direkte API-Endpunkte. Fortgeschrittene Anwender können über das Microsoft Graph API automatische Provisionierungsflüsse konfigurieren oder on-demand Synchronisation anstoßen. Ein Szenario: Wenn ein Mitarbeiter im HR-System angelegt wird, könnte ein Script über Graph den Cloud Sync Provisioning Job triggern, um nicht auf den nächsten Intervall zu warten.
• Skripting des Sync-Servers: Nicht vergessen sollte man die lokale Automatisierung auf dem Sync-Server. Das AD Sync Modul (MIIS/ADSynchronizationService) bietet Cmdlets, um z.B. einen Export oder Import zu forcieren, ohne die GUI zu bemühen. Auch Backup-Skripte für die Synchronisierungsdatenbank oder die Konfiguration lassen sich erstellen (Azure AD Connect hat einen integrierten Mechanismus, die aktuelle Konfiguration in eine ADSyncConfig.xml zu exportieren – dies kann man zeitgesteuert ausführen lassen).

Ob CI/CD-Pipeline für Identity-Provisioning oder einfach ein cron-jobähnliches Script, das jeden Morgen prüft, ob der letzte Sync erfolgreich war – nutzen Sie die Möglichkeiten der Automatisierung. So stellen Sie sicher, dass Entra ID Sync nicht zur „Black Box“ wird, sondern ein transparent überwachter und steuerbarer Prozess bleibt.

Sicherheit & Compliance

Bei der Synchronisierung von Verzeichnisdaten darf die Sicherheit keinesfalls zu kurz kommen. Schließlich verbindet Entra ID Sync Ihre sensibelsten Verzeichnisdienste miteinander und enthält Zugänge und Daten zu sämtlichen Nutzerkonten. Hier sind die wichtigsten Aspekte, um die Lösung sicher und compliant zu betreiben:

Least Privilege – nur die nötigsten Rechte

Das Motto „so viele Rechte wie nötig, so wenige wie möglich“ gilt auch hier. Beginnen wir beim lokalen AD: Das Konto, mit dem Azure AD Connect auf das AD zugreift, benötigt keine Domain-Admin-Rechte im täglichen Betrieb! Der Installationsassistent richtet standardmäßig ein Konto mit den notwendigen Berechtigungen ein – vor allem das Recht, Verzeichnisänderungen zu replizieren (Replicate Directory Changes auf Domänenebene), um Passwörter und alle Objekte auszulesen. Mehr braucht es normalerweise nicht. Nutzen Sie bevorzugt ein Group Managed Service Account (gMSA) für diesen Zweck, dann müssen Sie sich um Passwortwechsel keine Sorgen machen und das Konto kann sich nicht interaktiv anmelden. Ähnliches Prinzip auf der Azure-Seite: Azure AD Connect erstellt bei der Einrichtung ein Service-Prinzipal in Entra ID (oft erkennbar am Namen Sync_<GUID>@…), das die Synchronisierung vornimmt. Fassen Sie dieses Konto nicht an und verleihen Sie ihm keine zusätzlichen Rechte. Bei Cloud Sync registriert sich der Agent als Enterprise-App in Entra ID und nutzt einen Prinzipal mit beschränkten Rechten nur für die Provisionierung. Halten Sie die Gruppe der Global Admins klein und verwenden Sie für den Betrieb nach Möglichkeit Konten mit weniger Rechten (z.B. den Azure AD „Hybrid Identity Administrator“-Role für Sync-Themen statt immer Global Admin).

Geheimnisverwaltung & Schlüsselschutz

Entra ID Sync bringt unvermeidlich ein paar „Geheimnisse“ mit sich: Kennwörter und Zertifikate, die es zu schützen gilt. Zum einen das AD-Konto-Passwort (falls kein gMSA): Dieses ist im Synchronisierungsdienst hinterlegt. Stellen Sie sicher, dass es regelmäßig geändert wird und niemand außer dem Sync-Dienst kennt. Der Synchronisierungsserver verschlüsselt gespeicherte Credentials in seiner Datenbank – diese ist wiederum mit einem automatischen Schlüssel abgesichert. Sie können bei Azure AD Connect einen eigenen Verschlüsselungsschlüssel verwenden (dafür gibt es PowerShell-Befehle zum Export/Import des Azure AD Connect encryption keys), was in Hochsicherheitsumgebungen relevant sein kann, z.B. für Backup-Wiederherstellungen. In Cloud Sync brauchen Sie sich um das AD-Kennwort nicht zu kümmern, wenn Sie gMSA nutzen – das AD verwaltet es. Zum anderen: Passwörter der Benutzer. Bei PHS werden Kennworthashes an Entra ID übertragen – aber keine Angst, es ist ein Hash des Hashes (Double-HMAC-SHA256), der selbst nicht rückrechenbar ist. Microsoft speichert keine Klartextpasswörter in der Cloud. Dennoch ein heikler Punkt: Nur befugte Personen sollten die PowerShell-Option aktivieren können, PHS an- oder auszuschalten. Bei PTA kommen clientseitig Zertifikate ins Spiel: Jeder PTA-Agent generiert ein Zertifikat, mit dem er sich bei Entra ID für die Weiterleitung der Anmeldungen authentifiziert. Diese Zertifikate liegen im Windows-Zertifikatsspeicher der Agent-Server und sollten dort verbleiben. Geben Sie PTA-Servern kein Zugriffskonto, das jemand für andere Zwecke missbrauchen könnte – die Agenten laufen als lokaler Dienst.

Überwachung & Audit-Logs

Transparenz ist das A und O für Sicherheit. Aktivieren Sie daher die Protokollierung auf allen Ebenen: Azure AD Connect Health (falls lizenziert) überwacht die Synchronisierung und AD FS und warnt bei Problemen. Unabhängig davon: Prüfen Sie regelmäßig die Azure AD Audit Logs im Portal. Dort sehen Sie z.B., wenn durch die Synchronisierung ein Benutzer angelegt, geändert oder gelöscht wurde – inklusive Zeitpunkt und Initiator „Azure AD Connect“. Unerwartete Löschungen (z.B. plötzlich 50 Benutzer entfernt) springen so ins Auge, und Sie können rechtzeitig reagieren (oft sind Massenlöschungen ein Zeichen für Fehlkonfiguration oder einen versehentlichen Import leerer OU). Auch Sign-In Logs spielen eine Rolle: Bei PTA/Federation sollten Sie die Anmeldeprotokolle im Blick haben, um z.B. festzustellen, wenn alle Login-Versuche fehlschlagen (was auf einen Ausfall des Backends hindeutet). Auf AD-Seite lohnt es sich, den Eventlog des Synchronisierungsservers zu überwachen. Azure AD Connect schreibt wichtige Ereignisse (Start, Stop, Errors) in die Windows-Ereignisanzeige (unter „Applications and Services Logs -> Microsoft -> AzureADConnect“ bzw. ähnliches). Ein SIEM-System oder zumindest ein regelmäßiger Review dieser Logs erhöht die Sicherheit. Ebenso wichtig: Änderungen an der Konfiguration sollten nachvollziehbar sein. Führen Sie eine Art Change-Protokoll, wer wann die Sync-Config geändert hat (z.B. OU hinzugefügt). Da Azure AD Connect keine Nutzerverwaltung hat, lässt sich das nur prozessual lösen (d.h. durch interne Doku und Change Management).

Datenschutz und Datenminimierung

Beim Synchronisieren personenbezogener Daten in die Cloud stellt sich automatisch die Compliance-Frage – insbesondere nach DSGVO. Grundsätzlich sollten nur solche personenbezogenen Attribute ins Entra ID wandern, die dort einen Zweck erfüllen. Ein Beispiel: Telefonnummern für die Nutzung von Teams oder Handy-Nummern für MFA sind sinnvoll in der Cloud; Heimadresse oder Sozialversicherungsnummer des Mitarbeiters eher nicht. Azure AD Connect synchronisiert von sich aus nur einen begrenzten Satz Standardattribute (meist geschäftsbezogene Kontaktdaten, Titel, Abteilung etc.). Prüfen Sie diese Liste und deaktivieren Sie notfalls einzelne Attribute, wenn Ihr Unternehmen sie nicht hochladen möchte. Über Attributfilter (in AADC) können Sie auch sagen „synchronisiere Attribut X nicht“. Cloud Sync bietet hier weniger Granularität, da müsste man eher auf Domain/OU-Ebene filtern. Wichtig zu wissen: Microsoft Entra ID speichert die Kundendaten entsprechend den Vereinbarungen in geografisch bestimmten Rechenzentren. Für europäische Tenants bedeutet das, dass Identitätsdaten in der EU verbleiben (Standort z.B. Dublin oder Amsterdam). Es gelten die strengen Sicherheitsstandards von Microsofts Clouddiensten – Zertifizierungen wie ISO 27001, SOC und natürlich eine Auftragsverarbeitung gemäß DSGVO sind vorhanden. Dennoch bleibt der Grundsatz der Datensparsamkeit empfehlenswert: Weniger Daten in der Cloud = weniger Risiko bei etwaigen Zwischenfällen.

Härtung der Systeme

Last but not least: Härten Sie die beteiligten Systeme, als hinge Ihre Domain davon ab – denn genau das tut sie! Der Azure AD Connect Server sollte als kritisches System behandelt werden, vergleichbar einem Domänencontroller. Er gehört idealerweise in die höchste Sicherheitsstufe (Tier 0 im Active-Directory-Tiering-Modell). Nur Admin-Benutzer mit spezieller Berechtigung sollten darauf zugreifen dürfen. Installieren Sie keine unnötige Software auf diesem Server, und schon gar keine Benutzeranmeldungen für Daily Business. Das gleiche gilt für Cloud Sync Agent Server: Diese haben zwar wenig Angriffsfläche, aber laufen mit erhöhten Rechten in der Domäne (lesen alle User-Daten) – kompromittiert man einen solchen Server, könnte man Sync-Daten manipulieren oder abgreifen. Setzen Sie also klassische Maßnahmen um: aktuelle Patches einspielen, Firewall so konfigurieren, dass nur die nötigen Verbindungen offen sind (z.B. der Sync-Server muss ins Internet zu Azure, aber muss nicht für jede eingehende Verbindung offen sein). Auf Netzwerkebene segmentieren Sie idealerweise die Synchronisierungsserver weg von normalen Arbeitsplatznetzen. Überwachen Sie auch hier verdächtige Aktivitäten: z.B. wenn jemand versucht, auf dem Sync-Server eine Anwendung mit GUI zu starten – warum sollte das passieren? Im AD FS-Fall: härten Sie Ihre AD FS-Server und Proxies ebenfalls maximal, da diese exponiert sind (Mindestsicherung: WAF/Load Balancer mit IP-Filtering, regelmäßige Zertifikatpflege, bruteforce-Schutz via Extranet Lockout etc.). Fazit: Entra ID Sync ist mächtig, aber wie ein Brückenkopf zwischen On-Prem und Cloud – sorgen Sie dafür, dass diese Brücke gut bewacht und stabil gebaut ist.

Überwachung, KPIs & Troubleshooting

Auch nach erfolgreicher Implementierung darf man Entra ID Sync nicht einfach sich selbst überlassen. Eine kontinuierliche Überwachung stellt sicher, dass Probleme früh erkannt werden. Zudem sollten klare Kennzahlen (KPIs) definiert werden, um den Betriebszustand zu messen. Und wenn mal etwas klemmt, hilft ein strukturiertes Troubleshooting mit Checkliste.

Zielwerte definieren: Was bedeutet „Sync läuft gut“ überhaupt messbar? Hier einige mögliche KPIs und Zielwerte:

• Sync-Intervall: Azure AD Connect synchronisiert standardmäßig alle 30 Minuten. Ziel: < 30 Min Latenz für Änderungen (d.h. eine Änderung im AD ist spätestens nach 30 Min in der Cloud sichtbar). Bei Cloud Sync laufen delta-Syncs alle ~2-3 Minuten – Ziel hier: < 5 Min Latenz.
• Fehlerquote pro Zyklus: Ideal ist 0 Fehler pro Sync-Durchlauf. Ein paar nicht kritische „Exportskipped“ Warnungen (z.B. wegen unveränderter Objekte) sind normal, aber echte Fehler (z.B. „duplicate attribute“) sollten auf < 1% der Objekte begrenzt sein.
• Verfügbarkeit des Dienstes: Der Synchronisierungsdienst sollte 24×7 verfügbar sein mit einer Uptime von >99%. Ausfallzeit bedeuten Stau bei der Datenaktualisierung.
• Durchsatz: Anzahl der verarbeiteten Objekte pro Stunde. Hier gibt es keine harten Zahlen, aber ein Baseline-Wert (z.B. 1000 Objekte/Std im Schnitt) kann helfen, Abweichungen zu erkennen.
• Password Sync Delay: Wenn PHS aktiv ist, die Zeit zwischen Passwort-Änderung on-prem und Übernahme in die Cloud. Ziel: typischerweise <2 Minuten.

Diese Kennzahlen kann man mit Tools überwachen – Azure AD Connect Health liefert z.B. einige davon out-of-the-box (wie letzte Synchronisierungszeit, Fehleranzahl etc.).

Health Monitoring: Falls Ihre Lizenz es zulässt (Azure AD Premium P1/P2), aktivieren Sie Azure AD Connect Health. Dieses Portal zeigt auf einen Blick: ist der Sync aktuell, wie hoch ist die CPU/Memory-Auslastung des Servers, gab es Fehler? Für AD FS gibt es ähnliche Dashboards (Token-Anfragen, Anmeldefehlerquoten etc.). Darüber hinaus lassen sich Warnungen definieren – z.B. E-Mail an Admin, wenn 3 Sync-Durchläufe in Folge fehlschlagen. Ohne Connect Health können Sie eigene Skripte/Monitoring einsetzen: etwa per Windows Performance Counter und Eventlog-Überwachung auf dem Sync-Server. Der Prozess Microsoft.AzureADConnect.SynchronizationService.exe sollte konstant laufen. Ein Event 611 im Verzeichnisdienst-Protokoll könnte einen Fehler anzeigen. Viele Unternehmen integrieren AD Connect auch in bestehende Monitoring-Tools (SCOM, Zabbix etc.) – zumindest ein Ping/Service-Check und Überwachung der letzten Synchronisierungszeit per PowerShell ist sinnvoll.

Alarmierung: Monitoring ohne Alarm nützt wenig. Richten Sie Alerts ein, die z.B. auslösen wenn länger als 60 Minuten kein erfolgreicher Sync stattgefunden hat. Oder wenn die Anzahl der Objekte in der letzten Synchronisierung abrupt stark gefallen ist (Hinweis auf Massenlöschung). Azure AD Connect hat einen eingebauten Schutzmechanismus: Falls plötzlich >500 Objekte auf einmal gelöscht würden, stoppt es und verlangt manuellen Eingriff (dieses Limit ist konfigurierbar). Ein Alarm auf so ein Event ist Gold wert – er warnt davor, dass evtl. durch einen Konfig-Fehler gerade dabei waren, hunderte Konten zu entfernen. Ebenso sollten Sie Alerts für ablaufende Zertifikate (bei AD FS) oder nicht erreichbare PTA-Agenten einrichten. Kurz: alles, was einen Ausfall oder Datenverlust bedeuten könnte, sollte einen lauten Alarm triggern, bevor Benutzer es bemerken.

Häufige Fehlerbilder: Aus Erfahrung lassen sich einige typische Fehlerquellen benennen:

• Klassiker #1: Attribut-Konflikte – z.B. zwei Benutzer mit derselben E-Mail-Adresse im AD. Azure AD lässt diese Kollision nicht zu; einer der beiden scheitert beim Sync mit Fehler „duplicate attribute“. Lösung: Eindeutigkeit im AD herstellen (z.B. unterschiedliche Alias). Ähnliches gilt für UPN-Konflikte.
• Klassiker #2: Unverifizierte UPN-Suffixe – Benutzer hat UPN „alice@contoso.local“, aber diese Domäne kennt Entra ID nicht (weil nur contoso.com verifiziert wurde). Ergebnis: Der User bekommt einen temporären UPN in der *.onmicrosoft.com-Domäne oder synchronisiert gar nicht. Lösung: Entweder UPN-Suffix im AD ändern oder die zusätzliche Domäne in Entra ID hinzufügen und verifizieren.
• Klassiker #3: Große Gruppen – Sie synchronisieren eine Sicherheitsgruppe mit 100.000 Mitgliedern und wundern sich über Fehlermeldungen. Cloud Sync hat Limits (50k Mitglieder pro Gruppe, Stand heute), Connect Sync kann bis 250k verarbeiten, aber jenseits dessen wird’s kritisch. Lösung: Gruppen aufteilen oder dynamische Gruppen in M365 nutzen statt Monstergruppen.
• Klassiker #4: Berechtigungsprobleme – Der Sync hat plötzlich keine Leserechte mehr auf einer OU („stirbt“ mit Access Denied). Vielleicht hat ein eifriger Admin die Berechtigungen im AD verhärtet und dem Sync-Konto den Zugriff entzogen. Lösung: Berechtigungen prüfen, Replicate-Changes-Rechte sicherstellen.
• Klassiker #5: Passwort-Sync geht nicht – Alle anderen Daten syncen, aber Passwörter nicht (Nutzer können sich nicht anmelden). Ursachen: Der Azure AD Connect-Dienst „Password Synchronization“ könnte gestoppt sein (prüfen unter Dienste), oder die notwendigen Berechtigungen fehlen (das Sync-Konto braucht Replicate Directory Changes und Replicate Directory Changes All in AD für PHS). Bei PTA prüfen, ob die Agent-Dienste laufen und Zugang zum Internet haben. Ggf. auch Eventlogs auf Einträge wie „PTA agent unreachable“ checken.
• Klassiker #6: Veralteter Client – Azure AD Connect Version 1.x wird seit längerem nicht mehr unterstützt, oder eine bestimmte Funktion erfordert ein neueres Release. Wenn man jahrelang nicht updated, könnten Kompatibilitätsprobleme auftreten (z.B. Änderung in Graph API). Lösung: Update auf aktuelle Version einspielen.
• Klassiker #7: Rogue Change im AD – Ein Attributwert im AD verletzt die Synchronisierungsregeln (z.B. zu lange Zeichenkette, nicht erlaubtes Format). Der Sync wirft dann einen Error für das Objekt. Beispiel: Ein Attribut enthält einen Wert, der Azure ADs Regex-Prüfung nicht besteht (etwa ein Gruppenname mit unzulässigem Zeichen). Lösung: Korrigieren des Werts im AD gemäß Fehlermeldung.

Die Liste ließe sich fortführen, aber oft hilft schon ein Blick in die Fehlerprotokolle von Azure AD Connect: Im Synchronization Service Manager unter „Operations“ können Sie Deltas anzeigen und sehen genaue Fehlermeldungen mit Objekt- und Attributangabe. Cloud Sync meldet Fehler im Azure-Portal im Provisioning-Log, ebenfalls sehr detailliert. Nutzen Sie diese Hinweise, um Probleme einzugrenzen.

Troubleshooting-Checkliste

Wenn die Synchronisierung nicht tut, was sie soll, gehen Sie systematisch vor. Hier eine Checkliste, die Sie Punkt für Punkt durchgehen können:

1. Basis-Check: Läuft der Sync-Dienst überhaupt? (Dienst „Microsoft Azure AD Sync“ bzw. „Microsoft Entra Provisioning Agent“ prüfen und ggf. neu starten). Ist der Server eingeschaltet und erreichbar?
2. Netzwerkverbindung: Hat der Sync-Server Verbindung zu den benötigten Endpunkten? (AD erreichbar, DNS auflösbar, Internetzugriff zu *.azure.com). Gab es Firewall-/Proxy-Änderungen?
3. Azure AD Portal prüfen: Melden Sie sich im Entra Portal an und schauen unter „Entra ID > Synchronisierung“ nach dem Status. Wann war der letzte erfolgreiche Sync? Zeigt es Fehlermeldungen oder Warnungen?
4. Eventlogs & Health: Öffnen Sie auf dem Server die Ereignisanzeige. Gibt es Errors in den letzten Minuten (Quelle „Directory Synchronization“ oder „Azure AD Connect“)? Falls Azure AD Connect Health im Einsatz: dortige Fehlermeldungen anschauen.
5. Ein spezifischer User/Gruppen fehlt: Suchen Sie gezielt nach dem Objekt in der Metaverse. Im Synchronization Service Manager gibt es unter „Search Connector Space“ die Möglichkeit, ein AD-Objekt per Name oder GUID zu suchen. Finden Sie es? Wenn nein, ist es vermutlich durch Filter ausgeklammert (OU nicht ausgewählt? Attributfilter?). Wenn ja, schauen Sie auf seine „Connector“ – taucht es auch auf der Azure AD Seite auf? Möglicherweise ist es „Disconnectors“ (nicht verknüpft) – dann liegt ein Matching-Problem vor.
6. Attribut-Fehler analysieren: Bei Fehlern im Sync Manager: Doppelklick auf den Fehler-Eintrag, Details lesen. Oft steht dort „Attribute X violates …“ oder „… is already in use by Y“. Diese Info nutzen, um im AD die Korrektur vorzunehmen (z.B. eindeutigen Wert setzen).
7. Passwort-Problem eingrenzen: Können sich alle Nutzer nicht anmelden (dann globales Problem mit Auth) oder nur einzelne? Wenn global: je nach Methode PTA oder PHS Troubleshooting. Bei PTA z.B. in der Powershell Get-AzureADPassThroughAuthenticationAgents ausführen – es zeigt den Status der Agenten (Active/Inactive). Bei PHS: im Ereignislog nach Event IDs für Password Sync suchen (z.B. 614 – Password Sync completed, 611 – error).
8. Synchronisierungsregeln zuletzt geändert? Falls kurz vor dem Auftreten des Problems an der Konfiguration gedreht wurde (neue OU, Filter, Rule edit), überlegen Sie, ob das die Ursache sein könnte. Notfalls den Schritt zurücknehmen und prüfen, ob es dann geht.
9. Online Ressourcen zu Rate ziehen: Die Fehlermeldung googeln (oder besser: „bingen“ 😉) – oft gibt es bereits bekannte Lösungsansätze in TechCommunity oder Doku, gerade bei kryptischen Fehlercodes.
10. Microsoft Support einschalten: Wenn alles nichts fruchtet und es sich um einen hartnäckigen Fehler handelt, zögern Sie nicht, beim Microsoft Support ein Ticket zu eröffnen. Für Azure AD (und damit Entra ID Sync) haben Sie Supportzugriff je nach Lizenz/SLA. Die können oft in den Backend-Logs noch mehr sehen und helfen, ohne dass man ewig im Dunkeln tappt.

Mit dieser Checkliste lösen sich die meisten Probleme recht schnell. Wichtig ist, ruhig und systematisch vorzugehen – meist ist es irgendein Häkchen, Wert oder Dienst, der übersehen wurde. Hat man den Übeltäter gefunden, läuft die Sync-Maschinerie auch bald wieder wie geschmiert.

Zusatzfunktionen & Rückschreiben

Entra ID Sync kann mehr, als nur One-Way die AD-Daten hochladen. Gerade in Enterprise-Umgebungen kommen sogenannte Writeback-Funktionen ins Spiel – das Zurückschreiben bestimmter Objekte oder Attribute aus der Cloud ins lokale AD. Darüber hinaus bietet Entra ID Möglichkeiten für automatische Provisionierung via SCIM, etwa in HR-Szenarien. Schauen wir uns die wichtigsten Erweiterungen an:

Passwort-Rückschreibung (Password Writeback)

Stellen Sie sich vor, ein Mitarbeiter nutzt die Self-Service Password Reset (SSPR) Funktion in der Cloud, um sein vergessenes Kennwort zurückzusetzen – und sein AD-Kennwort wird dabei automatisch mitgeändert. Genau das leistet Password Writeback. Ist diese Option aktiviert (erfordert Azure AD Premium Lizenzierung), dann synchronisiert Azure AD Connect eine Passwortänderung in beide Richtungen: AD → Cloud sowie Cloud → AD. In der Praxis bedeutet das: Admins oder Benutzer können Passwörter via Azure AD ändern, z.B. im Microsoft 365 Portal oder per SSPR, und Azure AD Connect setzt das neue Passwort im On-Prem-AD. Sicherheit ist dabei gewährleistet – die Übertragung erfolgt verschlüsselt und der Vorgang wird im Eventlog festgehalten. Wichtig: Für SSPR mit Writeback muss der Azure AD Connect-Account in AD das Recht haben, Passwörter zu setzen (Reset-Password-Rechte auf die User-OU). Der Assistent richtet das bei Aktivierung automatisch ein. Password Writeback ist ein „Must-have“ Feature, um echten Identity-Life-Cycle zu erreichen, denn es erspart dem Helpdesk viele Anrufe á la „Ich hab mein AD-Passwort vergessen, aber im Office-Portal konnte ich es ändern – warum geht mein PC-Login nicht?“.

Gruppen- und Kontakt-Writeback

Cloud-only Gruppen in On-Premises verfügbar machen? Auch das geht: Mit Group Writeback kann Azure AD Connect z.B. Office 365 Groups (auch bekannt als Microsoft 365 Groups) zurück ins lokale AD schreiben. Diese erscheinen dann dort als verteilerlistenähnliche Objekte (Mail-aktivierte Sicherheitsgruppen, je nach Konfiguration). Use Case: Ihr Unternehmen nutzt Teams (dahinter stecken O365 Groups) und Sie wollen diese Gruppen auch On-Prem in Exchange verteilen oder für ACLs verwenden. Group Writeback legt in einer definierten OU (standardmäßig „Azure AD Groups“) für jede entsprechende Cloud-Gruppe ein AD-Objekt an und hält die Mitgliedschaften aktuell. Man sollte bedenken, dass nicht alle Cloud-Gruppentypen unterstützt sind (dynamische Gruppen eher nicht, Stand heute), und es entsteht ein Mehraufwand an Objekten im AD. Aber für die Integration von Cloud-Gruppen in lokale Anwendungen kann es sehr nützlich sein.

Ähnlich funktioniert Contact Writeback: Hierbei werden Kontakte, die in Entra ID (bzw. Exchange Online) vorhanden sind, ins lokale AD als Kontaktobjekte geschrieben. Das Szenario dahinter: Sie pflegen z.B. externe Kontakte in Exchange Online (weil Mitarbeiter sie im Outlook Adressbuch brauchen). Ohne Writeback bleiben diese nur in der Cloud sichtbar. Mit Contact Writeback haben Sie plötzlich auch im lokalen GAL (Global Address List) entsprechende Kontakte, was die Einheitlichkeit steigert. Azure AD Connect kann diese Option im Hybrid-Modus aktivieren. Besonders in Exchange-Hybrid-Organisationen sorgt das dafür, dass Cloud-Kontakte on-prem verfügbar sind und vice versa, sodass ein global einheitliches Adressbuch entsteht.

Geräte-Writeback (Device Writeback)

In modernen Arbeitsumgebungen spielen Geräteidentitäten eine Rolle – Stichwort Azure AD Join und Intune. Device Writeback ermöglicht es, dass Azure AD registrierte Geräte (z.B. via Azure AD Join oder Hybrid Join) im lokalen AD als Geräteobjekte (in der Container „Registered Devices“) angelegt werden. Warum? Zum einen konnte man damit in Verbindung mit AD FS durch Conditional Access Richtlinien auf Gerätecompliance prüfen („Nur Domänen-PCs dürfen XYZ“ – AD FS schaut ins AD-Geräteobjekt). Zum anderen lassen sich so im ConfigMgr oder anderen on-prem Tools die existierenden Azure AD Geräte referenzieren. Microsoft selbst propagiert inzwischen allerdings einen anderen Weg: Für Windows Hello for Business gibt es den Cloud Trust (Kerberos-TGT ohne Device Writeback), und generell ist Device Writeback in Cloud-Only Szenarien nicht mehr zwingend erforderlich. Dennoch, wer z.B. noch AD FS nutzt oder bestimmte Legacy-Anwendungen hat, kann Device Writeback in Azure AD Connect aktivieren. Voraussetzung: Active Directory Schema auf 2016 Niveau (Geräteobjekte) und eine Enterprise Mobility + Security (EMS) Lizenz, meine ich. Sobald aktiviert, werden Hybrid Azure AD Join-Geräte brav auch im AD geführt.

SCIM und HR-Provisionierung

Neben der AD<->Entra Synchronisierung gibt es noch die „andere Richtung“: Provisionierung von der Cloud zu anderen Systemen, oder aus HR-Systemen ins AD. Hier kommt SCIM ins Spiel – das System for Cross-domain Identity Management. Microsoft Entra ID beherrscht SCIM 2.0 als Protokoll, um Benutzerkonten automatisiert in Drittsystemen zu erstellen oder zu entfernen. Beispiel: Ihr Unternehmen nutzt eine SaaS-Anwendung wie Salesforce oder ServiceNow. Anstatt Benutzer dort manuell anzulegen, können Sie in Entra ID eine Anwendungs-Provisionierung einrichten. Azure AD agiert dann als Identity Hub und spricht via SCIM mit der Anwendung – jedes Mal, wenn ein Benutzer in Entra ID einer App zugewiesen wird, wird er in der App per SCIM API angelegt (oder deaktiviert, wenn entfernt). Das erleichtert das Onboarding/Offboarding in zig Cloud-Anwendungen enorm und sorgt für konsistente Zugriffsverwaltung.

Noch spannender ist HR-driven Provisioning: Hierbei wird ein HR-System wie Workday oder SAP SuccessFactors zur Quelle. Microsoft Entra ID kann über vordefinierte Konnektoren die Daten von Workday abrufen und dann Benutzer in AD und Entra ID anlegen. Praktisch läuft es so: der Entra Cloud Provisioning Service greift auf die Workday API zu, zieht neue Personaldatensätze und legt anhand definierter Regeln Konten im On-Prem AD an (mithilfe des Cloud Sync Agent). Von dort gehen sie dann per normalem Sync weiter ins Entra ID. Änderungen wie Abteilungswechsel oder Austritt werden genauso übernommen (Deaktivierung/Sperren von Accounts). Das Ganze ist quasi ein Ersatz für klassische Identity-Manager-Lösungen, maßgeschneidert für die Kopplung HR -> AD -> Azure AD. Natürlich muss man initial Aufwand investieren (Mapping-Logik, Attribut-Abgleich definieren), aber Microsoft liefert für einige HR-Systeme Templates. SCIM kommt hier ebenfalls zum Einsatz, wenn auch teils proprietär erweitert. Für Firmen mit hohem Personalwechsel oder komplexen HR-Prozessen ist das ein Segen: Man pflegt die Daten nur im HR-System, der Rest läuft automatisch bis hin zum Azure AD Konto mit Lizenz. Wichtig: Für HR-Provisioning benötigt man i.d.R. Azure AD Premium P2 Lizenzen, da es zum Identity Governance Bereich gehört.

Exchange-Hybrid-Integration

Kein Bereich ist so eng mit dem AD verbunden wie Exchange. Wenn Sie Exchange Server on-prem und Exchange Online (M365) hybrid betreiben, ist Azure AD Connect ohnehin Pflicht – denn es synchronisiert alle Exchange-relevanten Attribute (Mail-Adressen, Alias, Richtlinien etc.) zwischen AD und Azure AD. Im Hybrid Setup gibt es ein paar besondere Kniffe: Azure AD Connect hat die Option Exchange Hybrid. Ist diese aktiviert, werden bestimmte Attribute aus Exchange Online zurück ins lokale AD geschrieben, damit beide Umgebungen einen konsistenten Stand haben. Zum Beispiel das Attribut „msExchArchiveStatus“ oder „msExchLitigationHold“ – wenn ein Cloud-Postfach ins Archiv geht oder auf Hold gesetzt wird, kann diese Info ins AD gespiegelt werden, sodass ein eventuell verbliebenes On-Prem Exchange Admin Center dies anzeigen würde. Auch Free/Busy-Informationen und die globale Adressliste profitieren von einer korrekten Synchronisation aller Empfänger (MailUser, MailKontakt, Gruppen). Mit Contact- und Group-Writeback (siehe oben) sorgt man dafür, dass auch cloud-erstellte Objekte on-prem sichtbar sind, was in Hybrid-Org oft gewünscht ist.

Ein weiteres Szenario: Deaktivierung von On-Prem Exchange. Viele Organisationen migrieren alle Postfächer zu Exchange Online und möchten dann die on-prem Exchange Server loswerden. Microsoft unterstützt offiziell ein „Exchange-freies“ AD-Benutzermanagement nicht komplett, aber Azure AD Connect kann helfen, zumindest Standardattribute via Writeback in AD zu bringen. Dennoch bleibt die Empfehlung, wenigstens einen minimalen Exchange-Server für Verwaltungszwecke vorzuhalten, wenn man weiterhin ein lokales AD hat. Azure AD Connect erleichtert hier das Leben insofern, als dass man Cloud-Änderungen (z.B. zusätzliche Proxy-Adressen) ins AD bekommen kann – so bleiben die AD-Objekte konsistent, selbst wenn on-prem keiner mehr bewusst Exchange pflegt.

Zusammengefasst: Durch diese Zusatzfunktionen wächst Entra ID Sync zu einem mächtigen Hybrid-Toolkit heran. Man sollte jedoch selektiv vorgehen – aktivieren Sie nur, was Sie wirklich brauchen, und testen Sie die Auswirkungen zuvor gründlich. Jedes Writeback-Feature bringt nämlich auch etwas mehr Komplexität und potentielle Fehlerquellen mit sich. Richtig eingesetzt bieten sie aber einen riesigen Mehrwert, um die Welten von Cloud und On-Prem nahtlos zu verbinden.

Migration & Modernisierung

IT-Landschaften sind lebendig – was gestern „State of the Art“ war, ist morgen vielleicht veraltet. In Bezug auf Entra ID Sync stellen sich vor allem zwei Modernisierungsfragen: Umstieg von Azure AD Connect auf Cloud Sync und Ablösung von Federation (AD FS) zugunsten von Cloud-Authentifizierung (PHS/PTA). Daneben gilt es, Altlasten zu bereinigen und klare Abnahmekriterien für einen erfolgreichen Umzug zu definieren.

Von Connect Sync zu Cloud Sync

Viele Unternehmen setzen seit Jahren Azure AD Connect (AADC) ein und fragen sich nun, ob der leichtere Cloud Sync Agent nicht die bessere Lösung wäre – z.B. um auf eigene SQL-Server und komplexe Sync-Server zu verzichten. Der Wechsel ist durchaus machbar, erfordert aber Planung. Wichtig zu verstehen: Man kann beide Lösungen nicht gleichzeitig auf denselben Objekten aktiv haben. Ein Objekt sollte immer nur von einem System synchronisiert werden, sonst drohen Konflikte. Daher empfiehlt sich eine phasenweise Migration:

• Pilotphase: Installieren Sie den Entra Cloud Sync Agent parallel zum bestehenden AADC, aber konfigurieren Sie ihn zunächst für einen kleinen Teilbereich (z.B. eine Test-OU oder einen einzelnen AD-Forest, falls Sie mehrere haben). In Azure AD Connect schließen Sie diese Test-OU vom Sync aus, sodass nur Cloud Sync sie bedient. So können Sie im laufenden Betrieb beobachten, ob Cloud Sync alle benötigten Attribute korrekt setzt und wo Unterschiede bestehen.
• Schrittweiser Ausbau: Vergrößern Sie nach und nach den Scope von Cloud Sync und verkleinern im Gegenzug den von AADC. Beispielsweise nehmen Sie eine Abteilung nach der anderen ins Cloud Sync-Scope. Dieser iterative Ansatz minimiert Risiko – im Fehlerfall können Sie für betroffene Objekte wieder temporär auf AADC zurückschwenken.
• Finaler Cut-Over: Wenn schließlich alle Objekte über Cloud Sync laufen, ist es Zeit, Azure AD Connect vollständig zu deaktivieren. Idealerweise haben Sie einen Zeitpunkt außerhalb der Geschäftszeiten, an dem Sie den „Cut“ machen: Stellen Sie AADC auf Ihrem primären Server in den Staging Mode (oder deinstallieren Sie ihn ganz) und lassen Sie Cloud Sync vollständig übernehmen. Überprüfen Sie, dass nach diesem Wechsel keine doppelten Benutzer oder Gruppen auftauchen. Weil beide Systeme tendenziell denselben SourceAnchor (z.B. objectGUID) verwenden können, sollte die Cloud die Identitäten wiedererkennen und nicht neu anlegen – sofern alles korrekt vorbereitet war.
• Monitoring nach Umstieg: In den Tagen nach der Migration gut hinschauen! Läuft jeder Sync-Zyklus sauber durch? Stimmen die Attributswerte überein? Gerade besondere Objekte (verschachtelte Gruppen, Ressourcenpostfächer etc.) verdienen Aufmerksamkeit.

Ein Hinweis: Es kann Gründe geben, bei Azure AD Connect zu bleiben – z.B. wenn Sie Pass-Through Authentication benötigen (Cloud Sync kann kein PTA) oder sehr komplexe Transformationsregeln im Einsatz haben. In solchen Fällen ist „Never change a running system“ valide. Microsoft entwickelt Cloud Sync jedoch rasant weiter, und langfristig könnte es Azure AD Connect ablösen. Haben Sie also die Roadmap im Blick.

Von Federation zu Cloud-Auth (PHS/PTA)

Viele Organisationen, die früh in die Cloud gingen, setzten auf AD FS Federation für SSO. Doch AD FS bedeutet hohe Wartung, und neuere Features (Conditional Access, Identity Protection) funktionieren oft nur mit cloudseitiger Authentifizierung. Daher der Trend: Weg von AD FS, hin zu PHS oder PTA.

Der Migrationspfad hier ist meist:

1. Vorbereitung: Stellen Sie sicher, dass Azure AD Connect Password Hash Sync aktiviert hat, selbst wenn Sie Federation nutzen. Das ist möglich und sogar empfohlen (dient als Backup). Richten Sie zudem, falls gewünscht, Seamless SSO ein – so bekommen die Nutzer später ein nahezu identisches SSO-Erlebnis. Wenn PTA das Ziel ist, installieren Sie die PTA-Agenten parallel – diese bleiben zunächst ungenutzt, aber einsatzbereit.
2. Testing: Wählen Sie eine kleine Nutzergruppe oder eine Subdomäne, an der Sie den Wechsel ausprobieren können. Sie könnten z.B. eine Test-Domäne in Entra ID als „Managed“ konfigurieren und Benutzer darauf migrieren, um das Verhalten zu prüfen.
3. Umschalten: Zur Haupt-Wechselzeit (wieder vorzugsweise abends oder am Wochenende) führen Sie den Domain-Federation-Wechsel durch. Für PHS: Convert-MsolDomainToStandard (bzw. im Entra Admin Center die Domäne von Verbunden auf „Verwaltet“ umstellen). Für PTA: ähnlich, aber dann Domain auf PTA setzen – Azure AD Connect bietet die Option direkt im Wizard „Switch to PTA“. Nach dem Befehl authentifizieren sich Benutzer ab sofort über die Cloud. Wichtig: DNS-Einträge (autologon*.msappproxy.net bei Seamless SSO) etc. bleiben gleich, nur die Anmelde-URL ändert sich auf die Microsoft Standard-Seite. Testen Sie unmittelbar mit ein paar Usern das Login (auch an allen Anwendungen!). Achten Sie auf Dinge wie: Funktioniert Outlook- und Teams-Login ohne neue Authentifizierung? (In der Regel ja, da Tokens weiterhin gültig sind und Seamless SSO greift.)
4. Beobachten & Rollback-Option: Lassen Sie die AD FS Infrastruktur zunächst weiter intakt, bis Sie einige Tage/Wochen beobachten konnten, dass alles reibungslos läuft. Die User Experience sollte sich kaum ändern – außer, dass das AD FS Anmelde-Fenster nun durch die Azure AD Anmeldeseite ersetzt ist (dort können Sie Firmenlogo etc. per Company Branding hinzufügen, um den Wiedererkennungswert zu steigern). Falls doch gravierende Probleme auftreten, könnten Sie theoretisch via Convert-MsolDomainToFederated die Domäne wieder zurück auf AD FS schwenken. Das ist selten nötig, beruhigt aber zu wissen.
5. AD FS Abschalten: Wenn die Entscheidung fällt, endgültig bei Cloud-Auth zu bleiben, planen Sie die Außerbetriebnahme von AD FS. Entfernen Sie die Relying Party Trusts für Azure AD, depublizieren Sie die Proxy-Endpoints und fahren Sie die Server herunter. Viele behalten die AD FS Server noch eine Weile als „Cold Standby“, falls man überraschend doch zurück muss – aber meistens kann man irgendwann Tabula Rasa machen, gerade wenn AD FS sonst keine andere Anwendung bedient.

Die Migration von Federation zu PTA/PHS bringt meist sofort spürbare Vereinfachung. Funktionen wie Azure AD Conditional Access decken heute nahezu alle Szenarien ab, die man früher mit AD FS Claims Rules gebaut hat – inklusive MFA, Netzwerkstandort, Gerätestatus usw. Weniger Server, weniger Komplexität, mehr Cloud-Funktionen: ein Gewinn, solange man die Risiken im Blick hat (z.B. Cloud-Auth fällt bei Internetdown aus, aber das tat AD FS letztlich auch, wenn die Nutzer extern waren).

Bereinigung & Abschlussarbeiten

Nach einer erfolgreichen Migration sollte man Altlasten beseitigen:

• Aufräumen der Konfiguration: Entfernen Sie nicht mehr benötigte Synchronisationsjobs oder -Regeln. Z.B. wenn Cloud Sync übernommen hat, deinstallieren Sie Azure AD Connect sauber (inkl. SQL LocalDB, um Ressourcen freizugeben). In Entra ID selbst können Sie alte Azure AD Connect Einträge (im Admin Center unter Azure AD Connect) entfernen.
• AD FS Bereinigung: Falls AD FS abgeschaltet wird, denken Sie an die Clients – Gruppenrichtlinien mit dem alten Web-Authentifizierungsserver (wenn WIA genutzt wurde) können zurückgenommen werden. Firewall-Regeln, Load Balancer Einträge für AD FS können gelöscht werden. Die Domäne in Azure AD sollte nun den Status „Managed“ haben – prüfen Sie das.
• Documentation Update: Alle Betriebshandbücher, Architekturdokumente und Notfallpläne aktualisieren, damit sie den neuen Stand widerspiegeln. Nichts ist schlimmer, als im Ernstfall auf veraltete Doku zu schauen („Starte ADFS neu“ – obwohl es das gar nicht mehr gibt).
• Licensing-Check: Falls man von AD FS (keine CloudAuth-Lizenz nötig) auf Features wie Azure AD Password Protection oder Cloud App Provisioning umgestiegen ist, stellen Sie sicher, dass die entsprechenden Azure AD P1/P2 Lizenzen vorhanden sind.
• Cleanup von Objekten: Möglicherweise hat der Wechsel „Karteileichen“ zutage gefördert (z.B. ein Account, der doppelt war). Bereinigen Sie solche Unstimmigkeiten im AD und Entra ID. Weniger Objekte = weniger potentielle Probleme.

Abnahmekriterien

Wie erkennt man, dass die Migration erfolgreich war? Definieren Sie am besten im Voraus Abnahmekriterien:

• Funktional: 100% der Benutzer können sich weiterhin an allen relevanten Services anmelden (Überprüfen mittels Stichproben, inkl. spezielle Konten wie Admin oder Service-Accounts).
• Vollständigkeit: Es sind keine doppelten oder unerwarteten Objekte entstanden. Alle Attributswerte entsprechen vor und nach der Migration dem Soll (ein Vorher/Nachher-Vergleich ausgewählter Benutzer kann helfen).
• Performance: Die Synchronisierungszeiten und Login-Dauer bewegen sich im gewohnten Rahmen. Ein Login via PHS/PTA dauert erfahrungsgemäß nicht länger als via AD FS – falls doch, muss optimiert werden.
• Monitoring: Die Überwachungsmechanismen zeigen grünes Licht – keine Spike in Fehlermeldungen, keine ständigen Warnungen. Connect Health (oder Ihr Monitoring) meldet einen gesunden Zustand.
• User Experience: Die Endanwender haben keinen negativen Impact bemerkt. Im Idealfall war die Umstellung für sie transparent oder wurde ihnen klar kommuniziert („Ab jetzt neues Anmelde-Portal, ansonsten alles wie gewohnt“). Feedback des Helpdesks: keine erhöhte Ticketzahl bzgl. Login nach Umstellung.

Wenn all diese Punkte erfüllt sind, können Sie getrost das Häkchen an die Migration machen – Projekt erfolgreich abgeschlossen! Denken Sie dennoch daran, einen „Backout-Plan“ für eine gewisse Zeit in der Schublade zu behalten, falls sich im Nachgang doch etwas Unerwartetes zeigt. Erfahrungsgemäß, wenn die Abnahmekriterien stimmen, tritt das aber selten ein.

Best Practices

Aus den bisherigen Kapiteln lassen sich zahlreiche Empfehlungen ableiten. Hier präsentieren wir die Top 20 Best Practices für Entra ID Sync auf einen Blick:

1. Planung ist das A und O: Nehmen Sie sich Zeit, Ihre Identity-Architektur aufzumalen – Forests, Trusts, erforderliche Objekttypen, alles. Eine saubere Planung erspart später viel Kopfzerbrechen.
2. Vorbereitung des AD: Bereinigen Sie Ihr Active Directory, bevor Sie synchronisieren. Entfernen Sie veraltete Konten, duplizierte E-Mails und setzen Sie konsistente UPNs/Attribute. „Garbage in, garbage out“ gilt auch hier.
3. Verwenden Sie gMSAs: Setzen Sie für alle Sync-Dienstkonten (AADC und Cloud Agent) Group Managed Service Accounts ein. Erhöht die Sicherheit und reduziert den Administrationsaufwand (keine ablaufenden Passwörter).
4. Least Privilege umsetzen: Geben Sie dem Sync-Konto nur die minimal nötigen Rechte. Keine Domain-Admins oder globalen Admins, sondern genau definierte Berechtigungen.
5. Domain Suffixe prüfen: Stellen Sie sicher, dass alle verwendeten UPN-Domänen im Entra ID Tenant verifiziert sind. Keine .local oder .intern UPNs für Cloud-Logins verwenden.
6. Mit Pilot starten: Führen Sie neue Synchronisationsmethoden oder -konfigurationen erst in kleinem Umfang ein (Test-OU, Test-Gruppe von Usern) und skalieren Sie dann hoch.
7. Staging-Server/Agent für HA nutzen: Für AADC immer einen Staging-Server bereithalten. Für Cloud Sync stets mindestens zwei Agent-Installationen einplanen. HA ist kein Luxus, sondern verhindert Ausfälle.
8. Updates einspielen: Halten Sie Azure AD Connect auf dem aktuellen Stand. Microsoft fixt regelmäßig Bugs und Security-Issues – nutzen Sie das. Planen Sie Updates z.B. quartalsweise ein.
9. Monitoring etablieren: Richten Sie automatisierte Health-Checks ein (Azure AD Connect Health oder eigene Scripts). Ein täglicher kurzer Blick auf „alles grün?“ sollte Routine sein.
10. Alerts aufsetzen: Lassen Sie sich benachrichtigen, wenn etwas schief läuft – z.B. per E-Mail oder Teams, falls ein Sync ausfällt oder viele Fehler auftreten.
11. Datensparsamkeit anwenden: Synchronisieren Sie nur, was wirklich gebraucht wird. Jede zusätzliche Attribut- oder OU erhöht die Last und potenziell die Angriffsfläche.
12. Dokumentation führen: Dokumentieren Sie Ihre Entra ID Connect/Sync Konfiguration, inklusive aller speziellen Regeln und Anpassungen. Bei Personalwechsel oder Fehlersuche ist das unbezahlbar.
13. Change Management beachten: Änderungen an der Synchronisierung (z.B. neue OU, andere Match-Regel) nicht einfach „mal eben“ live ändern. Nutzen Sie Wartungsfenster und testen Sie vorher, wo möglich.
14. Security first: Härten Sie den Sync-Server (siehe Sicherheitstipps zuvor). Der Server ist Teil der schützenswerten Infrastruktur.
15. Passwort-Reset durch Nutzer ermöglichen: Wenn möglich, aktivieren Sie Self-Service Password Reset mit Writeback. Erhöht die Usability und entlastet IT – natürlich nur mit entsprechender Lizenz.
16. Alte Authentifizierungsmethoden überdenken: Evaluieren Sie regelmäßig, ob Ihre aktuelle Auth-Methode noch passt. Wer noch AD FS nutzt, sollte überprüfen, ob PHS/PTA nicht inzwischen sinnvoller ist.
17. Lizenzierung im Blick haben: Funktionen wie Cloud App Provisioning oder HR-Import erfordern Premium-Lizenzen. Planen Sie diese ein, statt auf halbem Weg zu merken, dass etwas nicht funktioniert.
18. Endbenutzer informieren: Größere Änderungen (z.B. neues Login-Portal nach AD FS Ablösung) sollten an die Nutzer kommuniziert werden. Überraschung führt zu Verunsicherung – proaktive Info schafft Vertrauen in die IT.
19. Notfallplan parat halten: Definieren Sie, was zu tun ist, wenn der Sync längere Zeit ausfällt oder falsche Daten synchronisiert hat. Backup der AD-Daten? Temporäres Deaktivieren des Syncs? Diese Szenarien durchspielen.
20. Stetige Verbesserung: Identity Management ist kein Projekt, sondern ein Prozess. Holen Sie Feedback ein – von Admins („Was können wir automatisieren?“) wie von Usern („Kommen die neuen Mitarbeiterkonten schnell genug in die Cloud?“) – und passen Sie Ihre Sync-Strategie laufend an.

Und weil ein „Spickzettel“ manchmal hilfreich ist, hier noch eine kompakte Do/Don’t-Tabelle:

Do (Tun)	Don’t (Bleiben lassen)
Gründlich planen und testen – Implementieren Sie Entra ID Sync nie blind. Führen Sie Dry-Runs/Piloten durch.	Hauruck-Aktionen – Nicht ohne Test die ganze Firma über Nacht umstellen. Planung schlägt Feuerwehraktion.
Servicekonten absichern – Nutzen Sie gMSA, individuelle OU für Dienstaccounts, starke Passwörter.	Domain-Admin als Sync-Konto – Bitte nicht! Überprivilegierung öffnet Türen für Angreifer.
Monitoring einrichten – Automatismen zur Überwachung und Alerting konfigurieren.	„Wird schon laufen…“ – Das System unüberwacht lassen, in der Hoffnung, dass alles gut geht.
Konfig-Änderungen dokumentieren – Jede Anpassung schriftlich festhalten, z.B. im Änderungsprotokoll.	Konfiguration „vergessen“ – Nach Jahren weiß keiner mehr, warum welche Regel aktiv ist (und keiner traut sich, sie zu ändern).
Up-to-date bleiben – Infos über neue Sync-Features, MS-Best-Practices verfolgen (Ignite, TechCommunity).	Auf altem Stand verharren – Technologie entwickelt sich weiter. Wer 2015 stehenblieb (DirSync lässt grüßen), riskiert Sicherheit und Supportprobleme.
Hybrid-Strategie ganzheitlich denken – Sync, MFA, Conditional Access, HR-Prozesse verzahnen.	Nur Stückwerk – Nicht isoliert betrachten. Ein wildes Flickwerk aus Scripts und Tools ohne Gesamtstrategie rächt sich später.
Nach Hilfe fragen – Komplexe Szenarien mit MS Support oder erfahrenen Consultants durchsprechen.	Im Alleingang verzetteln – Lieber rechtzeitig Experten einbeziehen, statt in der Sackgasse zu landen.

Die obigen Punkte fassen zusammen, worauf es ankommt: sauber planen, sicher betreiben, kontinuierlich verbessern – dann wird Entra ID Sync vom potenziellen Problemfall zum zuverlässigen Fundament Ihrer Hybrid-Identitätsinfrastruktur.

Betriebshandbuch & Verantwortlichkeiten

Eine klare Zuständigkeitsverteilung und geregelte Betriebsprozesse sind essentiell, damit Entra ID Sync reibungslos funktioniert und bei Problemen jeder weiß, was zu tun ist. In diesem Kapitel skizzieren wir ein mögliches RACI-Modell, einen Wartungskalender sowie Backup- und Recovery-Überlegungen.

RACI-Matrix (Roles and Responsibilities)

Angenommen, wir haben folgende Rollen in unserem IT-Betrieb:

• AD-Administrator: Verantwortlich für das on-prem Active Directory (Domänen, DCs, etc.)
• Azure AD Administrator: Verantwortlich für Entra ID (Cloud Directory) und Azure AD Connect/Cloud Sync Konfig.
• IAM Manager/Architekt: Gesamtverantwortung Identity Management (führt Regie, entscheidet über Strategie, „Product Owner“ des IAM-Services).
• Service Desk: First-Level-Support, bearbeitet Endbenutzeranfragen (z.B. Passwort zurücksetzen, Konto entsperren).
• Security Officer/Compliance: Überwacht die Einhaltung von Richtlinien, prüft regelmäßige Audits.

In der RACI-Matrix (Responsible, Accountable, Consulted, Informed) könnten typische Aufgaben folgendermaßen zugeordnet sein:

Aufgabe	AD-Admin	Azure AD Admin	IAM Manager	Service Desk	Security
Betrieb des Sync-Servers / Agenten (Wartung, Patching)	R	R	A	I	I
Überwachung der täglichen Sync-Läufe	I	R	A	I	I
Anpassung der Sync-Konfiguration (z.B. neue OU)	C	R	A	I	C
Passwort-Rücksetz-Requests (via SSPR oder Admin)	C (bei On-Prem Reset)	R (bei Cloud Reset)	A	R (führt evtl. Reset durch)	I
Security Incidents untersuchen (z.B. ungewöhnliche Änderungen)	C	C	A	I	R
Updates / Upgrades von Azure AD Connect	R (Server OS)	R (AADC Software)	A	I	I
Notfall: Fallback aktivieren (z.B. auf Staging-Server umschalten)	C	R	A	I	I
Regelmäßiges Reporting an Management	I	I	R	I	C

(„R“ = Responsible/durchführend, „A“ = Accountable/verantwortlich, „C“ = Consulted/konsultiert, „I“ = Informed/zu informieren)

Jede Organisation kann die Rollen anders zuschneiden – wichtig ist, dass klar definiert ist, wer im Tagesbetrieb welche Aufgaben übernimmt und wer im Ausnahmefall Entscheidungen treffen darf.

Wartungskalender

Eine proaktive Wartung hält den Synchronisierungsservice gesund. Hier ein Beispiel-Wartungsplan:

Intervall	Wartungsaufgaben & Checks
Täglich	Prüfen, ob letzter Sync erfolgreich (Monitoring-Dashboard oder E-Mail-Report sichten). Eventlogs auf Fehler scannen. Ggf. einzelne fehlgeschlagene Objekte korrigieren.
Wöchentlich	Stichproben: Erstellen eines Test-Benutzers im AD -> Überprüfung nach Sync in Entra ID (Funktionstest). Überprüfung der Azure AD Connect Health Warnungen. Falls Password-Writeback aktiv: Test-Passwortreset eines Dummy-Users durchführen.
Monatlich	Review der Synchronisierungs-Logs auf Trends (z.B. nimmt die Dauer zu? Gibt es vermehrt Objekte in Fehler?). Überprüfung, ob neue OUs hinzugekommen sind, die evtl. in den Sync aufgenommen werden müssen. Cleanup: nicht mehr benötigte Gruppen/Benutzer in AD deaktivieren/löschen, damit sie auch in Cloud wegfallen.
Quartalsweise	Azure AD Connect Versionscheck: Ist eine neuere Version verfügbar, die relevante Fixes enthält? Planung des Updates im nächsten Wartungsfenster. Überprüfung der Konfiguration auf Änderungbedarf (neue Attribute syncen? Policies angepasst?). Sicherheitsreview: Sind alle Dienstkonten-Passwörter noch aktuell, keine unnötigen Rechte vergeben?
Halbjährlich	Notfallübung: Ausfall des primären Sync-Servers simulieren – Staging-Server übernehmen lassen (bzw. Wiederherstellung eines Agents testen). DR-Test: Backup der AADC-Konfiguration einspielen auf Testsystem (Simulation).
Jährlich	Architektur-Review: Passt unser Hybrid-Setup noch zur Unternehmensstrategie? Lizenz-Review: Stimmen AAD P1/P2 Lizenzen mit genutzten Features überein? Überprüfung neuer Microsoft-Features: z.B. gab es Änderungen bei Cloud Sync, die vorteilhaft wären?

Natürlich kann der Rhythmus je nach Unternehmensgröße variieren – ein agiler Cloud-only Betrieb schaut vielleicht häufiger, ein stabiles Umfeld vielleicht seltener. Wichtig ist: regelmäßige Routine statt „Fire Fighting“.

Backup & Recovery

Eine oft gestellte Frage: Muss man Azure AD Connect backupen? Einerseits enthält es keine benutzerseitigen Daten (die sind ja in AD/Azure AD), andererseits wäre ein Verlust der Konfiguration unschön. Best Practices für Backup/Recovery:

• Konfigurations-Backup: Exportieren Sie die Azure AD Connect Konfiguration nach jeder größeren Änderung. Es gibt PowerShell-Commands (Export-ADSyncServerConfiguration), um eine XML der aktuellen Einstellungen zu ziehen. Dieses File sicher ablegen. Im Fall einer Neuinstallation kann man damit die Config rekonstruieren (nicht 1:1 automatisch importierbar, aber als Referenz Gold wert).
• Verschlüsselungsschlüssel sichern: Beim Neuaufsetzen eines Azure AD Connect kann es relevant sein, den alten Schlüssel parat zu haben, wenn man die bestehende Synchronisierungs-Datenbank weiter nutzen will. Nutzen Sie Get-ADSyncAutoUpgrade -BackupKey (bzw. die Doku-Anleitung) um den Key zu exportieren. In vielen Fällen fährt man aber besser, den neuen Server frisch zu konfigurieren (Staging Mode macht es leicht).
• Staging Server = Live-Backup: Der beste Backup für AADC ist ein zweiter Server im Staging Mode. Er hat eine eigene Kopie der Konfig und könnte jederzeit einspringen. Pflegen Sie ihn, dann brauchen Sie im Notfall kein Backup einspielen – einfach umschalten.
• Cloud Sync Agent Recovery: Für Cloud Provisioning Agents gilt: Keine State-Daten am Agent, daher im Ausfall einfach Agent neu installieren. Halten Sie die Installer-Version bereit. Die Cloud-Konfig selbst wird von Microsoft gespeichert (und redundant gehalten).
• Active Directory Backup: Bedenken Sie, dass ein „falscher“ Sync auch Schaden anrichten kann – z.B. wenn durch Fehlkonfiguration plötzlich viele Objekte in AD gelöscht würden (theoretisches Worst-Case). Daher weiterhin regelmäßige AD-Backups fahren (System State, Azure AD Connect ändert aber nichts ohne AD-Admin, also geringes Risiko von Cloud nach AD außer bei Writeback). Falls Kennwort-Writeback aktiv ist: ein versehentliches Zurücksetzen vieler Passwörter könnte man nur per AD-Backup rückgängig machen – also zumindest die Domänencontroller sichern.
• Azure AD Recycle Bin: Gelöschte Cloud-Objekte bleiben 30 Tage im Azure AD Papierkorb. Falls durch Synchronisierung versehentlich etwas gelöscht wurde, kann man es dort einfach wiederherstellen (Restore-AzureADObject via PowerShell). Nichtsdestotrotz: Fehler gar nicht erst so weit kommen lassen.
• Notfallplan Sync stoppen: Wenn Sie merken, der Sync läuft Amok (z.B. mass deletion), wissen Sie, wie Sie ihn anhalten. Optionen: Sync Scheduler deaktivieren (Set-ADSyncScheduler -SyncCycleEnabled $false) oder den AADC-Dienst stoppen. Bei Cloud Sync kann man die Provisioning im Azure Portal auf „Pause“ setzen. Lieber temporär einfrieren und Lage klären, als blind weitermachen.

Mit diesen Vorkehrungen sind Sie für den Fall der Fälle gerüstet. In der Praxis kommt ein Total-Ausfall selten vor – aber wenn doch, hat man besser einen Plan in der Tasche. Und wie immer gilt: das Team mit ins Boot holen, Zuständigkeiten klären und die Doku aktuell halten, dann übersteht man auch unerwartete Ereignisse im Sync-Betrieb.

Aufwände, Kostenrahmen & Tempo

Projekte rund um Entra ID Synchronisierung können vom kleinen 3-Tage-Auftrag bis zum monatelangen Großprojekt reichen – abhängig von Ausgangslage und Zielen. Um ein Gefühl für Aufwände und Kosten zu geben, hier ein Orientierungsrahmen auf Basis eines Tagessatzes von 1.500 € (zzgl. MwSt.):

• Kleines Unternehmen, einfaches Szenario: Ein einzelnes AD, wenige hundert Benutzer, Standard-PHS-Sync. Aufwand ca. 3–5 Personentage, verteilt über 1–2 Wochen. Kostenrahmen: 4.500–7.500 € (zzgl. MwSt.). Darin enthalten wären typischerweise Workshops, Installation, Grundkonfiguration und kurze Einweisung.
• Mittelstand mit etwas Komplexität: Z.B. Multi-Forest oder spezielle Anforderungen (PTA, erste Writeback-Funktionen). Aufwand ca. 10–15 Personentage. Kosten: 15.000–22.500 € (zzgl. MwSt.). Hier fallen zusätzliche Tätigkeiten an: detaillierte Konzeption, Testläufe, Migration von AD FS, Policies abstimmen, etc. Die Projektdauer erstreckt sich oft über 4–8 Wochen, da auch Abstimmungen und Change Management berücksichtigt werden müssen.
• Großunternehmen / komplexe Hybrid-Identität: Mehrere AD-Forests, weltweit verteilte Umgebungen, vollumfängliche Nutzung von Cloud Sync, HR-Provisioning, Conditional Access Integration und so weiter. Aufwand 20+ Personentage, je nach Umfang auch 50 PT und mehr möglich (in Tranchen). Kosten grob >30.000 € (zzgl. MwSt.). Solche Projekte werden in Phasen gestaffelt: Design-Phase, Pilotphase, Rollout-Wellen, und erfordern meist bereichsübergreifende Zusammenarbeit (IAM, Security, HR, Compliance). Die Dauer kann hier 3–6 Monate betragen inklusive aller Tests und Abnahmen.

Natürlich sind das Schätzwerte – jedes Unternehmen tickt anders. Wichtig ist, im Vorfeld die Erwartungen abzuklären: Welche internen Ressourcen stehen zur Verfügung? (Manche Kunden übernehmen z.B. Hardwarebereitstellung selbst, andere lagern alles aus.) Gibt es Deadlines, z.B. ablaufende Verträge (AD FS Zertifikate oder ein altes IAM-System, das abgeschaltet wird)? Solche Faktoren beeinflussen das Tempo.

Tempo und Projektdurchführung: Ein erfahrener Consultant kann eine Basis-Synchronisierung in wenigen Tagen zum Laufen bringen. Doch oft empfiehlt es sich, das Tempo bewusst zu dosieren. Ein schrittweiser Rollout mit Pufferzeiten für Tests und User-Feedback hat sich bewährt. So ein Projekt besteht grob aus:

• Kickoff & Anforderungsworkshop (1–2 Tage),
• Implementierung Kernsystem (z.B. AADC Installation, Grundkonfig) (2–3 Tage),
• Pilotbetrieb (einige Tage/Wochen beobachten, Feinjustierung),
• Rollout restliche Benutzer (1–2 Tage aktiver Aufwand, verteilt auf Woche X),
• Schulung/Übergabe (1 Tag),
• Post-Go-Live Support (nach Bedarf 1–2 Tage verteilt).

Rechnet man das zusammen, kommt man im Mittel auf die erwähnten ~10 Tage aktiver Beratungsleistung, verteilt über ~6 Wochen Gesamtprojektzeit. Bei strafferer Gangart ginge es auch schneller, aber die Erfahrung zeigt: etwas Luft einplanen verhindert Stress und erlaubt es, auf entdeckte Herausforderungen in Ruhe zu reagieren.

Was auch nicht vergessen werden darf: Neben den Beratungskosten können Lizenzkosten anfallen (etwa für Azure AD Premium P1/P2, falls noch nicht vorhanden), und interner Aufwand für Ihre Mitarbeiter (Workshops besuchen, Tests durchführen). Diese Kosten sind schwieriger zu beziffern, sollten aber im Projektplan berücksichtigt werden.

Alles in allem lässt sich sagen: Mit einem Budget von 15.000 € (plus/minus je nach Umfang) lässt sich bereits eine robuste Entra ID Sync Implementierung inklusive Beratung realisieren – eine Investition, die sich durch die darauf folgende Effizienz und Sicherheitsgewinne schnell bezahlt macht.

Persönliches Beratungsangebot

Zum Abschluss möchte ich – als erfahrener IAM-Berater – Ihnen drei vordefinierte Beratungspakete vorstellen. Alle Pakete haben eins gemeinsam: Sie buchen immer mich persönlich, keine anonyme Beratungsfirma, keine Übergabe an Junioren ohne Erfahrung. Ich begleite Ihr Unternehmen individuell und langfristig, bis Sie zufrieden sind. Es handelt sich bewusst nicht um ein laufendes Managed-Service-Abo, sondern um transparente Einmal-Leistungen, bei denen Ihr Team befähigt wird, selbst den Betrieb zu stemmen (mit meiner Unterstützung im Hintergrund bei Bedarf).

Paket „Starter“: Entra ID Sync Quickstart
Für kleinere Umgebungen oder einen ersten Einstieg. Enthält typischerweise:
– 2 Tage Workshop/Analyse vor Ort oder remote: Anforderungen aufnehmen, Umgebung sichten, Empfehlungen aussprechen.
– 1–2 Tage Umsetzung Kerninstallation (Azure AD Connect installieren und Grundkonfiguration durchführen) gemeinsam mit Ihrem Admin-Team.
– 1 Tag Nachbetreuung & Feintuning (Nachbesprechung, Dokumentation, Beantwortung offener Fragen).
Umfang: ca. 4–5 Beratertage zum Festpreis. Preis: etwa 7.500 € (zzgl. MwSt.).
Ergebnis: Ein funktionierender Basis-Sync zwischen AD und Entra ID, inkl. Wissenstransfer an Ihre Admins. Ihr Team kann danach eigenständig einfache Betriebsaufgaben durchführen.

Paket „Professional“: Hybrid Identity Komplett
Für mittlere Unternehmen oder erweiterte Anforderungen. Dieses Paket deckt den vollständigen Projektzyklus ab:
– Workshops für Design & Planung (inkl. Sicherheit/Compliance Abstimmung).
– Implementierung von Entra ID Connect oder Cloud Sync in Produktion, inkl. ggf. Pass-Through Auth oder grundlegenden Writeback-Features.
– Migration von bestehenden Lösungen (z.B. Ablösung von AD FS) falls benötigt.
– Umfassende Tests und begleitetes Go-Live.
– Schulung des IT-Personals (Runbooks, Troubleshooting-Training).
Umfang: ca. 10–15 Beratertage (je nach Komplexität auch in Etappen abrufbar). Preis: typischerweise 15.000–22.500 € (zzgl. MwSt.).
Ergebnis: Ein auf Ihre Organisation zugeschnittener Hybrid Identity Service, fertig eingerichtet und mit Ihren Prozessen verzahnt. Enthalten ist auch ein betreuter Betriebsstart, bei dem ich in den ersten Wochen on-demand zur Verfügung stehe, falls Fragen oder Probleme auftauchen.

Paket „Enterprise“: Identity Masterplan & Begleitung
Für große Unternehmen oder besondere Ansprüche. Hier bekommen Sie ein Rundum-Sorglos-Paket:
– Tiefgehende Analyse der bestehenden IAM-Landschaft und Entwicklung einer maßgeschneiderten Hybrid-Identitätsstrategie (z.B. Integration von HR-Systemen via SCIM, Multi-Forest-GALSync-Design, Conditional Access Konzepte).
– Umsetzung durch mich und ggf. Unterstützung Ihres Teams bei umfangreichen Tätigkeiten (Rollouts in verschiedenen Regionen, Koordination mit anderen Dienstleistern, etc.).
– Umfassendes Projektmanagement und Stakeholder-Management inklusive (Abstimmung mit Security- und Compliance-Verantwortlichen, Präsentation der Ergebnisse an Entscheider).
– Langfristige Begleitung: Auch nach dem Go-Live stehe ich Ihnen für einen definierten Zeitraum (z.B. 6–12 Monate) mit einem Kontingent an Tagen zur Seite – für Optimierungen, Reviews, Anpassungen an neue Anforderungen. Eine Art „Identity Coach“ auf Abruf.
Umfang: flexibel, oft 20+ Tage über mehrere Monate verteilt. Preis: nach individuellem Angebot, basierend auf 1.500 €/Tag. Beispiel: 20 Tage = 30.000 € (zzgl. MwSt.), inkl. begleitender Unterstützung über ein Jahr.
Ergebnis: Sie erhalten nicht nur eine implementierte Lösung, sondern einen nachhaltigen Identity-Betrieb. Ihr Team wird durch Coaching befähigt, auch zukünftige Herausforderungen zu meistern. Sie haben einen persönlichen Ansprechpartner, der Ihr Umfeld kennt – ohne sich in ein langfristiges Outsourcing zu begeben.

Transparenz: In allen Paketen wird klar ausgewiesen, welche Leistungen enthalten sind. Keine versteckten Kosten – Reisekosten und Spesen werden vorab besprochen (falls vor-Ort-Termine gewünscht sind). Die Formel ist einfach: Anzahl der Beratertage × 1.500 € (zzgl. MwSt) = Preis. Sie zahlen für Expertise und persönliche Betreuung, nicht für Hochglanzbroschüren oder Overhead.

Wenn keins der Pakete exakt passt, schnüren wir einfach ein individuelles Paket nach Ihrem Geschmack. Ziel ist stets: Sie erhalten die Unterstützung, die Sie brauchen – nicht mehr und nicht weniger.

FAQ (Häufige Fragen)

Zum Schluss noch eine Sammlung von 15 praxisrelevanten Fragen rund um Entra ID Sync – natürlich mit Antworten:

Frage: Was ist der Hauptunterschied zwischen Entra ID Connect (Azure AD Connect) und Entra ID Cloud Sync?
Antwort: Beide bringen Ihre AD-Benutzer in die Cloud, aber Connect Sync ist ein traditionelles Tool, das lokal installiert wird, viel Konfigurationsoptionen bietet (inkl. Pass-Through Auth, Writeback etc.) und einen eigenen Server braucht. Cloud Sync hingegen nutzt leichte Agenten und verlagert die Logik in die Microsoft Cloud – es ist einfacher aufzusetzen, erlaubt mehrere Agenten für HA, unterstützt aber (noch) nicht alle Spezialfälle (kein PTA, weniger Anpassungen). Faustregel: Connect für volle Kontrolle und Legacy-Features, Cloud Sync für einfache, verteilte Setups.

Frage: Brauche ich für die Synchronisierung eine Azure AD Premium Lizenz?
Antwort: Der Grundsync an sich ist kostenlos. Microsoft stellt Azure AD Connect / Cloud Sync allen Kunden zur Verfügung – auch mit Azure AD Free oder Microsoft 365 Business Standard funktioniert das. Aber: Einige Features erfordern Premium. Beispielsweise Passwort-Rückschreiben und Azure AD Connect Health gibt’s erst mit Azure AD Premium P1, und Identity Governance wie SCIM-Provisionierung erfordert P2. Zudem gilt: Bei sehr vielen Objekten (>50.000) erwartet Microsoft, dass man eine geeignete Lizenz hat (mindestens P1), um den erhöhten Verzeichnisabgleich zu unterstützen.

Frage: Wie oft wird synchronisiert und kann ich das Intervall ändern?
Antwort: Azure AD Connect synchronisiert standardmäßig alle 30 Minuten inkrementell. Man kann das Intervall anpassen (via PowerShell Set-ADSyncScheduler), aber Vorsicht: zu häufig kann Ressourcen belasten, zu selten führt zu Verzögerungen – 30 min ist ein guter Mittelwert. Cloud Sync arbeitet nahezu in Echtzeit: alle 2-3 Minuten wird nach Änderungen geschaut. Hier lässt sich das Intervall nicht manuell ändern (es ist ein Service), allerdings kann man den Dienst pausieren, falls nötig. Einzelne Objekte kann man auf Wunsch auch per PowerShell/Graph on-demand synchronisieren.

Frage: Welche Daten werden überhaupt synchronisiert?
Antwort: Standardmäßig Benutzerkonten (mit ihren Kerndaten wie Name, Vorname, Anzeigename, Benutzername/UPN, E-Mail, Gruppenmitgliedschaften, etc.), Gruppen (Sicherheits- und verteilerlisten), und Kontakte. Optional können auch Computer/Device-Objekte (für Hybrid Join) und einige spezielle Objekte synchronisiert werden. Kennwörter werden nicht als Klartext übertragen, sondern als Hash (bei PHS). Attribute wie Passwörter, Hashes und bestimmte sicherheitsrelevante Felder sind nur Einbahnstraße nach Azure AD. Sie können über Filter konfigurieren, welche OU und welche Objektarten einbezogen werden. Nicht synchronisiert werden z.B. Berechtigungen/ACLs, sehr systemnahe AD-Attribute oder Objekte wie OUs selbst.

Frage: Werden Änderungen in der Cloud (Entra ID) zurück ins lokale AD geschrieben?
Antwort: Im Normalfall ist der Fluss einseitig: AD → Cloud. Änderungen, die Sie im Azure-Portal an einem synchronisierten Benutzer vornehmen (z.B. Namen ändern), werden beim nächsten Sync vom AD wieder überschrieben. Es gibt aber Writeback-Ausnahmen: Wenn Passwort-Writeback aktiviert ist, gehen Passwortänderungen in Azure AD ins AD zurück. Bei Gruppen-Writeback werden in Azure angelegte Gruppen ins AD kopiert. Und Geräte-Writeback tut Ähnliches für Geräte. Diese Rückschreibefunktionen müssen gezielt eingerichtet sein – von allein passiert kein automatischer Zwei-Wege-Abgleich für normale Benutzerattribute.

Frage: Was passiert, wenn der Synchronisierungsserver oder -Agent ausfällt? Können sich Benutzer dann noch anmelden?
Antwort: Ja, Anmeldungen gehen weiterhin – zumindest wenn Sie Password Hash Sync im Einsatz haben. PHS lädt die Hashes ja in die Cloud, das heißt Azure AD kann User authentifizieren, auch wenn der Sync-Server gerade down ist. Die Konten bleiben also gültig, nur neue Änderungen kommen nicht nach. Bei Pass-Through Authentication ist es kritischer: Hier braucht es einen erreichbaren PTA-Agent, sonst schlagen Logins fehl. Darum sind mehrere PTA-Agenten so wichtig. Cloud Sync Agenten sollten ebenfalls redundant vorhanden sein – fällt einer aus, übernimmt der andere und Benutzer merken nichts. Sobald der primäre Server wieder da ist, holt er die versäumten Änderungen nach (Azure AD Connect puffert einiges zwischen). Langfristig sollte ein Sync-Server-Ausfall aber rasch behoben oder durch einen Staging-Server ersetzt werden.

Frage: Wir haben mehrere AD-Forests. Kann ich die alle mit Entra ID verbinden?
Antwort: Ja. Azure AD Connect unterstützt multiple Forests in einem Tenant – Sie müssen im Setup alle Forests hinzufügen. Der Server braucht Netzwerkzugriff zu allen und Sie konfigurieren evtl. eine Vereinheitlichung (z.B. falls ein Benutzer in Forest A und B je ein Konto hat). Cloud Sync macht das noch einfacher: Sie installieren in jedem Forest einen Agent und lassen alle ins selbe Entra ID synchronisieren. Wichtig ist, dass UPNs/Emails der Benutzer über Forests eindeutig sind, damit in Azure kein Durcheinander entsteht. Getrennte (disjunkte) Forests ohne Trust sind mit Cloud Sync sehr gut abbildbar, mit klassischem Connect schwieriger (hier ggf. über DMZ/LDAP-Vertrauensstellung arbeiten).

Frage: Können Azure AD Connect und Cloud Sync parallel betrieben werden?
Antwort: Grundsätzlich ja, aber nicht auf denselben Objekten. Sie könnten z.B. Forest A mit AADC synchronisieren und Forest B mit Cloud Sync, beides in denselben Tenant – das klappt. Oder Sie lassen testweise eine kleine OU via Cloud Sync syncen und den Rest via AADC (sofern klar getrennt per Filter). Was nicht geht: Ein und dieselbe Benutzerpopulation gleichzeitig von beiden Tools syncen lassen – das würde Kollisionen geben. Microsoft bietet aber die Möglichkeit, schrittweise umzusteigen: Cloud Sync kann neben AADC in „Pilot“ betrieben werden, bis man umschaltet.

Frage: Unterstützt Entra ID Sync auch andere LDAP-Verzeichnisse außer AD?
Antwort: Out of the box: nein. Die Microsoft-Tools sind für AD (Active Directory) ausgelegt. Andere LDAP-Server (OpenLDAP, Novell eDirectory etc.) werden nicht direkt unterstützt. In solchen Fällen könnte man überlegen, diese Verzeichnisse über SCIM an Entra ID anzubinden oder doch einen Zwischenschritt (z.B. via Microsoft Identity Manager oder Drittanbieter-Tool) einzusetzen. Wenn es um reinen Cloud-User-Abgleich geht, bietet Entra ID auch Provisioning-Connectoren für bestimmte Systeme. Aber ein generischer LDAP-Import ist nicht Teil von Azure AD Connect.

Frage: Wie verhält sich Azure AD Connect mit Azure AD Domain Services (AAD DS)?
Antwort: Azure AD Domain Services ist ein Cloud-Angebot, das ein AD-ähnliches LDAP für die Cloud bereitstellt. Es synchronisiert sich aus Azure AD heraus. Damit Azure AD dort vollständige Infos hat, sollten Sie Password Hash Sync aktiviert haben – denn AAD DS braucht Kennworthashes in der Cloud. Wenn Sie PTA only machen, könnten Benutzer in AAD DS sich mangels Hash eventuell nicht anmelden. Abgesehen davon: Azure AD Connect synchronisiert on-prem AD → Azure AD, und Azure AD Domain Services nimmt dann diese Daten und stellt sie als verwaltete Domäne bereit. Direkt mit AAD DS redet Azure AD Connect nicht.

Frage: Muss der Azure AD Connect Server ein Domain Controller sein?
Antwort: Nein. Er kann auf einem Mitgliedsserver laufen und das ist in der Regel auch empfohlen. Azure AD Connect installiert SQL Express und andere Komponenten; auf Domain Controllern kann das zu Ressourcenthemen oder Port-Konflikten führen. Supportet wäre es (man kann zur Not AADC auf einem DC installieren), aber best practice: verwalten Sie den Sync getrennt. Cloud Sync Agent hingegen ist recht leichtgewichtig – den könnte man auch auf einem DC installieren, falls nötig, aber auch hier lieber auf einem dedizierten Server oder sogar Client OS (der Agent unterstützt Windows 10/11) betreiben.

Frage: Kann ich die Synchronisierung vorübergehend pausieren oder stoppen?
Antwort: Ja. Bei Azure AD Connect können Sie den Scheduler per PowerShell aus- und einschalten. Im Synchronization Service Manager gibt es auch die Option, den nächsten Lauf zu verschieben. Notfalls stoppt man den Windows-Dienst „ADSync“. Bei Cloud Sync gibt es im Azure Portal einen Pause/Resume-Schalter für den Provisioning Job – damit können Sie den Abgleich anhalten. Lange pausieren sollte man aber nicht, da sich in der Zwischenzeit Änderungen ansammeln. Und unbedingt dran denken, wieder zu aktivieren – sonst wundert man sich, warum nichts mehr passiert.

Frage: Werden Passwörter im Klartext übertragen oder gespeichert? Wie sicher ist das?
Antwort: Passwörter werden nie im Klartext übertragen. Bei Password Hash Sync wird aus dem AD-Hash (NTLM-Hash) ein weiterer Hash gebildet („Hash of Hash“) und nur dieser geht an Azure AD. In Azure AD selbst liegen Passwörter also nur als stark gehashte Werte vor – selbst Microsoft könnte daraus das ursprüngliche Passwort nicht errechnen. Bei Pass-Through Auth verlassen Passwörter die Firma gar nicht: da prüft ein lokaler Agent jeden Login direkt gegen AD und gibt nur „okay/nicht okay“ an die Cloud. Sicherheit auch hier: Die Verbindung vom Agent zur Cloud ist verschlüsselt und auf Vertrauensbasis, der Agent meldet sich mit Zertifikat. Unterm Strich ist Entra ID Sync sehr sicher konzipiert, solange Sie die Server/Agenten schützen. Die größten Risiken liegen eher in Fehlkonfiguration (z.B. zu viele Rechte vergeben) als im Übertragungsweg.

Frage: Wie werden gelöschte Benutzer gehandhabt?
Antwort: Löschen Sie einen Nutzer im lokalen AD, so erkennt Azure AD Connect das und löscht den entsprechenden Azure AD Account ebenfalls – allerdings zunächst als Soft Delete. In Azure AD ist der User dann 30 Tage im Papierkorb (kann innerhalb der Zeit wiederhergestellt werden). Nach 30 Tagen erfolgt Hard Delete (endgültig weg). Umgekehrt, wenn Sie in Azure AD einen synchronisierten Benutzer löschen, taucht er beim nächsten Sync im Azure AD wieder auf (da er ja noch im AD existiert). Löscht man allerdings den AD-Benutzer und deaktiviert vorher den Sync, würde der Azure-Account in der Cloud bestehen bleiben (Waisenkonto sozusagen). Für Gruppen und Kontakte gelten ähnliche Regeln. Wichtig: Azure AD Connect hat einen Schutz, der verhindert, dass aus Versehen eine Massenlöschung passiert (Threshold). Cloud Sync verhält sich im Prinzip gleich, auch dort werden Removals synchronisiert. Für Geräteobjekte (bei Hybrid Join) werden Deletes ebenfalls synchronisiert, aber oft löscht man Geräte eher aus Azure AD manuell, das hat keine Auswirkung zurück on-prem außer man nutzt Device Writeback.

Frage: Wie skalierbar ist Entra ID Connect? Schafft das auch zehntausende Benutzer?
Antwort: Ja, durchaus. Azure AD Connect kann mit einigen Hunderttausend Objekten umgehen; Microsoft selbst spricht von getesteten Umgebungen jenseits der 500.000 Objekte (dann empfiehlt sich allerdings ein vollwertiger SQL Server statt der mitgelieferten SQL Express). Wichtig ist eine leistungsfähige VM/Hardware und genügend RAM für die Synchronisierungs-Engine. Cloud Sync hat pro Agent offiziell ein Limit von ~150.000 Objekten pro Domain; bei mehr müsste man mehrere Agenten/domain einsetzen oder Microsoft um Rat fragen. In der Praxis haben viele Organisationen mit 50k+ Usern AADC erfolgreich im Einsatz. Wenn Sie Millionen Objekte synchronisieren wollen, wird es spezieller – da sollte man Microsoft Consulting hinzuziehen. Für die meisten mittelständischen Szenarien reicht die Kapazität locker aus. Die Performance können Sie optimieren, indem Sie nur notwendige Objekte syncen (Filter) und ggf. die Synchronisierungsintervalle anpassen.

Glossar

Zum schnellen Nachschlagen hier ein Glossar wichtiger Begriffe rund um Entra ID Sync:

• Active Directory (AD): Lokaler Verzeichnisdienst von Microsoft (seit Windows 2000). Enthält Benutzer, Gruppen, Computer etc. und dient oft als zentrales Authentifizierungssystem im Unternehmen.
• Microsoft Entra ID (Azure AD): Cloud-Verzeichnisdienst von Microsoft, Teil der Entra-Familie. Früher bekannt als Azure Active Directory. Hier werden die Identitäten für Microsoft 365 und tausende Cloud-Apps verwaltet.
• Azure AD Connect / Entra ID Connect Sync: Das on-premises Synchronisierungstool (Windows-Server-Anwendung), um AD mit Entra ID zu verbinden. Oft kurz Azure AD Connect genannt. Liest lokale AD-Daten aus und überträgt sie nach Entra ID gemäß definierter Regeln.
• Entra ID Cloud Sync: Die cloud-native Synchronisierungslösung mit leichtgewichtigem Agent. Erfüllt ähnlichen Zweck wie Azure AD Connect, aber Konfiguration und Logik liegen in Azure. Vorteil: mehrere Agenten für Hochverfügbarkeit, einfacher für Multi-Forest ohne Trust.
• Hybrid Identity (hybride Identität): Gesamtkonzept, dass ein Benutzer eine kombinierte Identität On-Premises und in der Cloud hat. Der Benutzer meldet sich mit denselben Credentials an beiden Welten an (Single Sign-On über Organisationsgrenzen).
• Password Hash Synchronization (PHS): Synchronisierung von Passwort-Hashes vom AD zu Entra ID. Ermöglicht Cloud-Authentifizierung mit lokalem Passwort (Azure AD prüft den Hash). Bietet einfache Implementierung und unterstützt Self-Service-Password-Reset.
• Pass-Through Authentication (PTA): Authentifizierungsmodus, bei dem Azure AD das eingegebene Passwort nicht selbst prüft, sondern verschlüsselt an einen lokalen PTA-Agent sendet, der gegen AD validiert. Erfordert funktionierende Verbindung ins On-Prem AD pro Login.
• Federation (föderierte Anmeldung): Allgemein die Verwendung eines externen Identitätsproviders für die Anmeldung. Im Microsoft-Umfeld meist via AD FS realisiert: Azure AD leitet Benutzer zur AD FS-Anmeldeseite weiter, AD FS prüft Benutzer gegen AD und gibt ein Token zurück.
• AD FS (Active Directory Federation Services): Rolle unter Windows Server, die föderiertes SSO ermöglicht. Stellt SAML/OAuth2-Identitätsprovider Dienste bereit, um z.B. Office 365 oder andere Apps mit AD zu verbinden, ohne Passwörter zu synchronisieren. Erfordert eigene Serverinfrastruktur.
• Seamless Single Sign-On (Seamless SSO): Feature, das domain-joined Windows Clients automatisch bei Azure AD anmeldet, ohne Kennworteingabe. Nutzt das Kerberos-Ticket des angemeldeten AD-Benutzers. Funktioniert mit PHS oder PTA. Wird per Azure AD Connect eingerichtet (setzt einen Computeraccount „AzureADSSOACC“ im AD).
• Source of Authority: „Quellsystem der Wahrheit“ – gibt an, welches System für die Daten führend ist. Hier: das lokale AD ist Source of Authority für Benutzer, die von dort synchronisiert werden (d.h. Änderungen sollen im AD gemacht werden, nicht in Azure).
• SourceAnchor / ImmutableID: Der eindeutige Identifikator, der ein Objekt im lokalen AD mit dem in Entra ID verbindet. Wird einmalig beim Erst-Sync festgelegt (z.B. basierend auf objectGUID oder ms-DS-ConsistencyGuid) und dann in Azure AD als ImmutableId gespeichert. Dient dazu, Objekte wiederzuerkennen (z.B. bei erneuter Synchronisierung oder zwischen verschiedenen Sync-Servern).
• User Principal Name (UPN): Der Anmeldename eines Benutzers in E-Mail-Format (user@domain). Im AD oft gleich der primären E-Mail. Azure AD verwendet den UPN als Haupt-Benutzernamen für Logins. UPN-Domänen müssen in Entra ID als „benutzerdefinierte Domänen“ verifiziert sein, sonst wird auf *.onmicrosoft.com geändert.
• ms-DS-ConsistencyGuid: Attribut des AD-Benutzers (GUID), das für Azure AD Connect als alternatives SourceAnchor dienen kann. Vorteil: Administrator kann diesen GUID-Wert selbst steuern. Wird empfohlen, um z.B. bei Domain-Wechsel den Anchor mitzunehmen.
• ObjectGUID: Eindeutige Kennung jedes AD-Objekts, vom AD bei Erstellung vergeben. Azure AD Connect nutzt standardmäßig den ObjectGUID eines Users als SourceAnchor (außer man konfiguriert ms-DS-ConsistencyGuid). Ändert sich nie für ein Objekt innerhalb derselben Domain.
• SCIM (System for Cross-domain Identity Management): Offener Standard für den Austausch von Identitätsdaten (Benutzer, Gruppen) zwischen Systemen via REST/JSON. Azure AD verwendet SCIM 2.0, um Benutzer automatisch in SaaS-Anwendungen bereitzustellen oder von externen Systemen zu empfangen (z.B. Workday-Integration).
• Provisioning (User Provisioning): Allgemein der Prozess des automatischen Anlegens, Änderns und Entfernens von Benutzerkonten in Zielsystemen. In Kontext Entra ID: z.B. Provisioning von Entra ID zu einer Anwendung (User dort anlegen) oder von einem HR-System ins AD. Azure AD hat einen Provisioning-Dienst, der hierbei hilft (oft über SCIM).
• Writeback: Überbegriff für alle Funktionen, bei denen Azure AD als Quelle dient und Daten ins lokale AD zurückgeschrieben werden. Standardmäßig ist Writeback aus, muss gezielt aktiviert werden (siehe einzelne Arten unten).
• Password Writeback: Rückschreiben von Passwortänderungen aus Azure AD ins lokale AD. Ermöglicht, dass z.B. ein in der Cloud geändertes Passwort auch on-prem gilt. Voraussetzung: AD Connect mit PHS + entsprechender Lizenz. Wichtig für Self-Service Password Reset (SSPR).
• Group Writeback: Rückschreiben von in Azure AD erstellten Gruppen ins lokale AD. Speziell unterstützt Azure AD Connect das Writeback von Microsoft 365 Groups (Unified Groups) als verteilerlistenartige Objekte ins AD. Hilft, Cloud-Gruppen auch on-prem nutzbar zu machen.
• Device Writeback: Rückschreiben von Azure AD Gerätedaten ins lokale AD. Erst nutzbar mit AD Schema 2016. Erstellt in AD sogenannte Hybrid Device Objekte für Azure AD-registrierte Geräte. Wird hauptsächlich gebraucht für AD FS basierte Conditional Access (heute weniger relevant dank Cloud Trust).
• Contact Writeback: Rückschreiben von in Azure AD angelegten Kontaktobjekten ins AD. Ermöglicht ein einheitliches Adressbuch, wenn z.B. externe Kontakte in Exchange Online gepflegt werden; diese können ins lokale AD als MailKontakt geschrieben werden.
• Azure AD Connect Health: Cloud-Service (Portal) zur Überwachung von Hybrid Identity Komponenten. Zeigt Status von AAD Connect, AD FS und PTA-Agenten an, inkl. Warnungen, Statistiken, E-Mail-Alerts. Erfordert Azure AD Premium P1. Ein Agent (in AADC integriert) sendet Gesundheitsdaten ans Azure-Portal.
• Staging Mode (Staging Server): Betriebsmodus für einen Azure AD Connect Server, bei dem dieser synchronisiert aber keine Änderungen exportiert. Dient als Passiv-Standby: Im Notfall kann man ihn zum aktiven Server machen. Ermöglicht auch Lasttests und Änderungen „trocken“ zu probieren.
• Azure AD Domain Services (AAD DS): Azure-Service, der ein verwaltetes AD in der Cloud bereitstellt (Domain-Join, LDAP, Gruppenrichtlinien in Azure ohne eigenen DC). Es synchronisiert sich aus Entra ID. Nicht zu verwechseln mit Azure AD selbst – AAD DS ist eher für legacy Anwendungen in Azure gedacht, die ein klassisches AD brauchen.
• Conditional Access: Azure AD Feature, um Zugriffsrichtlinien basierend auf Bedingungen festzulegen (z.B. MFA verlangen, wenn außerhalb Firmennetz; Zugriff verweigern, wenn Gerät nicht compliant). Spielt im Hybrid-Setup mit rein, weil es z.B. Gerätestatus aus Azure AD auswertet (daher Device Writeback früher nötig bei AD FS, heute via Cloud Join/Intune geregelt).
• Multi-Factor Authentication (MFA): Mechanismus, bei dem zusätzlich zum Passwort noch eine zweite Komponente zum Login verlangt wird (z.B. SMS, Authenticator-App). Azure AD bietet MFA out-of-the-box. In föderierten Szenarien konnte auch AD FS die MFA übernehmen, aber heute meist in Azure AD direkt umgesetzt.
• On-Premises: Bedeutet „vor Ort“ – hiermit ist die lokale IT-Infrastruktur gemeint (also Ihr Rechenzentrum bzw. Server, im Gegensatz zur Cloud). Oft abgekürzt „On-Prem“. Ein On-Premises AD = das klassische Active Directory bei Ihnen lokal.
• Cloud Kerberos Trust: Neuer Mechanismus für Windows Hello for Business (seit 2022), der es ermöglicht, Hybrid AD-Join und Passwortlose Anmeldung ohne lokale Key Trust oder Zertifikate. Ersetzt in gewisser Weise die Notwendigkeit von Device Writeback, da die Azure AD Geräte direkt für Kerberos authentifizieren können (Kerberos-TGT wird in Azure AD ausgestellt).
• Self-Service Password Reset (SSPR): Azure AD Funktion, mit der Endanwender ihr Kennwort selbst zurücksetzen können, nach Verifikation (z.B. via MFA). In Hybrid-Umgebungen zusammen mit Password Writeback genutzt, damit das zurückgesetzte Kennwort auch im lokalen AD gilt. Spart Helpdesk-Aufwand und erhöht die Sicherheit (weil Benutzer eher mal ihr Passwort aktualisieren).
• Microsoft Graph API: Zentrale API von Microsoft 365/Azure, um auf Verzeichnisdaten und Dienste zuzugreifen. Kann genutzt werden, um z.B. Informationen über synchronisierte Benutzer abzurufen oder Provisioning-Jobs zu steuern. Ersetzt nach und nach ältere separate APIs (MSOL, Azure AD Graph). Admins können via Graph z.B. eine Liste aller AD-synchronisierten Accounts ziehen oder Provisioning-Konfigurationen automatisieren.
• gMSA (Group Managed Service Account): Spezieller AD-Kontotyp für Dienste. Kennwort wird automatisch vom AD verwaltet. Ideal für Azure AD Connect oder Cloud Sync Agent, da so kein statisches Passwort hinterlegt werden muss und das Konto nicht von Menschen benutzt werden kann. Erhöht die Sicherheit und verringert den Wartungsaufwand.
• RACI: Akronym für Responsible, Accountable, Consulted, Informed – Methode zur Rollenklärung in Projekten/Betrieb. Legt für Aufgaben fest: wer führt aus (R), wer trägt die Gesamtverantwortung (A), wer wird beratend hinzugezogen (C) und wer muss informiert werden (I).
• Global Address List (GAL): Die globale Adressliste, insbesondere in Exchange/Outlook Kontext. In Hybrid-Umgebungen ist das die Gesamtliste aller Mail-Empfänger (Benutzer, Gruppen, Kontakte), die idealerweise Cloud und On-Prem gemeinsam abbildet. Synchronisierung und Writeback spielen zusammen, um eine einheitliche GAL bereitzustellen.
• HR-driven Provisioning: Szenario, bei dem das HR-System (Personalmanagement) der Startpunkt für Identitätsbereitstellung ist. Z.B. neuer Mitarbeiter in Workday -> automatisch Anlage eines AD-Kontos -> Sync zu Azure AD. Azure AD bietet hierfür Connectoren, sodass das HR-System als „Master“ für Userdaten fungieren kann. Hilft, manuelle Prozesse zu eliminieren und konsistente Stammdaten zu gewährleisten.

Anhang

Go-Live Checkliste Entra ID Sync

Bevor Sie den hybriden Abgleich live schalten bzw. einen entscheidenden Wechsel (z.B. auf Cloud-Auth) durchführen, gehen Sie folgende Punkte durch:

• Testlauf abgeschlossen: Pilot-Benutzer wurden synchronisiert und konnten sich erfolgreich anmelden. Alle vorgesehenen Features (SSO, Writeback etc.) wurden in einer kleinen Gruppe verifiziert.
• Keine Synchronisierungsfehler: Der Synchronisierungs-Manager (bzw. das Azure Portal bei Cloud Sync) zeigt grüne Status. Etwaige Warnungen wurden geprüft und als unkritisch befunden.
• Backup & Fallback bereit: Aktuelle Azure AD Connect Konfiguration exportiert. Staging-Server steht synchron bereit (oder Cloud Sync Agent redundant installiert). Notfallszenario (Zurückschalten auf vorherige Auth-Methode, etc.) ist dokumentiert.
• DNS & Firewall: Falls relevant, DNS-Einträge angepasst (z.B. logon-Seiten auf Microsoft umgeleitet, falls Federation entfernt wurde). Firewall-Regeln geprüft (Azure AD Connect und Agent erreichen alle benötigten Endpunkte).
• Kommunikation an Benutzer: Ankündigung/Mitteilung über evtl. Änderungen im Login (oder geplantes Wartungsfenster) an die Endanwender und den Helpdesk verschickt.
• Passwortrichtlinien abgestimmt: (Bei PHS) Sichergestellt, dass Passwortänderungen ab jetzt in beiden Systemen gelten. Ggf. Synchronisierung einmalig aller aktuellen Passwörter erzwungen (Full Sync).
• Letzter Sync vor Go-Live manuell: Kurz vor dem offiziellen Start noch einen manuellen Delta-Sync angestoßen, um sicherzugehen, dass wirklich alles aktuell ist.
• Team in Alarmbereitschaft: Direkt nach Go-Live sind zuständige Admins erreichbar und überwachen die Systeme engmaschig, um sofort eingreifen zu können, falls doch etwas klemmt.

Troubleshooting Checkliste (Kurzform)

Wenn es während des Betriebs hakt, nutzen Sie diese verkürzte Erinnerungsliste als Leitfaden:

1. Status prüfen: Azure AD Connect Health Dashboard oder Portal -> Synchronisierung ansehen. Rote Anzeigen oder spezielle Fehlermeldungen notieren.
2. Dienst & Netzwerk: Läuft der AD Connect Sync-Dienst bzw. Provisioning Agent? Internet und AD-Verbindung ok? (Eventlog auf Netzwerk-Errors checken.)
3. Spezifisches Problem eingrenzen: Einzelner User fehlt? -> Suchen Sie den User im Synchronization Service unter Connector Space. Login schlägt fehl? -> Abhängig von Auth-Methode PTA/ADFS/PHS untersuchen (PTA Agent Status, AD FS Eventlog, Azure AD Sign-In Logs).
4. Fehlermeldungen auswerten: Details der Fehler (Attribute conflict, permissions, etc.) anschauen und entsprechende Korrektur im AD oder Azure AD vornehmen.
5. Resync/Restart: Kleinere Hänger löst oft schon ein erneutes Synchronisieren oder Neustart des Dienstes. Delta-Sync via PowerShell starten (Start-ADSyncSyncCycle) bei Bedarf.
6. Microsoft Doku/Community bemühen: Fehlercode googeln/bingen – häufig gibt es bekannte Lösungen (z.B. ProxySettings in Synchronisierungs-Dienst setzen bei bestimmten HTTP-Fehlern, etc.).
7. Support einschalten: Wenn interne Mittel erschöpft sind, Case bei Microsoft eröffnen. Besser früh als zu spät.

Eine ausführlichere Anleitung finden Sie im Troubleshooting-Kapitel oben.

Failover/Notfall Checkliste

Sollte der primäre Synchronisierungsweg ausfallen, so gehen Sie wie folgt vor:

• Azure AD Connect (Staging-Failover): Staging-Server-Konfiguration prüfen (sollte aktuell sein). Auf dem Staging-Server den Synchronisierungsdienst aus dem Staging Mode nehmen (Export aktivieren). Auf dem ursprünglichen Server den Dienst stoppen, um Doppelarbeit zu vermeiden. Überprüfen, ob der neue aktive Server erfolgreich exportiert (Eintrag im Eventlog/Portal kontrollieren). Nach Behebung des Problems alten Server wieder als Staging einrichten, damit erneut Hochverfügbarkeit besteht.
• Cloud Sync Agent: Wenn ein Agent ausfällt, übernimmt automatisch ein anderer. Trotzdem: schnellstmöglich auf dem ausgefallenen Server Fehler beheben oder Agent deinstallieren und auf einem gesunden Server neu installieren, damit die Redundanz wieder erreicht wird.
• Pass-Through Auth: Fällt ein PTA-Agent aus und es sind nur noch z.B. 1 von 2 übrig, möglichst bald einen weiteren Agent installieren, um wieder Ausfallsicherheit herzustellen. Azure AD zeigt im Portal die Anzahl aktiver PTA-Agenten – bei „0“ könnten sich Nutzer nicht mehr anmelden!
• AD FS Fallback: Bei AD FS Ausfall (und PHS als Backup bereits eingerichtet): In Azure AD PowerShell Domäne von Federated auf Managed umstellen (Convert-MsolDomainToStandard). So werden Logins sofort über PHS abgewickelt. Parallel AD FS reparieren. Danach kann man entscheiden, ob man zurückstellt oder bei PHS bleibt.
• Kommunikation: Im Ernstfall interne IT und ggf. Benutzer informieren, falls z.B. vorübergehend nur Cloud-Login ohne SSO geht („Bitte geben Sie Ihr Passwort heute manuell ein, SSO wird gerade repariert“). Transparenz schafft Verständnis.

Durch regelmäßige Tests dieser Abläufe (z.B. halbjährliche Notfallübung) stellen Sie sicher, dass im Falle eines Falles jeder Handgriff sitzt.

 

Weitere Beiträge zum Thema Security und Compliance