M365 EntraID | schaltet den memberOf-Operator ab

Am 3. November 2026 hört Entra ID auf, Mitgliedschaftsregeln mit dem Operator memberOf zu verarbeiten. Microsoft löscht die betroffenen Objekte nicht. Sie bleiben stehen, mit exakt dem Mitgliederstand, den sie an diesem Tag hatten.

Genau das macht die Abkündigung unangenehm: Es gibt keine Fehlermeldung, keinen roten Status im Portal, keinen Eintrag im Monitoring. Die Gruppe sieht weiter gesund aus, während neue Mitarbeiter nicht mehr aufgenommen und ausgeschiedene nicht mehr entfernt werden.

Die Ankündigung steht in MC1448379 vom 5. August 2026, eingestuft als Major change mit Admin- und User-Impact. Betroffen sind dynamische Mitgliedschaftsgruppen, dynamische administrative Einheiten und Auto-Assignment-Policies im Entitlement Management. Die Public Preview des Operators endet, ein GA-Termin kommt nicht mehr.

Eine dynamische Gruppe füllt sich normalerweise über Benutzerattribute, etwa user.department -eq "Vertrieb". Der memberOf-Operator hat diese Logik umgedreht: Statt Attribute auszuwerten, hat Entra ID die direkten Mitglieder anderer Gruppen eingesammelt und in die Zielgruppe geschrieben. Die Regel dazu sieht so aus:

Damit ließ sich das nachbauen, was Entra ID bis heute nicht kann: verschachtelte Gruppen, die von allen Workloads sauber aufgelöst werden. Anwendungen, die keine Nested Groups verstehen, Power-Platform-Umgebungen, gruppenbasierte Lizenzierung und Zugriffspakete bekamen so eine flache Gruppe mit allen Mitgliedern der Quellgruppen. Der Operator war nie mehr als eine Preview, aber er löste ein reales Problem, und deshalb ist er in vielen Tenants produktiv gelandet.

Wichtig für die Migrationsplanung: Übernommen wurden immer nur die direkten Mitglieder der Quellgruppe. Verschachtelungen innerhalb der Quellgruppe blieben außen vor, und eine memberOf-Gruppe durfte nicht selbst wieder als Quelle dienen.

Die Objekte bleiben erhalten, die Hintergrundverarbeitung endet. Mitgliedschafts- und Zuweisungsdaten verharren im letzten berechneten Zustand. Microsoft benennt in MC1448379 fünf Wirkungsbereiche, und jeder davon trifft den Betrieb an einer anderen Stelle.

Bei Microsoft-365-Gruppen laufen Teams- und SharePoint-Berechtigungen aus dem Ruder, weil neue Mitglieder keinen Zugriff bekommen und entfernte Mitglieder ihren Zugriff behalten. Conditional-Access-Richtlinien, die auf eine solche Gruppe zielen, greifen weiterhin auf einen eingefrorenen Personenkreis, womit ein neuer Mitarbeiter unter Umständen ohne die vorgesehene MFA-Anforderung arbeitet.

Die gruppenbasierte Lizenzierung verteilt keine Lizenzen mehr an Neuzugänge und zieht keine mehr von Abgängen ein, was direkt in Über- und Unterlizenzierung führt. Auto-Assignment-Policies im Entitlement Management vergeben und entziehen keine Zugriffspakete mehr. Bei dynamischen administrativen Einheiten veraltet neben der Mitgliederliste auch der administrative Geltungsbereich, in dem delegierte Rollen wirken.

Der letzte Punkt ist der stillste und der gefährlichste. Wenn der Scope einer administrativen Einheit nicht mehr nachgeführt wird, behalten delegierte Administratoren Rechte auf Objekte, die längst woanders hingehören.

Die Begründung ist ungewöhnlich offen: Eine einzige memberOf-Regel kann die Verarbeitung dynamischer Mitgliedschaften im gesamten Tenant ausbremsen, auch bei Gruppen, die den Operator gar nicht verwenden. Die Auswertung skaliert also nicht, und die Preview-Limits lesen sich entsprechend:

Dazu kommt ein Verhalten, das in der Praxis regelmäßig für falsche Mitgliederlisten sorgt: Wird eine Quellgruppe gelöscht oder verliert sie Mitglieder, aktualisiert sich die memberOf-Gruppe nicht automatisch. Die betroffenen Benutzer und Geräte bleiben so lange drin, bis jemand die Regel anfasst. Tony Redmond hat in seiner Analyse dokumentiert, dass eine Regel mit drei referenzierten Gruppen weiterlief, obwohl zwei davon nicht mehr existierten, ohne jeden Hinweis im Portal.

Microsoft stellt eine skalierbare Alternative in Aussicht, nennt aber weder Funktionsumfang noch Termin. Für die Planung heißt das: Du migrierst auf das, was heute existiert, nicht auf eine Ankündigung.

Der erste Schritt ist eine belastbare Liste. Für dynamische Gruppen holst du alle Objekte mit dynamischer Mitgliedschaft und filterst die Regel clientseitig:

MC1448379 schlägt eine Variante mit startsWith(membershipRule,'user.memberOf') vor. Die ist schneller, findet aber nur Regeln, die mit dem Operator beginnen. Sobald jemand die Regel in Klammern gesetzt oder mit einem Leerzeichen eingerückt hat, fällt sie durch den Filter. Die clientseitige Prüfung mit -match kostet ein paar Sekunden mehr und liefert dafür alle Treffer.

Für dynamische administrative Einheiten gilt dieselbe Logik:

Die Auto-Assignment-Policies im Entitlement Management sind der seltenste Fall und der einzige, den du über einen direkten Graph-Aufruf prüfen musst. Die Regel steht dort nicht im Gruppenobjekt, sondern in den erlaubten Zielen der Richtlinie:

Wer lieber im Portal arbeitet, exportiert die Gruppen aus dem Entra Admin Center und filtert die Spalte mit der Mitgliedschaftsregel in Excel. Für eine einmalige Bestandsaufnahme reicht das, für die Nachkontrolle nach dem Umbau ist das Skript die bessere Wahl.

Einen Operator, der eins zu eins dasselbe leistet, gibt es nicht. Was bleibt, sind vier Wege, und welcher passt, hängt daran, warum die Gruppe überhaupt gebaut wurde.

Rund drei Monate klingen nach viel, sind aber knapp, wenn Attributpflege dazukommt. Zieh die Inventur sofort, bevor du irgendetwas umbaust, und friere den Stand als Referenz ein: Gruppenname, Objekt-ID, Regel, aktuelle Mitgliederzahl. Diese Liste ist später dein Soll-Ist-Vergleich.

Danach sortierst du nach Wirkung. Gruppen, an denen Lizenzen oder Conditional Access hängen, kommen zuerst, weil dort ein eingefrorener Stand Geld kostet oder ein Sicherheitsloch aufreißt. Reine Verteilerlisten haben Zeit. Den Umbau testest du in einem Testtenant oder an einer Kopie der Gruppe, prüfst nach der Umstellung die Mitgliederdifferenz gegen die Referenzliste und dokumentierst jede Regel, die du ersetzt hast.

Plane einen Kontrolltermin nach dem 3. November ein. Wenn eine Regel übersehen wurde, meldet sich niemand. Der einzige Indikator ist eine Mitgliederzahl, die sich nicht mehr bewegt.

Die Abkündigung trifft eine Funktion, die formal nie produktionsreif war und trotzdem überall im Einsatz ist. Microsoft hat den Operator im Portal anklickbar gemacht, per Graph und PowerShell unterstützt und in der Dokumentation gleichzeitig auf Testumgebungen beschränkt. Diese Lücke zwischen Verfügbarkeit und Freigabe haben viele Tenants zu ihren Gunsten interpretiert, weil der Operator eine echte Lücke im Gruppenmodell geschlossen hat. Die Rechnung kommt jetzt.

Technisch ist die Begründung nachvollziehbar. Ein Verfahren, bei dem eine einzelne Regel die Verarbeitung aller dynamischen Gruppen eines Tenants verlangsamt, kann Microsoft nicht in die allgemeine Verfügbarkeit heben. Ärgerlich ist die Ersatzlage: Es gibt keinen Operator, der verschachtelte Gruppenlogik übernimmt, und der angekündigte Nachfolger hat weder Namen noch Termin. Wer memberOf für Anwendungen ohne Nested-Group-Unterstützung eingesetzt hat, steht vor einem Attributprojekt oder vor Eigenbau-Automatisierung.

Das Betriebsrisiko liegt weniger im Umbau als im Nichtstun. Eine eingefrorene Gruppe verhält sich unauffällig, sie wirft keinen Fehler und fällt im Tagesgeschäft erst auf, wenn ein Neuzugang keinen Teams-Zugriff bekommt oder ein Ausgeschiedener noch eine Lizenz hält. Für Audits nach ISO 27001 oder für ein internes Berechtigungskonzept ist genau das der unangenehme Fall: Der Prozess existiert auf dem Papier, greift aber nicht mehr.

Zieh daraus zwei Konsequenzen. Erstens: Jede Preview-Funktion in deinem Tenant braucht einen Owner und ein Wiedervorlagedatum, sonst wird aus einem Test unbemerkt Produktion. Zweitens: Baue nach der Migration eine schlichte Kontrolle, die Mitgliederzahlen kritischer Gruppen mitschreibt. Ein Report, der zeigt, dass sich seit Wochen nichts bewegt, ist die einzige Warnung, die du bei dieser Art von Ausfall bekommst.