Entra Hybrid Identity Sync: Cloud-Only- und verwaiste privilegierte Konten – der blinde Fleck im Hybrid-Audit

Entra Hybrid Identity Sync Cloud Only Privileged Orphaned Accounts erklärt

Entra Hybrid Identity Sync Cloud-only-privilegierte und verwaiste Konten bezeichnet die zwei blinden Flecken, um die es in diesem Artikel geht: Cloud-only-Konten mit privilegierten Microsoft-Entra-Rollen, die nie mit der On-Premises-Tier-0-Governance in Berührung kommen, und verwaiste synchronisierte Benutzer, die Entra Connect zurücklässt, nachdem ihr On-Premises-Konto gelöscht wurde. Beide fallen durch die Maschen der Sync-Pipeline, die die meisten Objekte sauber zwischen der On-Premises Active Directory und Microsoft Entra ID fließen lässt, und beide sind Audit-blinde Flecken, die spezifisch für Hybrid-Umgebungen sind – nicht für eine der beiden Seiten allein.

Der erste ist das Cloud-only-privilegierte Konto: ein Benutzer, der direkt in Entra ID angelegt wurde, nie aus dem On-Premises-AD synchronisiert wurde und eine aktive oder PIM-eligible Microsoft-Entra-Rolle innehat. Der zweite ist der verwaiste synchronisierte Benutzer: ein Objekt, das Entra Connect einst aus dem AD synchronisiert hat, dessen On-Premises-Quellkonto inzwischen gelöscht oder aus dem Sync-Scope ausgeschlossen wurde, dessen Entra-ID-Objekt aber nie sauber entfernt wird. Keines von beiden taucht in den Audits auf, die die meisten Hybrid-Organisationen bereits durchführen, weil diese Audits um jeweils eine Seite der Sync-Grenze herum aufgebaut sind – ein On-Premises-Tiering-Review scannt das AD, und selbst ein umfassendes Entra ID Security Audit geht meist davon aus, dass jede Identität noch ein lebendes On-Premises-Gegenstück hat.

Cloud-Only-privilegierte Konten: Eine bewusste Lücke, die On-Prem-Audits nicht sehen

Tier-0-Konten aus der Verzeichnissynchronisierung herauszuhalten ist kein Fehler – es ist Microsofts dokumentierte Empfehlung. Microsofts eigene Anleitung stellt unmissverständlich fest, dass „Tier-0-Administratorkonten nur für On-Premises-AD-Konten verwendet werden. Solche Konten werden typischerweise nicht mit Microsoft Entra ID in der Cloud synchronisiert", und separat, dass „Konten von Global Administrator (und anderen privilegierten Gruppen) reine Cloud-Konten ohne Verbindung zum On-Premises Active Directory sein sollten" (Secure access practices for administrators in Microsoft Entra ID).

Der blinde Fleck ist nicht die Architektur – es ist die Governance-Lücke, die sich darum herum auftut. Ein On-Premises-Tiering-Review (ob als manuelles Audit gegen ein Modell wie ANSSIs Tier-Modell oder mit einem Tool wie PingCastle, das das AD scannt) hat überhaupt keine Sichtbarkeit auf Entra-ID-Rollenzuweisungen, weil ein Cloud-only-Konto von vornherein nie On-Premises existiert hat. Wenn das Cloud-seitige Governance-Programm nicht auf dieselbe Sorgfalt ausgebaut wurde – PIM-eligible Zuweisung statt dauerhaftem Zugriff, Conditional Access, die bei der Aktivierung MFA und ein konformes Gerät verlangt, und periodische Access Reviews –, kann ein Cloud-only Global Administrator mit einer dauerhaften aktiven Zuweisung, ohne MFA-Durchsetzung und ohne Aktivierungsprotokollierung bestehen, unsichtbar für beide Hälften des Audit-Programms gleichzeitig.

Diese Lücke hat eine konkrete Angriffsfläche. SyncJacking ist eine Hard-Match-Übernahmetechnik, vom Microsoft Security Response Center als Privilege-Escalation-Problem mit dem Schweregrad „Important" bestätigt, bei der ein Angreifer, der Attribute eines On-Premises-AD-Objekts kontrolliert, Entra Connect dazu zwingen kann, dieses Objekt per Hard Match auf einen bestehenden Cloud-verwalteten Benutzer zu übertragen – einschließlich eines privilegierten – und dessen Source of Authority zu übernehmen. Die Technik „hinterlässt keine Spuren in den On-Premises-AD-Protokollen und nur minimale Spuren in den Entra-ID-Protokollen" (Semperis: Syncjacking Could Enable Entra ID Account Takeover).

Microsoft hat inzwischen eine Mitigation auf Plattformebene ausgeliefert. Laut Microsofts eigener Troubleshooting-Dokumentation: „Ab dem 1. Juli 2026 erzwingt Microsoft Entra ID automatisch die Hard-Match-Sicherheitshärtung", die einen Hard Match blockiert, sobald für das Ziel-Cloud-Konto bereits onPremisesObjectIdentifier gesetzt ist, es eine aktive privilegierte Entra-Rolle innehat oder für eine solche eligible ist (Microsoft Entra Connect: Troubleshoot errors during synchronization — InvalidHardMatch). Diese Härtung schützt den Übernahmeweg – sie schließt nicht die Governance-Lücke, die es einem unüberwachten Cloud-only-Admin überhaupt erst ermöglicht hat zu existieren, und genau darauf zielen die Erkennungs- und Behebungsabschnitte dieses Artikels ab. Es lohnt sich außerdem, diesen Access-seitigen Review mit den Notfallzugangskonten zu koppeln, die jeder Tenant für ein echtes Break-Glass-Szenario vorhält – siehe Entra ID Break-Glass-Kontenhygiene dafür, wie diese konkret abgegrenzt werden sollten (und wie nicht).

Verwaiste synchronisierte Benutzer: Was passiert, wenn Entra Connect ein gelöschtes On-Prem-Konto nicht entfernt

Auf der anderen Seite der Grenze garantiert das Löschen eines Benutzers im On-Premises-AD nicht, dass sein Entra-ID-Zwilling verschwindet. Zwei dokumentierte Mechanismen lassen synchronisierte Objekte zurück:

Schutz vor versehentlichem Löschen. Microsoft Entra Connect wird standardmäßig mit aktiviertem Löschschutz ausgeliefert, gedeckelt auf 500 Objektlöschungen pro Export-Zyklus. Wenn ein Massen-Cleanup On-Prem, eine OU-Verschiebung oder ein defekter Sync-Filter dazu führt, dass in einem Lauf mehr als der Schwellenwert gelöscht wird, stoppt der Export einfach – der Synchronization Service Manager meldet stopped-deletion-threshold-exceeded beim Export-Schritt, und jede dieser Löschungen bleibt in Entra ID unangewendet, bis ein Administrator sie überprüft und den Job fortsetzt (Microsoft Entra Connect Sync: Prevent accidental deletes). In der Praxis bedeutet das: Eine einzige unbemerkte Schwellenwertüberschreitung kann Dutzende gelöschter On-Prem-Konten zurücklassen, die in der Cloud weiterhin vollständig aktiv und synchronisiert aussehen.

Scope-Ausschluss ohne Konvertierung. Wenn ein Objekt aus dem Sync-Scope verschoben wird (zum Beispiel durch eine Änderung des OU-/Gruppenfilters), statt komplett gelöscht zu werden, führt Entra Connect ein Soft-Delete des Entra-ID-Objekts durch und setzt DirSyncEnabled auf False – aber laut Microsofts eigener Dokumentation „konvertiert dieser Prozess das Objekt jedoch nicht zu einem Cloud-verwalteten Objekt, es gilt weiterhin als ein aus dem On-Premises Active Directory synchronisiertes Objekt" und bleibt weiterhin für einen erneuten Hard Match berechtigt (Microsoft Entra Connect: Troubleshoot errors during synchronization). Ein Benutzer in diesem Zustand ist weder sauber gelöscht noch wirklich cloud-nativ – es ist ein halb migriertes Objekt, für das die meisten Access Reviews keinen passenden Eimer haben, ähnlich im Geiste den veralteten privilegierten Konten, die On-Prem-Audits bereits markieren, außer dass dieses hier von der AD-Seite aus unsichtbar ist, weil das Quellobjekt bereits verschwunden ist.

Erkennung: Cloud-only-privilegierte und verwaiste synchronisierte Konten finden

Die Eigenschaft onPremisesSyncEnabled der Microsoft-Graph-Ressource user ist der Ankerpunkt für beide Checks: Sie liefert true für ein aktiv synchronisiertes Objekt, false für ein Objekt, das einmal synchronisiert wurde, es aber nicht mehr ist, und null für ein Objekt, das nie synchronisiert wurde – also wirklich cloud-nativ ist.

Microsoft Graph nach Waisen-Kandidaten abfragen

Um die Liste der zurückgesetzten SOA / Waisen-Kandidaten direkt abzurufen, dokumentiert Microsoft diese Graph-Abfrage:

GET https://graph.microsoft.com/v1.0/users?$count=true&$filter=OnPremisesSyncEnabled ne true and OnPremisesImmutableId ne null

(Quelle: How to audit and monitor User Source of Authority (SOA) in Microsoft Entra ID.) Erweiterte Filter auf onPremisesSyncEnabled benötigen unter Umständen den Header ConsistencyLevel: eventual sowie $count=true, um zuverlässig Ergebnisse zu liefern.

Privilegierte Rollen gegen den Sync-Status abgleichen

Für die Cloud-only-privilegierte Seite: Rollenzuweisungen (PIM-eligible und aktiv) gegen den Sync-Status abgleichen:

# Users with an active or eligible Entra role that were never synced from on-prem
Get-MgUser -Filter "onPremisesSyncEnabled eq null" -ConsistencyLevel eventual -CountVariable c -All |
    Where-Object { (Get-MgUserMemberOf -UserId $_.Id) -match "RoleAssignable" }

Behebung

Die Cloud-Only-privilegierte Lücke schließen

1. Tier-0-Governance auf Cloud-only-privilegierte Konten ausweiten. Jedes Cloud-only-Konto mit aktiver oder eligible Entra-Rolle sollte tragen: PIM-eligible (nicht dauerhafte) Zuweisung, eine Conditional-Access-Richtlinie, die bei der Aktivierung MFA und ein konformes/verwaltetes Gerät verlangt (viele Tenants haben hier Lücken – siehe Conditional-Access-Baseline-Abdeckungslücken), und Einbindung in denselben periodischen Access Review wie On-Premises-Tier-0 – siehe Hygiene verschachtelter und rollenfähiger Gruppen für das Gruppen-seitige Äquivalent derselben Lücke.
2. Die Ausnahme eng halten. Die einzigen Konten, die vollständig außerhalb von PIM- und CA-Kontrolle stehen sollten, sind echte Break-Glass-Notfallzugangskonten – zwei, cloud-only, überwacht, gemäß Microsofts Anleitung (siehe Break-Glass-Kontenhygiene). Alles andere, das als „cloud-only, weil Tier 0 nicht synchronisieren sollte" bezeichnet wird, braucht trotzdem einen Owner und einen Review-Rhythmus.

Verwaiste synchronisierte Benutzer bereinigen

3. Den Schutz vor versehentlichem Löschen anpassen, statt ihn blind hochzusetzen. Bestätigen Sie, dass der Export-Löschschwellenwert (Enable-ADSyncExportDeletionThreshold) bewusst für Ihre Umgebung gesetzt ist, leiten Sie die Stopp-Benachrichtigung an ein überwachtes Postfach weiter, und behandeln Sie jedes stopped-deletion-threshold-exceeded-Ereignis als Untersuchungsauslöser, bevor Sie den Export fortsetzen – ein Fortsetzen ohne Review ist genau das, was aus einer Konfigurationsänderung Dutzende lebendige Waisen macht.
4. Veralteten Sync-Status planmäßig abgleichen. Fragen Sie onPremisesSyncEnabled = false mit einem alten onPremisesLastSyncDateTime ab, bestätigen Sie gegen das On-Premises-AD, ob das Quellobjekt noch existiert, und stellen Sie entweder das Mapping wieder her oder deprovisionieren Sie das Cloud-Objekt formell – lassen Sie es nicht im halb migrierten Zustand.
5. Löschungen in einen governten Leaver-Prozess einbinden. Microsoft Entra ID Governance Lifecycle Workflows können Deaktivierungs-/Zugriffsentzugs-/geplante Löschaufgaben auf Basis eines autoritativen Signals (HR-Feed oder AD-Attribut) auslösen, statt sich allein auf den Sync-Export zu verlassen, um ein Offboarding zu propagieren – das fängt den Fall ab, in dem der Export stillschweigend fehlschlägt.

Auf die Hard-Match-Härtung vorbereiten

6. Die Hard-Match-Härtung jetzt planen, nicht erst am 1. Juli 2026. Jeder Prozess, der davon abhängt, ein privilegiertes oder PIM-eligible Cloud-Konto erneut mit einem On-Premises-Objekt zu matchen (Forest-Recovery, Tenant-Migrations-Runbooks), wird standardmäßig blockiert, sobald Microsofts Härtung greift. Testen Sie Ihre Recovery-Runbooks gegen den dokumentierten Workaround – die Rolle oder Eligibility vorübergehend entfernen, den Hard Match abschließen und sie anschließend wiederherstellen –, bevor Sie das unter Incident-Druck brauchen.

Wie EtcSec dies erkennt

EtcSecs Entra-ID-Checks markieren beide Seiten dieser Lücke direkt: HYBRID_CLOUD_ONLY_PRIVILEGED erfasst Cloud-only-Benutzer mit einer privilegierten Rolle, und HYBRID_ORPHANED_CLOUD_USER erfasst Objekte, deren Sync-Status auf einen wahrscheinlichen Waisen hindeutet. Diese werden gepaart mit UNRESOLVED_PRIVILEGED_MEMBERS (privilegierte Rollenzuweisungen, die auf einen nicht mehr auflösbaren Principal verweisen), PA_ADMIN_STALE_ACCOUNT (administrative Konten ohne aktuelle Aktivität) und PA_GLOBAL_ADMIN_NOT_MFA (Global Administrators ohne erzwungene MFA), sodass ein Cloud-only-privilegiertes Konto nicht nur erkannt, sondern auch gegen dieselbe Access-Hygiene-Messlatte geprüft wird wie jede andere Tier-0-Identität.