Semion Vasilevitzky et Jonathan Elkabas

Note de la rédaction : Bienvenue dans le deuxième « point de contrôle pratique » du guide complet intitulé « Comprendre et prévenir les attaques d’identité ciblant l’agent Entra ID ». Tout au long de cette série, ces mini-guides pratiques et concis illustrent précisément les objets et les comportements dont nous venons de parler. Si vous êtes ici pour acquérir une compréhension théorique, n’hésitez pas à les parcourir rapidement ; si vous effectuez des tests dans votre propre tenant, ils constituent le moyen le plus rapide de suivre les étapes. Chaque point de contrôle est autonome et comporte une liste actualisée des identifiants (schéma, entité principale, identité d’agent, utilisateur d’agent) afin que les sections suivantes puissent faire référence aux mêmes objets. Pour revoir les chapitres précédents et les leçons pratiques, commencez ici.


Lors de notre premier « Practice Checkpoint », vous avez appris à configurer l'identifiant d'agent (Agent ID) et à créer votre premier utilisateur agent.

Maintenant que les objets principaux existent, nous allons mettre en place le modèle d'autorisations tel qu'il apparaît dans les déploiements réels : des autorisations directes, réservées à l'application, sur l'identité de l'agent, et des autorisations déléguées accordées au niveau du blueprint et marquées comme héritables.

Ce point de contrôle définit les données d'entrée exactes que nous validerons ultérieurement dans les jetons au cours des processus d'authentification.

Attribuer une autorisation à l'identité de l'agent

Pour illustrer les autorisations « directes » propres à une application au niveau de l'identité de l'agent, attribuez un rôle d'application à <agent-identity-id> en utilisant le même appRoleAssignments selon le même schéma que précédemment.

Dans cette démo, le appRoleId représente User.Read.All. Nous l'utiliserons plus tard pour nous authentifier en tant qu'agent et pour répertorier les utilisateurs.

Figure 1. Attribution d'un rôle d'application à l'identité de l'agent

Configurer les autorisations héritables

Configurez les autorisations héritables afin que l'agent puisse hériter des périmètres délégués dans les flux délégués.


Étape 1 : Accorder l'autorisation déléguée

Créer un oauth2PermissionGrants enregistrement qui accorde Group.Read.All vers le modèle d'identité de l'agent (processus standard de consentement délégué).

Figure 2. Attribution du droit « Group.Read.All » à l'identité de l'agent

Étape 2 : Le marquer comme héritable

Appelez le /applications/microsoft.graph.agentIdentityBlueprint /<agent identity blueprint id>/inheritablePermissions point de terminaison et incluez l'ID d'application de la ressource Graph. Utilisez une portée énumérée afin que l'identité de l'agent n'hérite que de la Group.Read.All autorisations.

Figure 3. Limitation des droits de lecture hérités de l'identité de l'agent à l'aide d'une portée énumérée

Dans un scénario d'authentification déléguée, nous allons examiner et utiliser ces autorisations pour répertorier les groupes de locataires. Si vous souhaitez que toutes les autorisations soient héritées, il suffit de définir gentil à allAllowed au lieu de enumerated et supprimez la propriété « scopes ».

Bien que cela ne soit pas documenté, il est possible d'hériter des autorisations énumérées propres à l'application. Au lieu des champs d'application, nous utiliserons appRoleIds, qui nécessitent le GUID du rôle de l'application. La requête se présentera donc comme suit :

Figure 4. Activation de l'héritage des autorisations énumérées propres à l'application

Vous pouvez également définir les deux en même temps. Pour mettre à jour les autorisations héritables existantes, envoyez une requête « Patch » à la ressource concernée que vous souhaitez mettre à jour.

Correctif : /applications/microsoft.graph.agentIdentityBlueprint/<agent-identity-blueprint>/inheritablePermissions/<resource-app-id>

Prochaine étape : nous allons découvrir comment votre identité d'agent s'authentifie et fonctionne dans Entra ID.


Découvrez le guide