Merill Fernando (ex-Principal Product Manager – Microsoft Entra) revient sur un point important concernant les nouveaux "agent users" de Microsoft Entra Agent ID et leur interaction avec les groupes à appartenance dynamique. Microsoft a clarifié la façon dont les comptes "agent user" sont traités par les règles de groupes dynamiques dans Entra ID. Un compte agent user est évalué comme n'importe quel autre utilisateur par les règles de membership dynamique basées sur les propriétés utilisateur. Si le compte satisfait une règle, il peut être ajouté au groupe dynamique au même titre qu'un utilisateur classique. Cela signifie qu'un agent peut hériter de tout ce qui est rattaché au groupe : licences basées sur le groupe, accès aux applications, ressources de groupes Microsoft 365, ou d'autres permissions.
À noter : les agent users ne sont pas ajoutés automatiquement à tous les groupes dynamiques. Ils sont évalués par les mêmes règles que les utilisateurs classiques et ne sont ajoutés que s'ils satisfont ces règles. Le vrai problème réside dans les règles trop larges, qu'un agent user peut satisfaire sans que le propriétaire du groupe s'en rende compte.
Pourquoi les agent users ressemblent à des utilisateurs pour les règles dynamiques
Il faut distinguer deux identités dans Microsoft Entra Agent ID :
- L'identité principale de l'agent est un service principal. Elle n'est pas prise en charge comme membre d'un groupe dynamique.
- L'agent peut également disposer d'un compte "agent user" optionnel, destiné aux systèmes nécessitant une identité de type utilisateur. Microsoft le décrit comme un sous-type de la ressource user. Ce compte reçoit des tokens avec idtyp=user, peut être ajouté à des groupes et des unités d'administration, et peut se voir attribuer des licences. Microsoft Graph expose ce compte via la ressource agentUser.
Ce compte hérite de nombreuses propriétés utilisateur classiques, notamment : userPrincipalName, userType, department, companyName, employeeId, assignedLicenses, assignedPlans
Parce que la ressource agentUser hérite de ces propriétés, une règle écrite avant l'arrivée des agent users dans le tenant peut malgré tout matcher un agent. Prenons l'exemple d'une règle courante « tous les utilisateurs membres » :
(user.objectId -ne null) -and (user.userType -eq "Member")
La propriété userType permet de distinguer Member de Guest, mais un agent user peut également avoir userType défini sur Member : cette propriété ne dit donc rien sur le fait que l'identité corresponde ou non à une personne physique. Le même problème peut apparaître avec des règles basées sur le pays, le département, le nom de société, l'UPN, ou toute autre propriété utilisateur supportée.
Microsoft documente explicitement qu'un agent user peut se voir attribuer des licences, et que sa collection assignedLicenses inclut les licences héritées via le group-based licensing. Si un groupe dynamique est utilisé pour l'attribution de licences, un agent user qui rejoint ce groupe peut consommer l'une des licences disponibles. Si le pool de licences est épuisé, les nouveaux utilisateurs ajoutés ne recevront pas cette licence tant qu'une autre ne se libère pas.
Deux vérifications s'imposent côté licences :
- Le produit attribué au groupe pourrait être assigné à un agent qui n'en a pas l'usage.
- Le group-based licensing dynamique nécessite suffisamment de licences Entra ID P1 pour couvrir chaque utilisateur unique présent dans un ou plusieurs groupes dynamiques. Un agent user étant un sous-type d'utilisateur, il convient de vérifier avec votre contact licensing Microsoft l'impact de votre population d'agents sur ce besoin.
Les licences ne sont qu'une des conséquences possibles. Il faut également vérifier si chaque groupe concerné est utilisé pour :
- Les assignations d'applications d'entreprise (Enterprise applications)
- Les groupes Microsoft 365 et Teams
- Les permissions SharePoint
- Le ciblage de stratégies Conditional Access
- Les Access Packages et autres workflows de gouvernance des accès
- Les attributions de rôles Azure ou spécifiques à une application qui s'appuient sur ce groupe
À noter également : un agent user ne peut pas être ajouté à un groupe assignable à un rôle (role-assignable group), ce qui limite son impact potentiel sur les rôles Entra ID les plus sensibles.
Voici ce qui est recommander :
- Auditez vos règles de membership dynamique existantes (utilisateurs et licences) afin d'identifier celles qui pourraient matcher un agent user sans distinction explicite.
- Ajoutez si besoin une condition d'exclusion explicite des agent users dans vos règles dynamiques les plus sensibles (licences, accès applicatifs, Conditional Access).
- Vérifiez le dimensionnement de vos licences Entra ID P1 utilisées pour le group-based licensing dynamique en tenant compte de votre population d'agents.
- Passez en revue les groupes dynamiques utilisés pour les accès SharePoint, les Access Packages, la Conditional Access et les rôles Azure afin de vérifier qu'aucun agent user n'y a été intégré involontairement.
Plus d'informations sur l'article original de Merill Fernando : Microsoft Entra agent users can join your dynamic groups. Here is what to check - merill.net
