Entra ID MemberOf-Regeloperator für dynamische Gruppen: Was dahintersteckt
Die Abschaffung von Microsofts memberOf-Regeloperator für dynamische Gruppen in Entra ID erfolgt am 3. November 2026 — nach diesem Datum aktualisiert sich jede Konfiguration, die ihn noch verwendet, nicht mehr. memberOf ist ein Regeloperator für dynamische Mitgliedschaft, veröffentlicht als öffentliche Preview, mit dem eine dynamische Gruppe, eine dynamische Verwaltungseinheit oder eine Auto-Zuweisungsrichtlinie im Entitlement Management sich selbst anhand der Mitglieder anderer Gruppen befüllen kann. Statt Regeln pro Attribut zu schreiben (Abteilung, Jobtitel, Erweiterungsattribute), konnte ein Administrator eine dynamische Gruppe auf bis zu 50 „Quell"-Sicherheitsgruppen, Microsoft-365-Gruppen oder lokal synchronisierte Gruppen verweisen lassen und deren direkte Mitglieder automatisch übernehmen lassen.
Am 5. August 2026 veröffentlichte Microsoft den Message-Center-Beitrag MC1448379, der das Ende der memberOf-Preview ankündigt. Laut der offiziellen Microsoft-Learn-Dokumentation aktualisiert sich nach dem 3. November 2026 jede dynamische Mitgliedschaftsgruppe, dynamische Verwaltungseinheit oder Auto-Zuweisungsrichtlinie im Entitlement Management, die noch memberOf verwendet, nicht mehr und erstarrt im letzten bekannten Zustand. Microsoft begründet dies mit einer Skalierungs- und Zuverlässigkeitseinschränkung, nicht mit einem Sicherheitsfix — doch die operativen Folgen treffen Identity-Teams genauso wie ein Bug: lautlos und mit Frist. Es ist dasselbe Muster „an der Oberfläche ruhig, darunter kaputt", das wir schon behandelt haben, als ein abgelaufenes SAML-Signaturzertifikat von Entra die föderierte Anmeldung mandantenweit lahmlegte: Der Auslöser ist eine Änderung auf Microsoft-Seite, aber der Wirkungsradius hängt vollständig davon ab, ob die eigene Konfiguration nachverfolgt wurde.
⚠️ Warnung: Dies ist keine langsame Abschaffung mit langem Nachlauf. Nach dem 3. November 2026 hören betroffene Gruppen, Verwaltungseinheiten und Access Packages vollständig auf, die Mitgliedschaft abzugleichen — sie werfen keinen Fehler, sie veralten einfach.
Wie es funktioniert — und warum Microsoft es abschafft
Eine memberOf-Regel wird in der erweiterten Regelsyntax für dynamische Gruppen in Entra geschrieben (sie wird im Regel-Builder-UI nicht unterstützt — nur im rohen Regeleditor):
user.memberof -any (group.objectId -in ['<sourceGroupObjectId>'])
oder für geräte-basierte dynamische Gruppen:
device.memberof -any (group.objectId -in ['<sourceGroupObjectId>'])
Mehrere Quellgruppen können in derselben Regel aufgeführt werden (-in ['<groupId1>', '<groupId2>']), und die resultierende dynamische Gruppe kann für App-Zuweisung, Conditional-Access-Ziele oder gruppenbasierte Lizenzierung verwendet werden — überall dort, wo eine normale Gruppe funktioniert.
Gemäß Microsofts eigenen Preview-Einschränkungen war das Feature von Anfang an eng begrenzt: eine mandantenweite Obergrenze von 500 dynamischen Gruppen mit memberOf (angerechnet auf das Gesamtkontingent von 15.000 dynamischen Gruppen), eine Grenze von 50 Quellgruppen pro Regel, nur direkte Mitglieder (keine transitive Verschachtelung — Mitglieder einer Gruppe, die in eine Quellgruppe verschachtelt ist, werden nicht übernommen), keine Verkettung einer memberOf-dynamischen Gruppe mit einer weiteren, und keine Kombination von memberOf mit einer anderen Regelklausel. Microsoft Entra ID Premium P1 oder P2 sowie mindestens die Rolle User Administrator waren allein für die Konfiguration erforderlich.
Der Grund für die Abschaffung ist laut Microsofts Migrationsleitfaden die Skalierung: Die Verwendung von memberOf „kann die Verarbeitung dynamischer Mitgliedschaft mandantenweit beeinträchtigen, selbst wenn nur eine memberOf-Regel im Mandanten existiert." Eine einzige Regel konnte die Auswertung nicht verwandter dynamischer Gruppen mandantenweit verlangsamen — weshalb Microsoft ausdrücklich sagt, der Operator sei „nicht für den Produktionseinsatz empfohlen", obwohl reale Mandanten ihn während der Preview produktiv eingesetzt haben.
Microsoft erklärt, man „entwickle weiterhin eine alternative Lösung" mit angemessener Skalierbarkeit, hat sich aber nicht auf ein Ersatzfeature oder einen Termin festgelegt — die aktuelle Migrationsanleitung verweist auf bestehende Regeloperatoren oder zugewiesene (statische) Mitgliedschaft, nicht auf einen direkten Nachfolger.
Erkennung: Jede memberOf-Regel finden, bevor sie einfriert
Das Risiko liegt nicht in der Abschaffung selbst — sondern darin, nicht zu wissen, welche dynamischen Gruppen, Verwaltungseinheiten und Access Packages heute lautlos von memberOf abhängen. Da der Operator nur in der Preview existierte und nie im Regel-Builder-UI angezeigt wurde, können betroffene Objekte bei einer routinemäßigen Konsolenprüfung leicht übersehen werden; der zuverlässige Weg, sie zu finden, ist eine gezielte Microsoft-Graph-Abfrage. Wer noch keinen strukturierten Durchlauf über die Entra-ID-Konfiguration fährt, findet im Leitfaden zur Prüfung der Microsoft-Entra-ID-Sicherheit den umfassenderen Prüfprozess, in den dieser Erkennungsschritt einzuordnen ist.
| Was zu prüfen ist | Wie | Quelle |
|---|---|---|
Dynamische Gruppen mit memberOf | Microsoft Graph groups, gefiltert nach groupTypes = DynamicMembership und membershipRule beginnend mit user.memberOf / device.memberOf | Microsoft Graph PowerShell |
Dynamische Verwaltungseinheiten mit memberOf | Microsoft Graph administrativeUnits, gefiltert nach membershipType = Dynamic und derselben membershipRule-Präfixprüfung | Microsoft Graph PowerShell |
| Auto-Zuweisungsrichtlinien im Entitlement Management | identityGovernance/entitlementManagement/assignmentPolicies, gefiltert nach Richtlinien mit konfiguriertem automaticRequestSettings, danach geprüft auf memberOf-basierte Kriterien | Microsoft Graph API |
Beispiel Graph PowerShell, angepasst nach der von office365itpros.com zusammengefassten Migrationsanleitung:
Connect-MgGraph -Scopes GroupMember.Read.All
[array]$Groups = Get-MgGroup -Filter "groupTypes/any(c:c eq 'dynamicmembership') and (startsWith(membershipRule,'user.memberOf') or startsWith(membershipRule,'device.memberOf'))" -All
Connect-MgGraph -Scopes AdministrativeUnit.Read.All
[array]$DynamicAdminUnits = Get-MgDirectoryAdministrativeUnit -Filter "membershipType eq 'Dynamic' and (startsWith(membershipRule,'user.memberOf') or startsWith(membershipRule,'device.memberOf'))" -All
$Uri = "https://graph.microsoft.com/v1.0/identityGovernance/entitlementManagement/assignmentPolicies"
$Data = Invoke-MgGraphRequest -Uri $Uri -Method Get -OutputType PsObject | Select-Object -ExpandProperty Value
$Data | Where-Object {$_.automaticRequestSettings}
Die letzte Abfrage liefert jede Auto-Zuweisungsrichtlinie zurück; jedes Ergebnis muss anschließend manuell auf memberOf-basierte Logik in den automaticRequestSettings-Kriterien geprüft werden, da die API keinen direkten Filter dafür bietet.
ℹ️ Hinweis: Nicht bei dynamischen Gruppen aufhören. Die zwei Objekte, die Teams am häufigsten vergessen, sind dynamische Verwaltungseinheiten (die delegierte Admin-Berechtigungen abgrenzen) und Auto-Zuweisungsrichtlinien im Entitlement Management (die die Mitgliedschaft in Access Packages steuern) — beide erstarren am selben Datum lautlos.
Behebung: Migration vor dem 3. November 2026
Microsofts eigener Migrationsleitfaden gliedert dies in drei Stränge:
- Dynamische Mitgliedschaftsgruppen — Die oben identifizierten dynamischen Gruppen exportieren,
memberOfdurch einen unterstützten Regeloperator ersetzen (attributbasierte Regeln gegen Benutzer- oder Geräteeigenschaften), wo sich dieselbe Population so abbilden lässt, oder die Gruppe auf zugewiesene (statische) Mitgliedschaft umstellen. Vor dem Entfernen der alten Regel prüfen, ob die resultierende Gruppenmitgliedschaft den Erwartungen entspricht. - Dynamische Verwaltungseinheiten — Gleiches Muster: die
memberOf-basierte Regel durch unterstützte Logik ersetzen oder auf zugewiesene Mitgliedschaft umstellen. Da Verwaltungseinheiten delegierte administrative Berechtigungen abgrenzen, sowohl die resultierende Mitgliedschaft als auch den administrativen Geltungsbereich prüfen — eine erweiterte Verwaltungseinheit ist ein Privilegienausweitungsrisiko derselben Kategorie wie die dauerhafte Global-Admin-Exposition, die wir in Azure Privileged Access behandeln, nicht nur eine veraltete Gruppe. - Auto-Zuweisungsrichtlinien im Entitlement Management —
memberOf-basierte Kriterien durch unterstützte attributbasierte Operatoren ersetzen, wo ein Äquivalent existiert. Wo das nicht der Fall ist, macht Microsofts Leitfaden ausdrücklich klar, dass Teams vor der Frist eine alternative Zuweisungsmethode planen müssen — es gibt keinen garantierten gleichwertigen Ersatz.
💡 Quick Win: Wenn eine memberOf-dynamische Gruppe immer nur eine kleine, sich kaum ändernde Population aufgelöst hat, ist die direkte Umstellung auf eine zugewiesene (statische) Gruppe meist schneller und risikoärmer, als eine gleichwertige attributbasierte Regel nachzubauen.
Für jedes bearbeitete Objekt die nachgelagerten Effekte vor der Frist prüfen, nicht danach: gruppenbasierte Lizenzzuweisung, Conditional-Access-Ziele und Teams-/SharePoint-Zugriff über Microsoft-365-Gruppen lesen alle aus derselben Mitgliedschaft, die am 3. November 2026 einfriert. Ein nicht oder zu stark lizenzierter Benutzer, oder eine Conditional-Access-Richtlinie, die lautlos ein Team ausschließt, das nach dem Einfrieren gewachsen ist, ist genau die Art von Lücke, die Wochen später bei einer Zugriffsprüfung auftaucht — nicht am ersten Tag.
Wie EtcSec das erkennt
EtcSec markiert dynamische Gruppen mit zu breiten oder risikoreichen Mitgliedschaftsregeln über die Prüfung AZ_GROUP_DYNAMIC_RULE_BROAD, die dynamische Mitgliedschaftskonfigurationen — einschließlich memberOf-basierter Regeln — sichtbar macht, die geprüft werden sollten, bevor sie aus dem Blick geraten oder, wie hier, komplett aufhören, sich zu aktualisieren. EtcSec prüft zudem die Entra-ID-P1/P2-Lizenzabdeckung (AZ_NO_P2_LICENSE), da memberOf und die meisten seiner unterstützten Nachfolger eine Premium-Lizenzierung zur Konfiguration und Pflege benötigen.
ℹ️ Hinweis: EtcSec prüft diese Schwachstelle automatisch bei jedem Azure-Audit. Führen Sie ein kostenloses Audit durch, um zu verifizieren, dass Ihre Umgebung nicht von einem Regeloperator abhängt, der am 3. November 2026 aufhört, sich zu aktualisieren.
Entdecken Sie die Identity-Security-Seiten zu diesem Thema
