Pourquoi les groupes imbriqués posent problème en gestion des accès
Les groupes imbriqués (des groupes ajoutés comme membres d'autres groupes) sont pratiques pour organiser des hiérarchies d'autorisations, mais ils compliquent sérieusement l'audit des accès. Savoir qui a réellement accès à une ressource sensible devient un exercice de traçabilité à travers plusieurs niveaux de groupes, avec un support parfois incohérent selon les workloads Microsoft 365. Les groupes de distribution tolèrent mieux ce modèle, car l'enjeu se limite au routage d'e-mails plutôt qu'à l'octroi de permissions sur des données confidentielles.
Microsoft vient d'ajouter une nouvelle propriété nommée disableNesting sur les objets groupe dans Microsoft Graph, permettant de verrouiller explicitement cette possibilité d'imbrication au niveau d'un groupe de sécurité donné.
Fonctionnalité en cours de déploiement
La propriété disableNesting n'est pas encore exposée dans le Centre d'administration Entra. Pour l'instant, la création et la vérification passent exclusivement par Microsoft Graph (API REST ou SDK PowerShell).
Comprendre la propriété disableNesting
Par défaut, disableNesting vaut false : le comportement actuel des groupes de sécurité est inchangé, l'imbrication reste possible. Lorsqu'elle est positionnée à true sur un groupe de sécurité, Entra ID refuse toute tentative d'ajouter un autre groupe comme membre de ce groupe.
Point notable pour les architectes : la propriété est disponible directement sur le endpoint de production V1.0, alors que la plupart des nouveautés Entra transitent d'abord par le endpoint beta avant d'être promues. Cela suggère une fonctionnalité jugée suffisamment stable par Microsoft pour un déploiement direct en production, même si l'expérience utilisateur (UX) associée dans le portail n'a pas encore suivi.
Créer un groupe de sécurité avec l'imbrication désactivée
La création se fait via l'API Graph, en passant disableNesting à true dans le corps de la requête. Il n'existe aujourd'hui aucune option équivalente dans le portail.
Construire le corps de la requête
Définissez les propriétés du groupe, y compris disableNesting à true.
1$RequestBody = @{}2$RequestBody.Add("displayName","Finance Auditors")3$RequestBody.Add("securityEnabled", $true)4$RequestBody.Add("disableNesting", $true)5$RequestBody.Add("mailEnabled", $false)6$RequestBody.Add("mailNickname", "Finance.Auditors")7$RequestBody.Add("description", "A security group for financial auditors. Nesting is disabled for this group")Envoyer la requête via Invoke-MgGraphRequest
Appelez le endpoint V1.0 des groupes en méthode POST.
1$Uri = "https://graph.microsoft.com/V1.0/groups"2Try {3 $NewGroup = Invoke-MgGraphRequest -Uri $Uri -Method Post -Body $RequestBody -ErrorAction Stop4 Write-Host ("Created group: {0}" -f $NewGroup.DisplayName)5} Catch {6 Write-Host "Failed to create group"7}Alternative avec le SDK Microsoft Graph PowerShell
Si vous préférez un cmdlet natif, New-MgGroup accepte le même corps de requête. Ce test a été réalisé avec la version 2.38.1 du SDK.
1$NewGroup = New-MgGroup -BodyParameter $RequestBody -ErrorAction StopPropriété figée à la création
À ce stade des tests, disableNesting ne peut être défini qu'au moment de la création du groupe. Toute tentative de modification ultérieure échoue avec une erreur 400 (BadRequest). Ce comportement rappelle celui des labels de gestion de conteneur, qui ne peuvent également être assignés qu'à la création d'un groupe de sécurité.
Voici l'erreur retournée lors d'une tentative de mise à jour a posteriori :
1$UpdateBody = @{}2$UpdateBody.Add("disableNesting", $false)3Update-MgGroup -GroupId $Group.Id -BodyParameter $UpdateBody4 5Update-MgGroup_Update: Unexpected request made to property 'disableNesting' of resource 'Group'.6Status: 400 (BadRequest)Conséquence pratique pour la planification : si un groupe existant doit basculer vers un mode « imbrication interdite », il faudra le recréer et migrer ses membres, pas simplement patcher la propriété.
Filtrer et interroger la propriété disableNesting
Le endpoint Groups de Graph API supporte le filtrage sur disableNesting, aussi bien sur V1.0 que sur beta. Exemple pour retrouver tous les groupes de sécurité (non mail-enabled) qui bloquent l'imbrication :
1[array]$Data = Get-MgGroup -Filter "securityEnabled eq true and mailEnabled eq false and disableNesting eq true" -AllLa requête Graph équivalente en brut :
1$Uri = "https://graph.microsoft.com/V1.0/groups/?`$filter=securityEnabled eq true and mailEnabled eq false and disableNesting eq true&`$Select=id,displayname,disableNesting"2[array]$Data = Invoke-MgGraphRequest -Uri $Uri -Method Get -OutputType PsObject | Select-Object -ExpandProperty ValuePour interroger un groupe précis, il faut demander explicitement la propriété, car elle ne fait pas partie du jeu de propriétés retourné par défaut :
1$Uri = ("https://graph.microsoft.com/V1.0/groups/{0}?`Select=id,displayname,disableNesting" -f $NewGroup.Id)2$Data = Invoke-MgGraphRequest -Uri $Uri -Method Get -OutputType PsObject3$Data | Format-List4 5@odata.context : https://graph.microsoft.com/v1.0/$metadata#groups(id,displayName,disableNesting)/$entity6id : 778818b5-7e68-4bc2-b667-0aa996c802807displayName : Finance Auditors8disableNesting : TrueLimite actuelle du SDK PowerShell
Ni Get-MgGroup ni Get-MgBetaGroup ne retournent la valeur de disableNesting, même en interrogeant l'objet complet. Il faut passer par Invoke-MgGraphRequest avec un $Select explicite tant que le schéma Graph n'a pas été mis à jour et qu'une nouvelle version du SDK n'a pas ajouté la propriété au jeu de champs disponible.
Comportement au moment d'un ajout de membre imbriqué
Si vous tentez d'ajouter un groupe comme membre d'un groupe qui bloque l'imbrication, New-MgGroupMember (ou la requête Graph sous-jacente) renvoie une erreur explicite :
1$GroupId = '9b5f3d2c-6c9f-4132-aa3d-88d903891206'2New-MgGroupMember -GroupId $GroupId -DirectoryObjectId $NewGroup.Id3 4New-MgGroupMember_CreateExpanded: Cannot add group '778818b5-7e68-4bc2-b667-0aa996c80280' as a member to group '9b5f3d2c-6c9f-4132-aa3d-88d903891206' because nesting is disabled on one or both groups. paramName: Members, paramValue: , objectType: Microsoft.Online.DirectoryServices.GroupLe détail important est dans le message d'erreur : le blocage s'applique si l'un ou l'autre des deux groupes a disableNesting à true, que ce soit le groupe cible ou le groupe candidat à l'imbrication. Autrement dit, un groupe verrouillé ne peut participer à aucune relation d'imbrication, ni comme conteneur, ni comme membre.
Des tests via le Centre d'administration Entra confirment ce comportement : la tentative d'ajout échoue également depuis le portail, mais avec un message beaucoup moins explicite que celui renvoyé par le cmdlet. Il est probable que Microsoft harmonise ce point une fois l'UX de gestion de disableNesting disponible dans le portail.
Permissions requises : appliquer le moindre privilège
Pour définir disableNesting à la création d'un groupe de sécurité, le compte utilisé doit disposer de la permission Group.ReadWrite.All. Microsoft a toutefois introduit une permission plus granulaire, Group-NestingSupport.ReadWrite.All, qui suffit également à l'opération.
| Permission | Portée | Cas d’usage recommandé |
|---|---|---|
| Group.ReadWrite.All | Gestion complète des groupes (création, mise à jour, membres) | Applications ou scripts de provisioning généraux |
| Group-NestingSupport.ReadWrite.All | Contrôle spécifique de la propriété disableNesting | Scripts dédiés à la gouvernance des groupes sensibles, principe du moindre privilège |
Côté ingénierie, il est raisonnable de réserver Group-NestingSupport.ReadWrite.All aux applications ou runbooks dédiés à la gouvernance des groupes à haut risque, plutôt que d'accorder Group.ReadWrite.All de façon large à un service principal qui n'a besoin que de verrouiller cette propriété.
Pièges connus et points de vigilance
- Aucune interface graphique : toute automatisation doit passer par Graph API ou le SDK PowerShell, pas par le Centre d'administration Entra pour l'instant.
- Propriété non modifiable après création : anticipez la conception des groupes sensibles avant leur mise en production, car un changement de politique impose une recréation.
- Cmdlets Get incomplets : ne vous fiez pas à Get-MgGroup ou Get-MgBetaGroup pour auditer cette propriété tant que le schéma SDK n'aura pas été mis à jour ; utilisez Invoke-MgGraphRequest avec $Select.
- Blocage bidirectionnel : un groupe verrouillé ne peut ni recevoir de groupe membre, ni être ajouté lui-même comme membre d'un autre groupe.
- Messages d'erreur inégaux : le portail Entra est moins verbeux que les cmdlets PowerShell pour expliquer un refus d'ajout ; privilégiez les scripts pour du diagnostic précis en environnement de production.
Cas d'usage recommandés en gouvernance des accès
Cette fonctionnalité prend tout son sens dès qu'il faut garantir une composition de groupe explicite et auditable, notamment pour :
- les groupes d'accès privilégié utilisés dans les assignations de rôles d'administration ;
- le contrôle d'accès à des applications sensibles ;
- les accès dédiés aux comptes exécutifs ;
- les ressources soumises à des exigences réglementaires ou de conformité ;
- les groupes faisant l'objet de revues d'accès régulières (access reviews).
Pour ces scénarios, savoir précisément qui a accès à une ressource vaut toujours mieux que de devoir remonter une chaîne de groupes imbriqués lors d'un audit ou d'un incident de sécurité.
Points clés à retenir
- disableNesting est une nouvelle propriété Graph des groupes de sécurité qui interdit l'ajout de groupes comme membres.
- Elle se définit uniquement à la création du groupe, via l'API V1.0 ou le SDK PowerShell (New-MgGroup, testé en version 2.38.1).
- Le blocage s'applique dès que l'un des deux groupes impliqués dans la relation a la propriété activée.
- Les permissions Group.ReadWrite.All ou la permission granulaire Group-NestingSupport.ReadWrite.All suffisent pour créer ce type de groupe.
- Le Centre d'administration Entra et les cmdlets Get-MgGroup / Get-MgBetaGroup n'exposent pas encore complètement cette propriété : comptez sur des mises à jour futures du schéma Graph et du SDK.
En attendant l'arrivée de l'UX correspondante dans le portail, les équipes de sécurité ont tout intérêt à documenter dès maintenant leurs groupes sensibles candidats à ce verrouillage, afin de les recréer avec disableNesting activé lors de la prochaine revue de gouvernance des accès.
