← Microsoft Entra ID & Microsoft 365 Administration

Verzeichnisabgleich und hybride Objekte

Die Telefonnummer ist korrigiert, gespeichert, und zwei Tage später steht wieder der alte Wert da — ohne Fehlermeldung, ohne Protokolleintrag. Nicht weil jemand sie zurückgesetzt hätte, sondern weil die Änderung an einer Kopie stattfand und der Abgleich die maßgebliche Quelle durchsetzt. Dieses Modul behandelt die Cloud-Seite hybrider Objekte: woran du eine abgeglichene Identität erkennst, welche Attribute gesperrt sind, warum ein gelöschtes Konto am nächsten Morgen wieder da ist und welche Schalter im Tenant eine Sperrfrist von 72 Stunden auslösen. Der Aufbau des Abgleichs selbst steht im Active-Directory-Track.

Lehrtext · 12 Abschnitte · zuletzt geprüft: 2026-09-12

Die Cloud-Sicht auf ein Objekt, das anderswo entsteht

In einer hybriden Umgebung entstehen Benutzer und Gruppen im lokalen Active Directory und erscheinen anschließend in Microsoft Entra ID. Für den Betrieb der Cloud-Seite ist entscheidend, dass diese Objekte dort anders sind als selbst angelegte: Sie sehen im Portal gleich aus, lassen sich aber nur teilweise bearbeiten, kommen nach dem Löschen unter Umständen zurück, und einige ihrer Eigenschaften sind an eine Quelle gebunden, die außerhalb der Cloud liegt.

Wo dieses Modul aufhörtWie der Abgleich aufgebaut wird — Topologie, die Wahl zwischen Kennwort-Hashsynchronisierung, Passthrough und Föderation, der Quellanker mit Hart- und Weichabgleich, der Abgleichsserver als besonders schützenswertes System — steht im Modul hybrid-identity des Active-Directory-Tracks und wird hier nicht wiederholt. Dieses Modul beantwortet die Frage danach: Was heißt das für den Betrieb im Tenant?

Source of Authority — Die Stelle, an der ein Attribut verbindlich gepflegt wird. Für synchronisierte Objekte liegt sie im lokalen Verzeichnis — die Cloud führt eine Kopie, die sie selbst nicht korrigieren darf.

Das klingt nach einer Formalie und ist der häufigste Grund für verlorene Arbeitszeit in hybriden Tenants: Jemand ändert etwas im Portal, es sieht aus, als hätte es funktioniert, und beim nächsten Abgleich ist der alte Wert zurück.

Woran du ein synchronisiertes Objekt erkennst

Die Unterscheidung ist keine Interpretationsfrage, sondern steht in einer Eigenschaft. onPremisesSyncEnabled ist true, solange ein Objekt aus einem lokalen Verzeichnis abgeglichen wird — andernfalls lässt es sich in Entra ID verwalten. Die Eigenschaft ist selbst schreibgeschützt.

Daneben stehen mehrere Felder, die ausschließlich bei abgeglichenen Objekten gefüllt sind. Sie sind alle schreibgeschützt und zusammen die beste Diagnosegrundlage, wenn unklar ist, woher ein Objekt stammt:

onPremisesSyncEnabled: true, solange das Objekt abgeglichen wird. Die Leitfrage vor jeder Änderung.
onPremisesLastSyncDateTime: Zeitpunkt des letzten Abgleichs. Ein alter Wert heißt, dass der Abgleich steht — nicht, dass das Objekt reines Cloud-Objekt wäre.
onPremisesDistinguishedName: Der lokale DN. Sagt, wo im Verzeichnis das Objekt liegt — nützlich, um den zuständigen Bereich zu finden.
onPremisesSamAccountName: Der lokale Anmeldename, der in der Cloud nicht zur Anmeldung dient.
onPremisesSecurityIdentifier: Die lokale SID des Objekts.
onPremisesProvisioningErrors: Fehler, die beim Bereitstellen aufgetreten sind. Der erste Ort, an dem man nachsieht, wenn ein Objekt unvollständig wirkt.

Die nützlichste Abfrage überhauptDiese Felder werden nicht automatisch mitgeliefert — sie verlangen laut Dokumentation ein ausdrückliches $select. Wer sie in einem Skript vermisst, hat oft keinen leeren Wert gefunden, sondern schlicht nicht danach gefragt.

Schreibgeschützt: was die Cloud nicht ändern darf

Bei einem abgeglichenen Objekt sind die aus dem lokalen Verzeichnis stammenden Attribute in der Cloud gesperrt. Das betrifft nicht nur Exoten: Auch businessPhones und mobilePhone sind laut Dokumentation schreibgeschützt für Benutzer, die aus dem lokalen Verzeichnis abgeglichen werden — bei reinen Cloud-Konten dagegen nicht.

Der praktische Effekt ist unangenehm, weil er nicht überall gleich aussieht. Über die Graph-API kommt eine Fehlermeldung. Im Portal sind die Felder oft ausgegraut. In manchen Verwaltungsoberflächen lässt sich der Wert eintippen, und erst der nächste Abgleich setzt ihn zurück — der Irrtum hat dann eine Halbwertszeit von Stunden und wird als Fehler gemeldet, nicht als Missverständnis.

Rückschreiben — Der umgekehrte Weg: Bestimmte in der Cloud entstandene Angaben können in das lokale Verzeichnis zurückgeschrieben werden. Das ist eine ausdrücklich einzuschaltende Funktion je Objektart, kein Standardverhalten — Gruppenrückschreiben und Geräterückschreiben gibt es, ein allgemeines Rückschreiben von Benutzern nennt die Dokumentation als nicht unterstützt.

Aus dieser Asymmetrie folgt eine Planungsregel, die vor vielen Sackgassen bewahrt: Der Abgleich ist grundsätzlich eine Einbahnstraße von lokal nach Cloud, und jede Gegenrichtung ist eine benannte Ausnahme, die eingeschaltet sein muss. Wer eine Lösung entwirft, in der ein in der Cloud gepflegtes Feld lokal ankommen soll, muss zuerst prüfen, ob es für diese Objektart überhaupt einen Rückweg gibt — und wenn nicht, entweder die Quelle wechseln oder auf das Feld verzichten.

Nicht verwechseln sollte man das mit dem Kennwortrückschreiben, das die Kennwortzurücksetzung durch Benutzer in der Cloud an das lokale Verzeichnis weitergibt. Die Dokumentation führt es ausdrücklich nicht als Merkmal des Abgleichsdienstes auf dieser Ebene, sondern verweist für die Einrichtung auf die Abgleichssoftware selbst. Wer es an der falschen Stelle sucht, hält es für abgeschaltet, obwohl es läuft.

Die Ausnahme, die man kennen muss: Erweiterungsattribute

Bei den Erweiterungsattributen extensionAttributes1 bis 15 — in der Exchange-Welt als benutzerdefinierte Attribute bekannt, je bis zu 1.024 Zeichen — gilt eine Dreiteilung, die sonst nirgends so steht.

Abgeglichenes Objekt: Die Quelle liegt lokal, die Attribute sind in der Cloud schreibgeschützt.
Reines Cloud-Objekt: Die Attribute lassen sich beim Anlegen und Ändern setzen.
Früher abgeglichenes, jetzt reines Cloud-Objekt: In Microsoft Graph schreibgeschützt — über das Exchange-Admin-Center oder das Exchange-Online-Modul in PowerShell aber vollständig verwaltbar.

Warum das lehrreich istDer dritte Fall ist der interessante: Dasselbe Attribut desselben Objekts ist über eine Schnittstelle gesperrt und über eine andere offen. Wer aus einem Fehler in Graph schließt, die Änderung sei unmöglich, liegt falsch — sie ist nur woanders zu machen. Das ist der Grund, warum die Frage immer lauten muss, wo etwas zu ändern ist, nicht ob.

Reines Cloud-Konto ist eine Entscheidung, keine Restmenge

In einer hybriden Umgebung ist die Versuchung groß, alles aus dem lokalen Verzeichnis zu beziehen — es ist der gewohnte Ort, und der Abgleich macht die Arbeit. Für bestimmte Objekte ist das falsch, und zwar aus einem strukturellen Grund: Sie müssen den Ausfall des lokalen Verzeichnisses überleben.

Notfallzugangskonten — aus dem ersten Modul: ausdrücklich als reine Cloud-Konten empfohlen, damit sie nicht mit dem lokalen Verzeichnis ausfallen.
Rollenfähige Gruppen — sie tragen Verzeichnisrollen und sollen nicht davon abhängen, wer lokal eine Gruppenmitgliedschaft ändern darf.
Dienstprinzipale und verwaltete Identitäten — sie existieren ausschließlich in der Cloud und haben im lokalen Verzeichnis keine Entsprechung.

Die Regel dahinter ist einfach und trägt weit: Wer eine Abhängigkeit vom lokalen Verzeichnis erzeugt, muss sie begründen können. Der Abgleich ist bequem, aber er ist auch eine Kopplung — und jede Kopplung überträgt Ausfälle.

Der Preis dieser Trennung wird gern übersehen. Reine Cloud-Objekte fallen aus jedem Ablauf heraus, der am lokalen Verzeichnis hängt: Sie erscheinen nicht in den gewohnten Berichten, sie werden beim Austritt einer Person nicht automatisch mitdeaktiviert, und sie brauchen eine eigene wiederkehrende Überprüfung. Genau deshalb ist die Liste oben kurz — jedes zusätzliche reine Cloud-Objekt ist ein Objekt, an das jemand gesondert denken muss.

Die Probe aufs ExempelEine brauchbare Prüffrage für jedes Objekt lautet: Wenn das lokale Verzeichnis eine Woche lang nicht erreichbar wäre — müsste dieses Objekt dann funktionieren? Lautet die Antwort ja, gehört es in die Cloud. Lautet sie nein, gehört es in den Abgleich, und die Kopplung ist begründet.

Doppelte Werte: das Objekt mit dem Namen, den niemand gewählt hat

Zwei Objekte mit demselben Anmeldenamen oder derselben Adresse sind im lokalen Verzeichnis möglich, in der Cloud nicht. Früher scheiterte in so einem Fall der gesamte Objektexport. Seit 2016 ist für neue Verzeichnisse die Widerstandsfähigkeit gegen doppelte Attribute standardmäßig aktiv, und sie verhält sich anders, als die meisten erwarten.

Statt das Objekt abzulehnen, wird das doppelte Attribut in Quarantäne genommen und ein vorläufiger Wert vergeben. Das Objekt existiert also — mit einem Anmeldenamen, den niemand ausgewählt hat. Wird der Konflikt in der Quelle aufgelöst, ersetzt das System den vorläufigen Wert automatisch durch den richtigen.

Was das im Betrieb bedeutetEin Konto, das sich nicht anmelden lässt, obwohl es „da ist“, hat oft genau diesen Zustand. Die Fehlersuche führt nicht über Berechtigungen, sondern über onPremisesProvisioningErrors und den Vergleich des tatsächlichen mit dem erwarteten Anmeldenamen. Der Vorteil der Funktion ist echt — ein Objekt statt gar keinem —, der Preis ist ein stiller Zwischenzustand, der ohne gezielte Prüfung unentdeckt bleibt.

Weichabgleich: warum Microsoft empfiehlt, ihn zu sperren

Der Weichabgleich verbindet ein lokales Konto mit einem bereits vorhandenen Cloud-Konto, wenn beide dieselbe primäre Adresse tragen — auf Wunsch zusätzlich über den Anmeldenamen. Das ist bei der Einführung nützlich und danach ein offener Weg, den man nicht offen lassen sollte.

Die Dokumentation ist hier ungewöhnlich direkt: Kunden werden ausdrücklich ermutigt, die Funktion BlockSoftMatchEnabled einzuschalten und eingeschaltet zu lassen, bis der Weichabgleich wieder gebraucht wird — und ihn danach sofort wieder zu sperren. Der Grund ist die Wirkung: Wer im lokalen Verzeichnis ein Objekt mit der passenden Adresse anlegt, übernimmt damit ein bestehendes Cloud-Konto.

Get-MgDirectoryOnPremiseSynchronization: Liest die Merkmale auf Tenant-Ebene — braucht den Bereich OnPremDirectorySynchronization.Read.All.
Update-MgDirectoryOnPremiseSynchronization: Setzt sie — braucht OnPremDirectorySynchronization.ReadWrite.All.
SoftMatchOnUpnEnabled: Erlaubt den Weichabgleich zusätzlich über den Anmeldenamen; über die primäre Adresse ist er immer möglich.
BlockSoftMatchEnabled: Sperrt den Weichabgleich vollständig. Die empfohlene Ruhestellung.

Die ehrliche KehrseiteIst die Sperre aktiv und es steht eine Migration an, schlagen Zusammenführungen fehl, bis jemand sie bewusst aufhebt. Genau das ist der Zweck — aber es heißt, dass die Sperre in einem Ablauf auftauchen muss, sonst sucht ein Team stundenlang nach einem Fehler, den es selbst eingeschaltet hat.

Löschen im Hybrid: was zurückkommt und was nicht

Ein gelöschtes Benutzerkonto bleibt 30 Tage in einem ausgesetzten Zustand und lässt sich in dieser Zeit mit allen Eigenschaften wiederherstellen. Danach beginnt die endgültige Löschung automatisch und lässt sich laut Dokumentation nicht mehr anhalten; danach kann weder die Organisation noch der Hersteller das Konto zurückholen.

Im hybriden Fall kommt eine Eigenheit hinzu, die man einmal gelesen haben muss. Ein abgeglichenes Konto lässt sich in Entra ID löschen — aber Entra ID ist für dieses Konto nicht die maßgebliche Quelle. Existiert der Benutzer lokal weiter, stellt der Abgleich ihn beim nächsten Durchlauf möglicherweise wieder her.

Die Konsequenz für einen AustrittWer ein Konto aus Sicherheitsgründen sperren will, erreicht das nicht durch Löschen in der Cloud. Die Sperre gehört an die Quelle — sonst entsteht ein Wechselspiel aus Löschen und Wiederkehren, das im Protokoll aussieht wie ein Angriff und keiner ist.

Und noch eine Falle im selben Zeitraum: Während der endgültigen Löschung ist die Verwaltung vorläufig gelöschter Benutzer blockiert. Das gilt ausdrücklich auch für die Wiederherstellung über eine Übereinstimmung im Abgleichszyklus — der Weg, auf den man in hybriden Umgebungen intuitiv setzt, steht genau dann nicht zur Verfügung.

Wiederherstellen bringt die Lizenzen mit

Beim Wiederherstellen eines Kontos werden laut Dokumentation auch die Lizenzen wiederhergestellt, die ihm zum Zeitpunkt der Löschung zugewiesen waren — auch dann, wenn keine mehr verfügbar sind. Die Organisation verbraucht dann vorübergehend mehr Lizenzen als gekauft und ist damit kurzzeitig nicht regelkonform.

Das verbindet dieses Modul mit der Lizenzierung: Wer knapp kalkuliert und gleichzeitig viele Konten löscht und wiederherstellt, erzeugt einen Bestand, der rechnerisch nicht aufgeht. Sichtbar wird das nicht als Fehler, sondern als Abweichung in der Abrechnung.

Der praktische SchlussWiederherstellung ist kein neutraler Vorgang. Sie bringt den vollständigen früheren Zustand zurück — samt Zuweisungen, die inzwischen jemand anderes belegt. Nach jeder Wiederherstellung gehört deshalb ein Blick auf den Lizenzzustand des Kontos.

Zusammen mit dem vorigen Abschnitt ergibt das eine Reihenfolge für den Austrittsfall, die sich lohnt: erst an der Quelle deaktivieren, dann die Lizenz über die Gruppenmitgliedschaft entziehen, dann eine Aufbewahrungsfrist abwarten — und erst danach löschen. Wer mit dem Löschen beginnt, verliert die Steuerung über beides, weil das Konto entweder zurückkehrt oder nach dreißig Tagen endgültig verschwindet, samt allem, was daran hing.

Wenn der Abgleich aufhört: eine Entscheidung mit Sperrfrist

Der Abgleich lässt sich auf Tenant-Ebene abschalten; die abgeglichenen Objekte werden dabei zu reinen Cloud-Objekten. Den Zustand liest man mit Get-MgOrganization | Select OnPremisesSyncEnabled, gesetzt wird er über Update-MgOrganization mit onPremisesSyncEnabled = $false.

Zwei Dinge stehen ausdrücklich in der Dokumentation und machen das zu einer Entscheidung, keiner Maßnahme. Erstens: Nach dem Abschalten muss man 72 Stunden warten, bevor sich der Abgleich wieder einschalten lässt. Zweitens: Der Vorgang löscht die lokalen Eigenschaften am Objekt — die Herkunftsangaben aus dem zweiten Abschnitt sind danach weg.

Was die Dokumentation ausdrücklich abrätDen Abgleich zur Fehlersuche abzuschalten. Soll er dauerhaft enden, ist zuerst die Abgleichssoftware zu entfernen — sonst zeigt das Portal den Abgleich als deaktiviert, während einzelne Zusatzfunktionen weiter als aktiviert erscheinen. Das richtet laut Dokumentation keinen Schaden an, ergibt aber einen Zustand, den niemand mehr richtig deuten kann.

Durchgerechnet: eine Telefonnummer ändern

Die Änderung, die dreimal verschwindet

Szenario

Der Servicedesk meldet, dass die Mobilnummer einer Kollegin im Adressbuch falsch ist. Sie wird im Entra-Portal korrigiert. Zwei Tage später ist der alte Wert zurück. Die Korrektur wird wiederholt, mit demselben Ergebnis.

Anforderungen

Der richtige Wert soll dauerhaft stehen.
Der Weg soll auch für die nächsten Fälle gelten.
Es soll nachvollziehbar sein, warum die ersten Versuche scheiterten.

Schritte

Herkunft bestimmen: onPremisesSyncEnabled des Kontos abfragen — mit ausdrücklichem $select, sonst kommt das Feld gar nicht zurück.
Ist der Wert true, ist die Frage beantwortet: mobilePhone ist für abgeglichene Benutzer schreibgeschützt, und jede Cloud-Änderung hält nur bis zum nächsten Durchlauf.
Über onPremisesDistinguishedName den Ort im lokalen Verzeichnis bestimmen und damit das zuständige Team.
Die Änderung dort vornehmen — an der maßgeblichen Quelle.
Mit onPremisesLastSyncDateTime prüfen, dass seither ein Abgleich gelaufen ist, und erst dann den Wert in der Cloud gegenlesen.

Merksatz: Die ersten beiden Versuche waren keine Fehlbedienung. Sie waren eine Änderung an einer Kopie — und Kopien werden überschrieben.

Der Preis dieses Weges ist echt und wird oft unterschätzt: Er dauert länger und braucht ein zweites Team. Für den Servicedesk heißt das, eine Änderung nicht selbst abschließen zu können, und der Rückkanal an die betroffene Person wird ungenauer. Wer diesen Aufwand vermeiden will, muss das Attribut in die Cloud verlagern — und damit die Quelle wechseln, nicht die Oberfläche.

Die Reihenfolge, die alles zusammenhält

Vor jeder Änderung onPremisesSyncEnabled abfragen→Bei true die maßgebliche Quelle bestimmen, nicht die bequemste Oberfläche→Bei reinen Cloud-Objekten prüfen, ob sie bewusst so gewählt sind→Löschen an der Quelle vornehmen, sonst kehrt das Objekt zurück→Nach Wiederherstellung und Abgleich das Ergebnis gegenlesen, nicht annehmen

Erst die Quelle, dann die Änderung

Alle Befunde dieses Moduls sind Varianten eines einzigen Satzes: In einer hybriden Umgebung ist das Portal nicht immer der Ort, an dem etwas entschieden wird. Es ist manchmal nur der Ort, an dem man das Ergebnis sieht.

Gleich im CheckDie Übungen prüfen die Bestimmung der Herkunft, die Grenzen des Schreibzugriffs, das Verhalten beim Löschen im Hybrid, den vorläufigen Wert bei doppelten Attributen und das Abschalten des Abgleichs mit seiner Sperrfrist.

Jetzt anwenden

Diesen Stoff gibt es als Modul mit bewerteten Entscheidungs-Checks — dieselbe Einführung, danach die Übungen.

Zum Modul →

Quellen & Aktualität6 Primärquellen · zuletzt geprüft: 2026-09-12