Der Source-of-Authority-Wechsel holt AD-Gruppen ohne Neuanlage in die Cloud

In vielen Projekten begegnen mir Gruppen, die einst im lokalen AD angelegt wurden, heute aber fast nur noch in der Cloud gebraucht werden: als moderne Verteilerlisten in Exchange Online, als Berechtigungsgruppen für SharePoint, Teams oder SaaS-Anwendungen, für Conditional Access oder sogar für Copilot-Berechtigungen. Sobald das lokale AD allmählich zur reinen Altlast wurde, steckten Admins bisher in der Zwickmühle. Entweder verwaltete man die Gruppen weiter on-premises und pflegte sie mühsam doppelt, oder man löschte sie und legte sie in Entra ID komplett neu an – mit allen Risiken für Mitgliedschaften, Mailadressen und Verknüpfungen zu Ressourcen oder Rollen. So manche Cloud-only-Strategie ist genau daran ins Stocken geraten. Mit der Preview des Source-of-Authority-Switch (SOA) für Gruppen in Entra ID hat sich das grundlegend geändert. Das Feature hat viel Potenzial, bringt aber auch ein paar Fallstricke mit.

Nach dem SOA-Wechsel wird die Gruppe nur noch in der Cloud verwaltet

Mit dem SOA-Switch wandle ich eine aus dem lokalen AD synchronisierte Gruppe in eine cloudverwaltete Gruppe um, ohne sie neu erstellen zu müssen. Die Gruppe bleibt dabei mit allen Attributen, ihrer Objekt-ID und ihren Zugriffsrechten in Entra ID bestehen. Mitglieder, Attribute und Namensänderungen pflegt man ab sofort aber ausschließlich in der Cloud. Für hybrid aufgestellte Organisationen, die konsequent auf Cloud-only-Identitäten hinarbeiten, ist das ein großer Schritt, gerade bei Distribution Groups in Exchange Online, Sicherheitsgruppen für Cloud-Apps oder Teams-Berechtigungen.

Nach dem SOA-Wechsel trägt die Gruppe die Quelle „Cloud“ und hängt nicht mehr von weiteren Synchronisationen aus dem lokalen AD ab. Änderungen on-premises werden ignoriert, die Gruppe verhält sich nun wie eine „native“ Entra-Gruppe. Objekt-ID, E-Mail-Adressen und bestehende Zuweisungen (z. B. zu Teams, SharePoint, Rollen) bleiben erhalten. In der Praxis sollte man sich allerdings klarmachen, dass die lokale AD-Quelle nach dem Wechsel abgeschnitten ist. Was dort noch geändert wird, kommt nicht mehr an.

In fast jedem Tenant warten AD-Gruppen auf den Umzug in die Cloud

Besonders interessant ist der SOA-Switch für Umgebungen, in denen Gruppen nur deshalb noch im AD gepflegt werden, weil sie irgendwann als „Universalgruppe“ oder Verteiler für Exchange on-premises angelegt wurden. Solche Relikte finde ich in fast jedem Tenant, den ich betreue. Seit Jahren dienen sie nur noch Cloud-Zwecken, existieren wegen Altprozessen, Postfachberechtigungen oder Compliance-Vorgaben aber weiterhin on-premises. Auch bei automatisiert synchronisierten Gruppen (z. B. dynamischen Security Groups für SaaS-Apps) erleichtert der Wechsel die Arbeit spürbar. In Projekten stoße ich immer wieder auf diese Hürden:

• Drittanwendungen fragen die Gruppen noch per LDAP ab, oder Skripte greifen darauf zu.
• Alte Prozesse (HR, Onboarding) hängen an der AD-Verwaltung.
• Gruppennamen oder -typen (z. B. Mail-Enabled Security Groups) entsprechen nicht den Cloud-only-Standards.

Mit dem SOA-Switch lassen sich all diese Gruppen nach und nach in die Cloud holen. Dafür muss die Gruppe synchronisiert worden sein, klassisch mit Entra Connect Sync oder mit Cloud Sync. Soll sie nach dem Wechsel nur noch in der Cloud gepflegt werden, darf sie außerdem keine lokalen AD-Abhängigkeiten mehr haben.

Der SOA-Switch setzt aktuelle Sync-Werkzeuge und statische Gruppen voraus

Der Source-of-Authority-Switch für Gruppen ist seit 2025 in der Preview und setzt aktuelle Versionen von Entra Connect Sync oder Cloud Sync voraus. Welche Mindestversion Connect Sync braucht, steht in der aktuellen Ankündigung. Ein Blick in die offizielle Dokumentation lohnt sich hier immer. Bei Cloud Sync erreicht man das Feature grundsätzlich über die Portaloberfläche. Migrieren lassen sich nur „statische“ Gruppen, dynamische AD-Gruppen werden derzeit nicht unterstützt.

Wer eine Gruppe weiterhin auch lokal benötigt (z. B. für alte Anwendungen oder Backups), kann mit Entra Cloud Sync das Membership-Writeback-Feature nutzen. Dabei wird die Mitgliedschaft der nun cloudverwalteten Gruppe regelmäßig ins AD zurückgeschrieben. Verwaltet wird also in der Cloud, die lokale Gruppe bleibt für Legacy-Zwecke trotzdem erhalten. Damit das Writeback funktioniert, muss Cloud Sync entsprechend konfiguriert sein, und der Ziel-AD-Connector braucht die nötigen Rechte.

Ein Tipp aus der Praxis zur Vorbereitung:

Prüft vor dem SOA-Wechsel, ob noch Workflows, Automatisierungen oder Anwendungen die Gruppenmitgliedschaft direkt aus dem AD lesen. Solche Abhängigkeiten sind oft gut versteckt. Ein kurzer Blick in die AD-Logs oder ein Gespräch mit den Kollegen aus dem Application Management erspart euch böse Überraschungen.

Die lokale AD-Gruppe bleibt nach dem Wechsel technisch bestehen

In jedem Projekt fragt irgendwann jemand, was nach dem Wechsel mit der ursprünglichen Gruppe im lokalen AD geschieht. Sie bleibt technisch bestehen, wird aber nicht mehr mit der Cloud synchronisiert. Änderungen wie neue Mitglieder gelangen also nicht mehr nach Entra ID. Ist Membership Writeback aktiviert, überschreibt die Cloud-Änderung sogar die lokale Mitgliedschaft, damit beide Seiten konsistent bleiben. Wer die lokale Gruppe nicht mehr braucht, kann sie nach einer Validierungsphase löschen. Für Compliance- oder Recovery-Szenarien empfehle ich allerdings, den Umzug im AD nachvollziehbar zu dokumentieren, denn nicht jede Altanwendung bemerkt sofort, dass die Gruppe „umgezogen“ ist.

Den SOA-Status aller Gruppen prüft man derzeit nur im Entra-ID-Portal → Gruppen. Über den Filter „Quelle“ seht ihr, ob ein Objekt aus der Cloud oder aus dem AD stammt; nach dem Wechsel steht dort „Cloud“. Die Group ObjectId bleibt identisch, deshalb funktionieren Berechtigungszuweisungen weiter.

Das Diagramm zeigt den Weg einer Gruppe durch den SOA-Wechsel

Im folgenden Diagramm durchläuft eine AD-Gruppe den SOA-Wechsel, bei Bedarf einschließlich Cloud-Writeback:

flowchart TD
    ADGruppe["AD-Gruppe"] --> Sync["Synchronisation"]
    Sync --> EntraGruppe["Entra ID Gruppe (Quelle: AD)"]
    EntraGruppe --> SOASwitch["SOA-Wechsel"]
    SOASwitch --> CloudManaged["Entra ID Gruppe (Quelle: Cloud)"]
    CloudManaged -->|optional| Writeback["Membership Writeback (Cloud Sync)"]
    Writeback --> ADGruppe["AD-Gruppe (nur Mitgliedschaft)"]

Abbildung: Source-of-Authority-Wechsel für Gruppen und Writeback-Pfad

Für viele Umgebungen ist jetzt der richtige Zeitpunkt zum Umstellen

Aus meiner Sicht ist der Source-of-Authority-Switch für Gruppen in Entra ID ein sehr hilfreiches Werkzeug für alle, die ihre Gruppenlandschaft von Altlasten befreien und auf eine zukunftsfähige Cloud-Verwaltung umstellen wollen. Da keine Gruppe neu angelegt werden muss, spart man sich viel Migrationsaufwand und vermeidet Risiken bei der Berechtigungsvererbung. Wer noch hybride Anwendungen betreibt, bekommt mit Membership Writeback über Cloud Sync eine pragmatische Brücke. Es bleibt allerdings ein Preview-Feature, und laut aktueller Ankündigung können sich Verhalten und Funktionsumfang noch ändern. Behaltet deshalb die Dokumentation und das Message Center im Blick. Für viele meiner Kunden ist jetzt der richtige Zeitpunkt, den Source-of-Authority-Wechsel für Gruppen gezielt zu planen und damit den Weg zu einer echten Cloud-Identitätsverwaltung freizumachen.