Groupes dynamiques Entra ID : retrait de memberOf

Introduction

Microsoft prépare un changement structurant sur les groupes dynamiques de Microsoft Entra ID : le retrait de l'opérateur memberOf dans les règles d'appartenance, annoncé pour novembre. Si votre tenant utilise cette syntaxe pour construire des groupes imbriqués, des attributions Conditional Access ou des unités d'administration, il est temps de vérifier votre exposition avant que la règle ne cesse de fonctionner.

Cet article revient sur le fonctionnement des groupes dynamiques (utilisateur et appareil), explique pourquoi Microsoft retire cette fonctionnalité restée en préversion pendant des années, et donne les commandes PowerShell pour auditer et corriger vos règles avant l'échéance.

Rappel : groupes attribués vs groupes dynamiques

Dans le Centre d'administration Entra, la création d'un groupe propose deux dimensions à ne pas confondre :

• Le type de groupe : Microsoft 365 (collaboratif, avec boîte partagée, SharePoint, etc.) ou Sécurité (dédié aux permissions, assignable à des utilisateurs ou des appareils).
• Le type d'appartenance : Attribué (ajout manuel) ou Dynamique (règle basée sur des attributs, évaluée automatiquement par Entra ID).

Un groupe dynamique utilisateur peut par exemple regrouper automatiquement tous les employés dont l'attribut city vaut Oslo. Dès qu'un administrateur RH modifie la fiche d'un utilisateur, son appartenance au groupe se met à jour sans aucune action manuelle.

Créer un groupe dynamique utilisateur pas à pas

La logique de configuration reste identique avec ou sans la future dépréciation de memberOf. Voici la démarche standard côté portail.

Groupes dynamiques d'appareils et cas d'usage Intune

Le même mécanisme s'applique aux appareils, avec des attributs différents : fabricant, catégorie, version d'OS, ou identifiant de périphérique.

1(device.deviceManufacturer -eq "Dell") -and (device.deviceCategory -eq "Laptop")

Cette règle peut être affinée davantage, par exemple pour ne cibler qu'une gamme de matériel avec un opérateur startsWith sur le nom de l'appareil (XPS). Ces groupes dynamiques d'appareils sont particulièrement utiles pour :

• Cibler des politiques Intune par modèle ou catégorie de poste.
• Construire des règles Conditional Access restreignant l'accès à des appareils spécifiques.
• Automatiser des déploiements logiciels sans maintenance manuelle des listes.

Pourquoi Microsoft retire l'opérateur memberOf

L'opérateur memberOf permettait de construire une règle dynamique basée sur l'appartenance à un autre groupe — l'équivalent des groupes imbriqués d'Active Directory. Problème : cette fonctionnalité est restée en préversion publique pendant plusieurs années, sans jamais obtenir d'interface graphique. Elle n'était accessible que via PowerShell, en récupérant manuellement l'ID d'objet du groupe cible pour l'injecter dans la règle :

1# Ancienne règle utilisant l'opérateur memberOf (en cours de retrait)
2(user.memberOf -Any (group.objectId -in ['a1b2c3d4-e5f6-7890-abcd-ef1234567890']))

Ce modèle n'a jamais réellement scalé sur Entra ID comme il le faisait sur Active Directory : contrairement à l'imbrication classique de groupes AD, les mises à jour de règles basées sur memberOf généraient une charge d'évaluation disproportionnée à grande échelle. Autre point sensible : cet opérateur n'est pas cantonné aux groupes, on le retrouve aussi dans des règles associées aux unités d'administration et à certaines stratégies d'application, ce qui élargit le périmètre d'impact bien au-delà des seuls groupes de sécurité.

Migrer vers la nouvelle syntaxe simplifiée

Microsoft propose de remplacer les règles complexes en cascade par l'opérateur -in, qui accepte une liste de valeurs séparées par des virgules — beaucoup plus lisible et plus rapide à maintenir qu'une chaîne de conditions -or :

1# Nouvelle règle simplifiée avec l'opérateur -in
2(user.department -in ["IT Support", "Helpdesk", "Service Desk"])

Auditer vos règles avant la coupure de novembre

Avant de modifier quoi que ce soit, identifiez tous les groupes dynamiques qui exploitent memberOf. Le script suivant utilise le module Microsoft.Graph (PowerShell) et nécessite le scope Group.Read.All a minima :

1# Connexion avec le scope minimal nécessaire pour la lecture
2Connect-MgGraph -Scopes "Group.Read.All"
3 
4# Récupère tous les groupes à appartenance dynamique et filtre ceux utilisant memberOf
5Get-MgGroup -All -Filter "groupTypes/any(c:c eq 'DynamicMembership')" |
6    Where-Object { $_.MembershipRule -match "memberOf" } |
7    Select-Object DisplayName, Id, MembershipRule |
8    Format-Table -AutoSize

Une fois les groupes concernés identifiés, la mise à jour de la règle se fait avec le rôle Groups Administrator ou Global Administrator, via le scope Group.ReadWrite.All :

1# Mise à jour d'une règle dynamique existante
2Connect-MgGraph -Scopes "Group.ReadWrite.All"
3 
4Update-MgGroup -GroupId "<Id-du-groupe>" `
5    -MembershipRule '(user.department -in ["IT Support", "Helpdesk"])' `
6    -MembershipRuleProcessingState "On"

Pensez à répéter cette vérification sur les unités d'administration et les objets liés à des stratégies d'application, qui ne remontent pas dans le filtre groupTypes ci-dessus.

Pièges courants et dépannage

• La règle est enregistrée mais aucun membre n'apparaît : vérifiez d'abord que les utilisateurs ciblés disposent d'une licence Entra ID P1, cause la plus fréquente d'échec silencieux.
• Erreur de syntaxe dans l'éditeur de règle : les noms d'attributs sont sensibles à la casse dans certains contextes ; privilégiez l'éditeur visuel du portail pour éviter les fautes de frappe.
• Impossible de combiner appartenance attribuée et dynamique : ces deux modes sont mutuellement exclusifs sur un même groupe, il faut choisir l'un ou l'autre à la création.
• La règle memberOf fonctionne encore aujourd'hui mais cessera brutalement : ne repoussez pas la migration à la dernière minute, l'évaluation des règles n'est pas rétroactive une fois l'opérateur retiré.

Une fonctionnalité bonus à ne pas négliger : l'expiration des groupes

Au-delà des règles dynamiques, Entra ID propose une stratégie d'expiration des groupes, particulièrement utile contre la prolifération de groupes Microsoft 365 créés en self-service et jamais nettoyés :

• Définissez une durée (par exemple 180 jours) au-delà de laquelle un groupe inactif est signalé.
• Un contact administrateur reçoit une notification pour confirmer si le groupe est toujours utilisé.
• Si personne ne renouvelle, le groupe est placé dans la corbeille (restauration possible pendant une période limitée) avant suppression définitive.

Cette fonctionnalité s'applique groupe par groupe ou à l'ensemble du tenant, et constitue un excellent complément de gouvernance à mettre en place au moment où vous révisez vos règles dynamiques.

Points clés à retenir

• Microsoft retire l'opérateur memberOf des règles de groupes dynamiques Entra ID en novembre, une fonctionnalité restée en préversion sans interface graphique pendant des années.
• L'impact dépasse les groupes : unités d'administration et stratégies d'application peuvent aussi être concernées.
• La nouvelle syntaxe recommandée repose sur l'opérateur -in, plus simple à écrire et à maintenir que des chaînes de conditions -or.
• Auditez vos règles dès maintenant via Microsoft.Graph PowerShell pour repérer les groupes à risque avant la coupure.
• Profitez de cette migration pour activer l'expiration automatique des groupes, un excellent outil de gouvernance souvent sous-utilisé.

Pour aller plus loin, consultez la documentation officielle sur les règles d'appartenance dynamique Entra ID et sur la gestion du cycle de vie des groupes.