Le 3 novembre 2026, l’opérateur memberOf cesse de fonctionner dans les groupes à appartenance dynamique de Microsoft Entra ID. Pas de suppression brutale, pas d’erreur qui saute aux yeux : les groupes concernés arrêtent simplement de se mettre à jour et restent figés dans leur dernier état connu. C’est précisément ce genre de panne silencieuse qui fait le plus de dégâts — personne ne la remarque avant que quelqu’un perde un accès qu’il devrait avoir, ou en garde un qu’il ne devrait plus avoir.
Microsoft a envoyé un rappel final le 5 octobre 2026 (MC1488834), trois mois après l’annonce initiale du 5 août. Si tu n’as pas suivi ce fil de la Message Center, voici ce qu’il faut vérifier avant la date butoir.
Ce qui casse exactement
memberOf est un opérateur en préversion qui permet à un groupe dynamique d’inclure les membres d’autres groupes — pratique pour agréger plusieurs groupes de sécurité existants sans tout reconstruire à la main. Trois types d’objets l’utilisent, et les trois sont concernés après le 3 novembre :
- Les groupes à appartenance dynamique dont la règle contient
memberOf: ils arrêtent de traiter les changements d’appartenance. - Les unités d’administration dynamiques basées sur cette même règle : leur périmètre d’administration se gèle aussi.
- Les politiques d’auto-attribution de l’entitlement management qui s’appuient sur
memberOf: plus aucune nouvelle attribution de package d’accès ne sera traitée via cette règle.
Les effets en cascade sont le vrai problème : accès Teams et SharePoint qui ne reflètent plus la réalité, ciblage Conditional Access obsolète, licences attribuées par groupe qui ne suivent plus les arrivées et départs. Microsoft est explicite sur la cause : l’opérateur memberOf peut ralentir le traitement des appartenances dynamiques pour tout le tenant, pas seulement pour le groupe qui l’utilise — même un seul groupe mal configuré peut dégrader les temps de traitement de tous les autres. D’où la retraite plutôt qu’un simple correctif de performance.
Comment savoir si tu es concerné
La syntaxe à chercher ressemble à ceci :
user.memberof -any (group.objectId -in ['<id-du-groupe-source>'])Pour la repérer sur tous tes groupes dynamiques via Microsoft Graph PowerShell :
Connect-MgGraph -Scopes "Group.Read.All"
Get-MgGroup -All -Filter "groupTypes/any(c:c eq 'DynamicMembership')" `
-Property Id,DisplayName,MembershipRule |
Where-Object { $_.MembershipRule -match '(?i)memberof' } |
Select-Object Id, DisplayName, MembershipRulePour les unités d’administration et les politiques d’auto-attribution, il n’existe pas de filtre équivalent côté portail — passe aussi par Graph PowerShell (Get-MgDirectoryAdministrativeUnit et Get-MgEntitlementManagementAssignmentPolicy) et grep la propriété membershipRule ou les règles de la policy de la même façon.
Que mettre à la place
Deux chemins, selon ce que tu avais réellement besoin de faire :
- Remplacer par un opérateur supporté — si ton besoin se ramène à un attribut (département, pays, type d’appareil…), les opérateurs
-eq,-in,-startsWithcouvrent la grande majorité des cas, et sont documentés dans le guide des règles de groupe dynamique. - Basculer en appartenance assignée — si le besoin réel était juste d’agréger quelques groupes de façon ponctuelle, un groupe assigné avec une synchro manuelle ou scriptée (un petit script planifié qui recopie les membres) est souvent plus simple à maintenir qu’une règle dynamique fragile, surtout vu les limites déjà en place sur
memberOf(50 groupes membres max, pas de chaînage entre deux groupesmemberOf, pas de combinaison avec un autre opérateur).
Dans les deux cas, valide l’appartenance résultante avant de considérer la migration terminée — un comptage avant/après suffit dans la plupart des cas, sur une politique d’auto-attribution, va vérifier aussi les attributions de packages d’accès.
Le piège si tu ne fais rien
Ce n’est pas un échec propre : le groupe continue d’exister, continue d’avoir des membres, et continue d’être utilisé par Conditional Access ou par une licence groupée. Il se contente de ne plus évoluer. Un nouvel employé ajouté au groupe source trois semaines après le 3 novembre n’apparaîtra jamais dans le groupe dynamique qui en dépendait — sans message d’erreur nulle part. C’est le genre d’écart qui ressort en audit six mois plus tard, pas le jour où ça casse.
FAQ
Est-ce que je peux encore créer un nouveau groupe memberOf avant le 3 novembre ?
Techniquement oui, mais ça n’a aucun sens : il arrêtera de se mettre à jour dès l’échéance. Autant partir directement sur un opérateur supporté ou une appartenance assignée.
Microsoft va-t-il proposer une alternative pour le cas d’usage memberOf ?
Le message officiel indique que Microsoft continue à travailler sur une solution alternative avec un meilleur niveau de fiabilité et d’échelle, sans date annoncée. En attendant, il n’y a pas de remplacement direct en préversion à adopter.
Est-ce que ça touche aussi les groupes dynamiques basés sur les appareils ?
Oui — la syntaxe device.memberof suit exactement la même règle et la même échéance que la version user.memberof.
Passe à l’action
Lance le script PowerShell ci-dessus cette semaine, pas la semaine du 2 novembre. Si tu as déjà dû gérer une échéance Entra qui est tombée sans prévenir — on en a parlé avec le couperet Entra Connect Sync du 30 septembre — tu sais que le vrai risque n’est pas la date elle-même, c’est de la découvrir après coup.
