Retrait de l'opérateur de règle memberOf pour les groupes dynamiques Entra ID : ce qui casse le 3 novembre

Retrait de l'opérateur de règle memberOf pour les groupes dynamiques Entra ID : ce que c'est

Le retrait de l'opérateur de règle memberOf pour les groupes dynamiques Entra ID par Microsoft prend effet le 3 novembre 2026 — après cette date, toute configuration qui l'utilise encore cesse de se mettre à jour. memberOf est un opérateur de règle d'appartenance dynamique, livré en préversion publique, qui permet à un groupe dynamique, une unité d'administration dynamique ou une politique d'attribution automatique de gestion des droits de se peupler à partir des membres d'autres groupes. Plutôt que d'écrire des règles par attribut (service, intitulé de poste, attributs d'extension), un administrateur pouvait faire pointer un groupe dynamique vers jusqu'à 50 groupes de sécurité, groupes Microsoft 365 ou groupes synchronisés on-premises « source », et faire remonter automatiquement leurs membres directs.

Le 5 août 2026, Microsoft a publié l'article MC1448379 dans le Message Center, annonçant la fin de la préversion memberOf. Selon la documentation officielle Microsoft Learn, après le 3 novembre 2026, tout groupe à appartenance dynamique, toute unité d'administration dynamique ou toute politique d'attribution automatique de gestion des droits qui utilise encore memberOf cesse de se mettre à jour et se fige dans son dernier état connu. Microsoft présente cela comme une limitation de scalabilité et de fiabilité, pas comme un correctif de sécurité — mais l'impact opérationnel touche les équipes identité de la même façon qu'un bug le ferait : silencieusement, avec une échéance. C'est le même schéma « calme en surface, cassé en dessous » que celui que nous avions couvert lorsqu'un certificat de signature SAML Entra expiré avait cassé l'authentification fédérée sur tout le tenant : le déclencheur vient de Microsoft, mais le rayon d'impact dépend entièrement de si vous avez suivi votre propre configuration.

Fonctionnement — et pourquoi Microsoft le retire

Une règle memberOf s'écrit dans la syntaxe de règle avancée des groupes dynamiques Entra (elle n'est pas prise en charge dans l'interface de création de règle — seulement dans l'éditeur de règle brute) :

user.memberof -any (group.objectId -in ['<sourceGroupObjectId>'])

ou pour les groupes dynamiques basés sur les appareils :

device.memberof -any (group.objectId -in ['<sourceGroupObjectId>'])

Plusieurs groupes source peuvent être listés dans la même règle (-in ['<groupId1>', '<groupId2>']), et le groupe dynamique résultant peut être utilisé pour l'attribution d'applications, le ciblage Accès conditionnel, ou l'attribution de licences par groupe — partout où un groupe classique fonctionne.

Selon les propres limitations de préversion de Microsoft, la fonctionnalité était toujours strictement cadrée : un plafond de 500 groupes dynamiques utilisant memberOf par tenant (comptabilisé dans le quota global de 15 000 groupes dynamiques), une limite de 50 groupes source par règle, membres directs uniquement (pas d'imbrication transitive — les membres d'un groupe imbriqué dans un groupe source ne sont pas remontés), pas de chaînage d'un groupe dynamique memberOf dans un autre, et pas de combinaison de memberOf avec une autre clause de règle. Une licence Microsoft Entra ID Premium P1 ou P2 et au minimum le rôle Administrateur des utilisateurs étaient nécessaires pour simplement la configurer.

La raison du retrait, selon les indications de migration de Microsoft, est liée à la scalabilité : utiliser memberOf « peut affecter le traitement de l'appartenance dynamique dans tout un tenant même avec une seule règle memberOf ». Une seule règle pouvait ralentir l'évaluation des groupes dynamiques sans rapport, à l'échelle du tenant — ce qui explique pourquoi Microsoft indique explicitement que l'opérateur « n'est pas recommandé en production », alors même que de vrais tenants l'avaient adopté en production pendant la préversion.

Microsoft indique « continuer à développer une solution alternative » avec une scalabilité adéquate, mais ne s'est engagé sur aucune fonctionnalité de remplacement ni date précise — les indications de migration actuelles pointent vers les opérateurs de règle existants ou l'appartenance assignée (statique), pas vers un remplacement direct.

Détection : trouver chaque règle memberOf avant qu'elle ne se fige

Le risque n'est pas le retrait en lui-même — c'est de ne pas savoir quels groupes dynamiques, unités d'administration et packages d'accès dépendent silencieusement de memberOf aujourd'hui. Comme l'opérateur était réservé à la préversion et jamais exposé dans l'interface de création de règle, les objets concernés peuvent facilement passer inaperçus lors d'une revue de console classique ; la façon fiable de les trouver est une requête Microsoft Graph ciblée. Si vous n'effectuez pas déjà une revue structurée de la configuration Entra ID, notre guide d'audit de la sécurité Microsoft Entra ID couvre le processus de revue plus large dans lequel s'inscrit cette étape de détection.

Exemple PowerShell Graph, adapté des indications de migration résumées par office365itpros.com :

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}

La dernière requête renvoie chaque politique d'attribution automatique ; chaque résultat nécessite ensuite une vérification manuelle de ses critères automaticRequestSettings pour une logique basée sur memberOf, car l'API n'expose pas de filtre direct pour cela.

Remédiation : migrer avant le 3 novembre 2026

Les indications de migration de Microsoft se déclinent en trois volets :

1. Groupes à appartenance dynamique — Exportez les groupes dynamiques identifiés ci-dessus, remplacez memberOf par un opérateur de règle pris en charge (règles basées sur les attributs de l'utilisateur ou de l'appareil) lorsque la même population peut être exprimée ainsi, ou convertissez le groupe en appartenance assignée (statique). Validez que l'appartenance du groupe résultant correspond aux attentes avant de supprimer l'ancienne règle.
2. Unités d'administration dynamiques — Même schéma : remplacez la règle basée sur memberOf par une logique prise en charge, ou convertissez en appartenance assignée. Comme les unités d'administration cadrent les permissions administratives déléguées, validez à la fois l'appartenance résultante et le périmètre administratif — une unité d'administration élargie est un risque d'élévation de privilèges de la même famille que l'exposition d'administrateurs globaux permanents que nous couvrons dans Accès à privilèges Azure, pas juste un groupe obsolète.
3. Politiques d'attribution automatique de gestion des droits — Remplacez les critères basés sur memberOf par des opérateurs basés sur les attributs pris en charge lorsqu'un équivalent existe. Quand ce n'est pas le cas, les indications de Microsoft sont explicites : les équipes doivent prévoir une méthode d'attribution alternative avant l'échéance — il n'y a pas de remplacement équivalent garanti.

Pour chaque objet que vous touchez, validez les effets en aval avant l'échéance, pas après : l'attribution de licence par groupe, le ciblage de l'Accès conditionnel, et l'accès Teams/SharePoint via les groupes Microsoft 365 lisent tous la même appartenance qui se fige le 3 novembre 2026. Un utilisateur non licencié ou sur-licencié, ou une politique d'Accès conditionnel excluant silencieusement une équipe qui s'est agrandie après le gel, est le genre d'écart qui remonte des semaines plus tard lors d'une revue d'accès — pas le premier jour.

Comment EtcSec détecte cela

EtcSec signale les groupes dynamiques avec des règles d'appartenance trop larges ou à risque via le contrôle AZ_GROUP_DYNAMIC_RULE_BROAD, qui fait remonter les configurations d'appartenance dynamique — y compris les règles basées sur memberOf — à examiner avant qu'elles ne dérivent hors périmètre ou, comme ici, cessent complètement de se mettre à jour. EtcSec vérifie également la couverture de licence Entra ID P1/P2 (AZ_NO_P2_LICENSE), car memberOf et la plupart de ses successeurs pris en charge nécessitent une licence Premium pour être configurés et maintenus.