M365 Entra ID | MemberOf-Regeln bis 3. November ersetzen

Microsoft beendet zum 3. November 2026 die seit vier Jahren laufende Public Preview des MemberOf-Regeloperators in Entra ID. Der Operator kommt nicht in die allgemeine Verfügbarkeit, er wird abgeschaltet. Betroffen sind dynamische Gruppen, dynamische Administrative Units und die Auto-Assignment-Policies im Entitlement Management.

Nach dem Stichtag verarbeitet Entra ID keine Regel mehr, die MemberOf nutzt. Die Regeln verschwinden nicht, sie frieren im letzten Stand ein. Das ist das eigentliche Risiko, weil keine Fehlermeldung kommt. Ein neuer Mitarbeiter in der Quellgruppe landet nicht mehr automatisch in der Zielgruppe und bekommt weder Zugriff noch Lizenz. Ein ausgeschiedener behält beides.

Conditional Access zielt dann auf veraltete Mitgliedschaften, und die gruppenbasierte Lizenzierung weist Lizenzen an Konten zu, die keine mehr brauchen. Microsofts Begründung: schon eine einzige MemberOf-Regel kann die dynamische Mitgliedschaftsverarbeitung im gesamten Tenant ausbremsen.

Ohne eine vollständige Liste der betroffenen Objekte arbeitest du blind. Fang mit den dynamischen Gruppen an und zieh dir die Treffer gleich als CSV, damit du eine Abarbeitungsliste hast.

Die dynamischen Administrative Units liegen in einem eigenen Objekttyp und fallen bei einer reinen Gruppenprüfung durch. Deshalb prüfst du sie getrennt.

Bleibt das Entitlement Management. Die Auto-Assignment-Policies der Access Packages können ebenfalls MemberOf nutzen. Die siehst du im Portal unter Identity Governance, Entitlement Management, Access Packages, bei der jeweiligen Policy. Für eine saubere Dokumentation gehst du jedes Access Package durch und notierst, welche Auto-Assignment-Regel dahinter steht.

Für jede Regel gibt es zwei Wege. Wenn sich die Mitgliedschaft auch über ein Attribut ausdrücken lässt, ersetzt du MemberOf durch eine attributbasierte Regel. Statt auf die Mitgliedschaft in einer Quellgruppe zu verweisen, baust du die Regel auf department, jobTitle, eine Kostenstelle oder eine andere Abteilungskennung. Das ist der bessere Weg, weil die Gruppe dynamisch bleibt.

Eine attributbasierte Regel sieht dann etwa so aus:

Wenn es kein sauberes Attribut gibt, über das sich die Gruppe beschreiben lässt, bleibt nur der Wechsel auf zugewiesene Mitgliedschaft. Du überführst die aktuelle Mitgliederliste in eine statische Gruppe und pflegst sie künftig über einen anderen Mechanismus, etwa einen Provisioning-Prozess oder ein Lifecycle-Workflow. Plane diesen Ersatz bewusst ein, sonst wächst die Gruppe nicht mehr mit.

Die Mitgliedschaftsregel einer Gruppe änderst du im Portal oder per Graph. Achte darauf, dass du nach der Umstellung die Verarbeitung abwartest und das Ergebnis kontrollierst, bevor du die nächste Gruppe anfasst.

Nach jeder Änderung prüfst du drei Dinge: die Mitgliedschaft der Gruppe, den administrativen Scope einer betroffenen AU und die Lizenzzuweisung, falls an der Gruppe eine Lizenz hängt. Gerade die Lizenzzuweisung fällt sonst erst auf, wenn ein neuer Nutzer ohne Lizenz dasteht.

Die Frist ist hart und es gibt keine automatische Migration. Das Risiko liegt nicht im Umstellen selbst, sondern darin, eine betroffene Gruppe zu übersehen. Eine einzige vergessene MemberOf-Gruppe, an der Conditional Access oder eine Lizenz hängt, reicht für einen stillen Zugriffs- oder Lizenzfehler Wochen nach dem Stichtag.

Deshalb steht die Bestandsaufnahme am Anfang, und deshalb gehört die CSV-Liste abgehakt, nicht überflogen. Wer dynamische Gruppen für Lizenzen oder Conditional Access nutzt, prüft den Bestand jetzt, nicht Ende Oktober.