Enregistrement personnalisé de l’application client pour Agent 365 CLI

L’interface de ligne de commande (CLI) Agent 365 nécessite une inscription d’application locataire personnalisée dans votre locataire Microsoft Entra ID pour authentifier et gérer les blueprints d’identité d’assistant.

Cet article décompose le processus en quatre principales étapes :

  1. Enregistrer l’application
  2. Définissez l’URI de redirection
  3. Copier l’ID de l’application (client)
  4. Configurer les autorisations de l’APInécessite des droits d’administrateur
  5. Ajouter la revendication de rôle wids

Si vous rencontrez des problèmes, consultez la section Dépannage.

Configuration requise

Avant de commencer, assurez-vous d’avoir accès au centre d’administration Microsoft Entra et, si nécessaire, à l’un des rôles d’administrateur requis pour accorder le consentement.

Enregistrer l'application

Par défaut, tout utilisateur du locataire peut enregistrer des applications dans le centre d’administration Microsoft Entra. Cependant, les administrateurs de locataires peuvent restreindre cette capacité. Si vous ne pouvez pas enregistrer votre application, contactez votre administrateur.

Vous avez besoin d’un de ces rôles d’administrateur pour 4. Configurer les autorisations de l’API

Astuce

Vous n’avez pas accès administrateur ? Vous pouvez effectuer les étapes 1 à 3 vous-même, puis demander à l’administrateur de votre locataire de terminer l’étape 4. Fournissez-leur votre ID d’application (client) de l’étape 3 et un lien vers la section Configurer les autorisations de l’API.

Astuce

Les administrateurs généraux peuvent éviter l’inscription manuelle. Exécutez a365 setup requirements et, si l’application Agent 365 CLI n’est pas présente dans votre locataire, la CLI vous invite à la créer et à accorder automatiquement le consentement d’administrateur. Tapez C à la requête pour créer l’application en une seule étape. Si vous utilisez cette méthode automatisée, vous pouvez ignorer les étapes de cette section.

1. Enregistrer l’application

Ces instructions résument les instructions complètes pour créer l’enregistrement d’une application.

  1. Accédez au centre d’administration Microsoft Entra

  2. Sélectionnez Inscriptions d’applications

  3. Sélectionnez Nouvelle inscription

  4. Saisissez :

    • Nom : saisissez un nom significatif pour votre application, tel que my-agent-app. Les utilisateurs de l’application voient ce nom, et vous pouvez le modifier à tout moment. Vous avez plusieurs inscriptions d’applications ayant le même nom.

      Astuce

      Si vous souhaitez utiliser le flux sans configuration a365 setup all --agent-name, nommez l’application précisément Agent 365 CLI. La CLI recherche automatiquement l’application client sous ce nom d’affichage bien connu, donc vous n’avez pas besoin de copier l’ID client dans un fichier de configuration.

    • Types de comptes pris en charge : comptes de ce répertoire organisationnel uniquement (locataire unique)

    • URI de redirection : sélectionnez Client public/natif (mobile et bureau) et saisissez http://localhost:8400/

  5. Sélectionnez Inscrire

La CLI nécessite au total trois URI de redirection. La CLI ajoute automatiquement celles qui manquent lorsque vous l’exécutez a365 setup requirements:

URI Objectif
http://localhost:8400/ Authentification du navigateur interactif de la bibliothèque d’authentification Microsoft (MSAL)
http://localhost Kit de développement logiciel (SDK) Microsoft Graph PowerShell Connect-MgGraph
ms-appx-web://Microsoft.AAD.BrokerPlugin/{client-id} À l’aide du gestionnaire de comptes Web (WAM)

Consultez ce que la CLI configure automatiquement pour obtenir davantage de détails.

2. Définissez l’URI de redirection

  1. Accédez à Vue d’ensemble et copiez la valeur de l’ID de l’application (client).
  2. Accédez à Authentification (version préliminaire), puis sélectionnez Ajouter une URI de redirection.
  3. Sélectionnez Applications mobiles et de bureau et définissez la valeur à ms-appx-web://Microsoft.AAD.BrokerPlugin/{client-id}, où {client-id}correspond à la valeur de l’application (ID client) que vous avez copié.
  4. Sélectionnez Configurer pour ajouter la valeur.

3. Copier l’ID de l’application (client)

Sur la page Vue d’ensemble, copiez l’ID d’application (client) au format GUID. Vous utilisez cette valeur lors de l’exécution de a365 setup all ou lors de la création manuelle de a365.config.json.

Astuce

Ne confondez pas cette valeur avec ID d’objet – vous avez besoin de ID d’application (client).

Si vous avez nommé votre application Agent 365 CLI à l’étape 1, vous pouvez ignorer cette étape lorsque vous utilisez a365 setup all --agent-name. La CLI résout automatiquement l’identifiant client par nom d’affichage.

4. Configurer les autorisations API

Important

Vous avez besoin de privilèges administrateur pour cette étape. Si vous êtes un développeur sans accès administrateur, envoyez votre Identifiant Application (ID client) de l’étape 3 à votre administrateur locataire et faites-lui effectuer cette étape.

Note

À partir de décembre 2025, les autorisations AgentIdentityBlueprint.*, AgentInstance.* et AgentIdentity.* sont des API bêta et pourraient ne pas être visibles dans le centre d’administration Microsoft Entra. Si ces autorisations deviennent généralement disponibles dans votre tenant, vous pouvez utiliser l’option A pour toutes les autorisations.

Choisissez la méthode appropriée :

  • Option A : utiliser le centre d’administration Microsoft Entra pour toutes les autorisations (si les autorisations bêta sont visibles)
  • Option B : utiliser Microsoft API Graph pour ajouter toutes les autorisations (recommandé si les autorisations bêta ne sont pas visibles)

Option A : centre d’administration Microsoft Entra (méthode standard)

Utilisez cette méthode si vous pouvez voir les autorisations bêta dans votre locataire.

  1. Dans votre enregistrement d’application, accédez à Autorisations de l’API.

  2. Sélectionnez Ajouter une autorisation>Microsoft Graph>Permissions déléguées.

    Important

    Vous devez utiliser les autorisations déléguées (et non autorisations d’application). Le CLI s’authentifie de manière interactive – vous vous connectez, et il agit en votre nom. Pour en savoir plus, voir type de permission incorrect.

  3. Ajoutez ces sept permissions une par une :

    Autorisation Objectif
    AgentIdentityBlueprint.ReadWrite.All Création de blueprint, gestion des clés secrètes client, permissions héritables, identifiants d’identité fédérée et suppression (API bêta)
    AgentIdentityBlueprintPrincipal.Create Créer le principal de service pour le Blueprint de l’assistant (API bêta)
    AgentIdentity.Read.All Vérification de l’idempotence et recherche du principal de service d’identité d’assistant (API bêta)
    AgentIdentity.DeleteRestore.All Supprimer les principaux de service d’identité d’agent lors du nettoyage (API bêta)
    AgentRegistration.ReadWrite.All Lire et écrire toutes les inscriptions d’assistant
    Application.Read.All Recherche du principal de service par identifiant d’application (remplacement plus restreint de Directory.Read.All)
    User.Read Lire le profil de l’utilisateur connecté pour l’attribution du propriétaire et du sponsor du blueprint

    Note

    AgentRegistration.ReadWrite.All est nécessaire pour la mise en place de l’agent. Le validateur CLI vérifie explicitement cette permission. Elle doit figurer dans l’enregistrement de votre application et disposer du consentement administrateur.

    Pour chaque autorisation :

    • Dans le champ de recherche, saisissez le nom de l’autorisation (p. ex., AgentIdentityBlueprint.ReadWrite.All).
    • Cochez la case à côté de l’autorisation.
    • Sélectionnez Ajouter des autorisations.
    • Répétez cette étape pour chacune des sept autorisations.

  4. Sélectionnez Accorder un consentement à [votre locataire].

    • Pourquoi est-ce nécessaire ? Les plans d’identité d’agent sont des ressources à l’échelle du locataire auxquelles plusieurs utilisateurs et applications peuvent se référer. Sans consentement au niveau du locataire, la CLI échoue lors de l’authentification.
    • Que faire en cas d’échec ? Vous devez disposer du rôle d’administrateur d’application, d’administrateur d’application cloud ou d’administrateur global. Demandez de l’aide à votre administrateur de locataires.

  5. Vérifiez que toutes les autorisations affichent des coches vertes sous le statut.

Si les autorisations bêta (AgentIdentityBlueprint.*) ne sont pas visibles, passez à l’option B.

Option B : API Microsoft Graph (pour les autorisations bêta)

Utilisez cette méthode si le centre d’administration Microsoft Entra n’affiche pas les autorisations AgentIdentityBlueprint.*.

Avertissement

Si vous utilisez cette méthode API, n’utilisez pas le bouton « Accorder le consentement administrateur » du centre d’administration Microsoft Entra par la suite. La méthode API accorde automatiquement le consentement administrateur, et l’utilisation du bouton du centre d’administration Microsoft Entra supprime vos autorisations bêta. Pour plus d’informations, voir les autorisations bêta disparaissent.

  1. Ouvrez l’Explorateur graphique.

  2. Connectez-vous avec votre compte administrateur (Administrateur d’application ou Administrateur d’application cloud).

  3. Accordez le consentement administrateur en utilisant API Graph. Pour terminer cette étape, vous avez besoin de ce qui suit :

    • ID du principal de service. Vous avez besoin de la valeur de la variable SP_OBJECT_ID.
    • ID de ressource Microsoft Graph Vous avez besoin de la valeur de la variable GRAPH_RESOURCE_ID.
    • Créer (ou mettre à jour) les permissions déléguées en utilisant le type de ressource oAuth2PermissionGrant avec les valeurs des variables SP_OBJECT_ID et GRAPH_RESOURCE_ID .

Utilisez les informations des sections suivantes pour effectuer ces étapes.

Obtenez votre ID du principal de service

Un principal de service est l’identité de votre application dans votre locataire. Vous en avez besoin avant de pouvoir accorder des autorisations via l’API.

  1. Définissez la méthode de l’explorateur graphique sur GET et utilisez cette URL. Remplacez <YOUR_CLIENT_APP_ID> par votre ID client d’application obtenu à l’étape 3 : copier l’ID d’application (client).

    https://graph.microsoft.com/v1.0/servicePrincipals?$filter=appId eq '<YOUR_CLIENT_APP_ID>'&$select=id

  2. Sélectionnez Exécuter la requête.

    • Si la requête réussit, la valeur retournée est votre SP_OBJECT_ID.

    • Si la requête échoue en raison d’une erreur de permissions, sélectionnez l’onglet Modifier les permissions, donnez votre consentement aux autorisations requises, puis sélectionnez Exécuter la requête à nouveau. La valeur retournée est votre SP_OBJECT_ID.

    • Si la requête ne renvoie aucun résultat ("value": []), créez le service principal en suivant les étapes ci-dessous :

      1. Définissez la méthode sur POST et utilisez cette URL :

        https://graph.microsoft.com/v1.0/servicePrincipals

        Corps de demande (remplacez YOUR_CLIENT_APP_ID par l’ID client de votre application) :

        {
   "appId": "YOUR_CLIENT_APP_ID"
}

      2. Sélectionnez Exécuter la requête. Vous devriez obtenir une réponse 201 Created. La valeur id retournée est votre SP_OBJECT_ID.

Obtenez votre identifiant de ressource Graph

  1. Réglez la méthode de l’explorateur graphique sur GET et utilisez cette URL :

    https://graph.microsoft.com/v1.0/servicePrincipals?$filter=appId eq '00000003-0000-0000-c000-000000000000'&$select=id

  2. Sélectionnez Exécuter la requête.

    • Si la requête réussit, copiez la valeur id. Cette valeur est votre GRAPH_RESOURCE_ID.
    • Si la requête échoue en raison d’une erreur de permissions, sélectionnez l’onglet Modifier les permissions, donnez votre consentement aux autorisations requises, puis sélectionnez Exécuter la requête à nouveau. Copiez la valeur id. Cette valeur est votre GRAPH_RESOURCE_ID.

Créez des autorisations déléguées

Cet appel d’API accorde le consentement administrateur à l’échelle du locataire pour les sept autorisations, y compris les autorisations bêta qui ne sont pas visibles dans le centre d’administration Microsoft Entra.

  1. Réglez la méthode de l’explorateur graphique sur POST et utilisez cette URL ainsi que le corps de la requête :

    https://graph.microsoft.com/v1.0/oauth2PermissionGrants

    Corps de la demande :

    {
"clientId": "<SP_OBJECT_ID>",
"consentType": "AllPrincipals",
"principalId": null,
"resourceId": "<GRAPH_RESOURCE_ID>",
"scope": "AgentIdentityBlueprint.ReadWrite.All AgentIdentityBlueprintPrincipal.Create AgentIdentity.Read.All AgentIdentity.DeleteRestore.All AgentRegistration.ReadWrite.All Application.Read.All User.Read"
}

  2. Sélectionnez Exécuter la requête.

    • Si vous obtenez une réponse 201 Created : succès ! Le champ scope dans la réponse affiche les sept noms de permission. Vous avez terminé.
    • Si la requête échoue en raison d’une erreur d’autorisations, sélectionnez l’onglet Modifier les autorisations, donnez votre consentement aux autorisations requises, puis sélectionnez Exécuter la requête à nouveau.
    • Si vous obtenez l’erreur Request_MultipleObjectsWithSameKeyValue : un octroi existe déjà. Peut-être que quelqu’un a ajouté des autorisations précédemment. Voir la mise à jour suivante des autorisations déléguées.

Avertissement

Le consentType: "AllPrincipals" dans la requête POSTaccorde déjà le consentement administrateur à l’échelle du locataire. NE SÉLECTIONNEZ PAS Accorder le consentement d’administrateur dans le centre d’administration Microsoft Entra après avoir utilisé cette méthode API : cela supprime vos autorisations bêta, car le centre d’administration Microsoft Entra ne peut pas voir les autorisations bêta et écrase votre consentement accordé par l’API avec seulement les autorisations visibles.

Mettre à jour des autorisations déléguées

Lorsque vous obtenez une erreur Request_MultipleObjectsWithSameKeyValue en suivant les étapes pour créer des autorisations déléguées, utilisez ces étapes pour mettre à jour les autorisations déléguées.

  1. Réglez la méthode de l’explorateur graphique sur GET et utilisez cette URL :

    https://graph.microsoft.com/v1.0/oauth2PermissionGrants?$filter=clientId eq 'SP_OBJECT_ID_FROM_ABOVE'

  2. Sélectionnez Exécuter la requête. Copiez la valeur id de la réponse. Cette valeur est YOUR_GRANT_ID.

  3. Définissez la méthode de l’explorateur graphique sur PATCH et utilisez cette URL avec YOUR_GRANT_ID.

    https://graph.microsoft.com/v1.0/oauth2PermissionGrants/<YOUR_GRANT_ID>

    Corps de la demande :

    {
   "scope": "AgentIdentityBlueprint.ReadWrite.All AgentIdentityBlueprintPrincipal.Create AgentIdentity.Read.All AgentIdentity.DeleteRestore.All AgentRegistration.ReadWrite.All Application.Read.All User.Read"
}

  4. Sélectionnez Exécuter la requête. Vous devriez recevoir une réponse 200 OK avec les sept autorisations dans le champ scope.

5. Ajouter la revendication de rôle wids

L’Agent 365 CLI lit directement les attributions de rôles de votre répertoire Entra depuis le jeton d’accès pour déterminer si vous disposez de privilèges administrateur. Cela nécessite d’ajouter la revendication wids aux jetons d’accès émis pour l’enregistrement de votre application.

Sans cette revendication, le CLI ne peut pas détecter votre rôle et affiche des instructions PowerShell pour chaque étape nécessitant des privilèges d’administrateur - même lorsque vous êtes administrateur. Complétez cette étape pour obtenir le comportement attendu.

  1. Dans l’enregistrement d’application, accédez à Configuration des jetons.

  2. Sélectionnez Ajouter une revendication en option.

  3. Pour le type de jeton, sélectionnez Accès.

  4. Dans la liste des revendications, cochez la case à côté de wids.

  5. Sélectionnez Ajouter.

    Si vous êtes invité à activer l’autorisation Microsoft Graph profile pour permettre la revendication, sélectionnez Oui, ajouter.

Note

La revendication wids contient les GUID de modèle de rôle des rôles d’annuaire Entra attribués directement à l’utilisateur connecté. Le CLI utilise ces GUID pour détecter les rôles d’administrateur général et d’administrateur ID d’assistant sans appel API Graph supplémentaire.

Limitation :wids ne reflète que les rôles directement attribués. Si votre locataire attribue des rôles d’annuaire via des groupes de sécurité attribuables à des rôles, l’interface CLI risque de ne pas détecter ces attributions de rôles basées sur des groupes. L’attribution directe de rôles constitue la norme pour les rôles d’administrateur et de développeur d’ID d’assistants.

Meilleures pratiques de sécurité

Vérifiez ces directives pour garantir la sécurité et la conformité à votre inscription à votre application.

À faire :

  • Utilisez l’enregistrement en locataire unique.
  • Accordez uniquement les autorisations déléguées.
  • Auditez régulièrement les autorisations.
  • Supprimez l’application lorsque vous n’en avez plus besoin.

À ne pas faire :

  • Octroi d’autorisations d’application. N’utilisez que le délégué.
  • Partagez publiquement l’identifiant client.
  • Accordez d’autres autorisations inutiles.
  • Utilisez l’application pour d’autres usages.

Ce que la CLI configure automatiquement

Lorsque vous exécutez a365 setup requirements, la CLI valide l’enregistrement de votre application et pourrait devoir apporter des modifications. Avant d’appliquer toute modification, la CLI vous présente un résumé et vous demande de confirmer :

WARNING: The CLI needs to make the following changes to your app registration (<app-id>):

  - Add redirect URI(s): http://localhost
  - Enable 'Allow public client flows' (isFallbackPublicClient = true)

Do you want to proceed? (y/N):

Pour ignorer la requête de confirmation (p. ex., dans un environnement d’intégration continue), utilisez l’option --yes :

a365 setup requirements --yes

Le tableau suivant décrit chaque modification que le CLI pourrait apporter :

Modification Raison
Ajoutez une URI de redirection http://localhost Le kit SDK Microsoft Graph PowerShell requiert cet URI pour l’authentification via le navigateur. Sans cette URI, les opérations de concession OAuth2 aboutissent à un jeton dépourvu des autorisations déléguées requises et échouent avec une erreur 403.
Ajoutez une URI de redirection http://localhost:8400/ MSAL nécessite cet URI pour l’authentification interactive du navigateur.
Ajoutez une URI de redirection ms-appx-web://Microsoft.AAD.BrokerPlugin/{id} Nécessaire pour le gestionnaire de comptes web (WAM), un courtier d’authentification pour Windows. En savoir plus sur Acquisition de jetons limités à l’appareil.
Activer Autoriser les flux de clients publics Requis pour le mécanisme de secours d’authentification par code d’appareil sur macOS, Linux, le sous-système Windows pour Linux (WSL), les environnements sans interface graphique, ainsi que comme solution de secours pour les stratégies d’accès conditionnel sous Windows.
Ajouter des autorisations manquantes à l’inscription de l’application Ça maintient l’enregistrement de l’application synchronisé avec les nouveaux autorisations requises après une mise à jour de la ligne de commande.
Étendre l’octroi du consentement administrateur Étend l’octroi d’autorisations OAuth2 existant pour inclure toutes les nouvelles autorisations ajoutées.

Si vous refusez la requête, la CLI ne modifie pas l’enregistrement de votre application. Si des modifications sont nécessaires pour que la CLI fonctionne, vous pouvez les configurer manuellement dans le centre d’administration Microsoft Entra ou les relancer avec --yes.

Étapes suivantes

Après avoir enregistré votre application client personnalisée, utilisez-la avec la CLI Agent 365 pour compléter votre configuration Agent 365 :

Démarrer avec le développement Agent 365

Résolution des problèmes

Cette section décrit comment résoudre les erreurs liées à l’enregistrement d’une application client personnalisée.

Astuce

Le Guide de dépannage Agent 365 contient des recommandations générales de dépannage, les meilleures pratiques et des liens vers du contenu de dépannage pour chaque étape du cycle de développement de l’Agent 365.

La validation de la CLI échoue lors de la configuration

Symptôme : l’exécution de a365 setup ou de a365 setup requirements échoue avec des erreurs de validation concernant votre application client personnalisée.

Solution : utilisez cette liste de vérification pour vous assurer que l’enregistrement de votre application est correct :

# Run requirements validation to see validation messages
a365 setup requirements

Résultat attendu : la CLI affiche Custom client app validation successful.

Si vous n’obtenez pas le résultat attendu, vérifiez chacun des points suivants :

Vérification Comment vérifier Correction
✅ Utilisation du bon ID Vous avez copié ID d’application (client) (et non l’ID d’objet) Accédez à l’application Vue d’ensemble dans le centre d’administration Microsoft Entra
✅ Autorisations déléguées Permissions afficher Type : délégué dans les permissions API Voir Type de permission incorrect
✅ Toutes les permissions ajoutées Voir toutes les permissions listées ci-dessous Suivez à nouveau l’étape 4
✅ Consentement d’administrateur accordé Tous affichent la coche verte sous Statut Voir Consentement administrateur accordé incorrectement

Autorisations déléguées requises :

  • AgentIdentityBlueprint.ReadWrite.All [Bêta]
  • AgentIdentityBlueprintPrincipal.Create [Bêta]
  • AgentIdentity.Read.All [Bêta]
  • AgentIdentity.DeleteRestore.All [Bêta]
  • AgentRegistration.ReadWrite.All
  • Application.Read.All
  • User.Read

Symptôme : la validation échoue même si vous avez ajouté des autorisations.

Cause principale : vous n’avez pas accordé le consentement d’administrateur, ou vous l’avez accordé incorrectement.

Solution : dans l’enregistrement de votre application dans le centre d’administration Microsoft Entra, allez dans Autorisations d’API et sélectionnez Accorder le consentement d’administrateur pour [Votre locataire]. Vérifiez que toutes les autorisations affichent des coches vertes sous le statut.

Symptôme : a365 setup alll’outil affiche « Consentement d’application délégué accordé avec succès », mais échoue immédiatement lors de la création du blueprint avec :

Admin consent has not been granted for this application.
Share this URL with an Application Administrator or Global Administrator to grant consent:
  https://login.microsoftonline.com/<tenant-id>/v2.0/adminconsent?client_id=<client-app-id>

Cause première : votre locataire possède déjà un enregistrement oauth2PermissionGrant pour votre application cliente personnalisée (issu d’une exécution partielle précédente ou d’une action antérieure « Octroyer le consentement d’administrateur » dans le centre d’administration Microsoft Entra pour d’autres portées), mais cet enregistrement ne contient pas la portée requise (AgentIdentityBlueprint.ReadWrite.All). Le CLI détecte l’absence de portée requise et affiche une URL de consentement pour qu’un administrateur puisse finaliser l’octroi du consentement.

Solution :

Partagez l’URL de consentement affichée dans la sortie d’erreur avec un Administrateur d’application ou un administrateur général. Cette URL ressemble à ce qui suit :

https://login.microsoftonline.com/<tenant-id>/v2.0/adminconsent?client_id=<client-app-id>

Après que l’administrateur ait donné son consentement, relancez a365 setup all --agent-name <name>.

Si vous disposez des droits d’administrateur, vous pouvez ouvrir l’URL directement dans un navigateur pour accorder le consentement sans attendre.

Type de permission incorrect

Symptôme : échec du CLI avec des erreurs d’authentification ou des erreurs de refus d’autorisation.

Cause profonde : vous avez ajouté permissions d’application au lieu de permissions déléguées.

Ce tableau décrit les différents types de permissions.

Type d’autorisation Utilisation Comment Agent 365 CLI l’utilise
Délégué (« Étendue ») L’utilisateur se connecte de manière interactive Le CLI Agent 365 utilise cette option : vous vous authentifiez, le CLI agit en votre nom.
Application (Rôle) Le service s’exécute sans utilisateur Ne pas utiliser - Uniquement pour les services en arrière-plan/démons

Pourquoi délégué ?

  • Vous vous connectez de manière interactive (par le navigateur)
  • Le CLI effectue des actions en votre nom (les journaux d’audit montrent votre identité)
  • Plus sécurisé - limité par vos autorisations réelles
  • Assure la responsabilité et la conformité

Solution :

  1. Accédez au centre d’administration Microsoft Entra>Inscriptions d’applications> Votre application >Autorisations de l’API
  2. Supprimez toutes les autorisations d’application. Ces autorisations apparaissent comme Application dans la colonne Type.
  3. Ajoutez les mêmes autorisations en tant qu’autorisations déléguées.
  4. Accorder à nouveau un consentement d’administrateur

Symptôme : vous avez utilisé l’option B : l’API Microsoft Graph (pour les autorisations bêta) pour ajouter des autorisations bêta, mais elles disparaissent après avoir sélectionné Accorder le consentement administrateur dans le centre d’administration Microsoft Entra.

Cause principale : le centre d’administration Microsoft Entra n’affiche pas les autorisations bêta dans l’interface. Lorsque vous sélectionnez Accorder le consentement de l’administrateur, le portail accorde le consentement uniquement pour les autorisations visibles et écrase le consentement accordé par l’API.

Pourquoi cela se produit :

  1. Vous utilisez l’API Graph (option B) pour ajouter les sept permissions, y compris les autorisations bêta.
  2. L’appel API consentType: "AllPrincipals"accorde déjà le consentement administrateur à l’échelle du locataire.
  3. Vous allez dans le centre d’administration Microsoft Entra et ne voyez qu’un sous-ensemble de permissions, car les permissions bêta sont invisibles dans le portail.
  4. Vous sélectionnez Accorder le consentement administrateur en pensant que vous en avez besoin.
  5. Le centre d’administration Microsoft Entra remplace votre consentement accordé via l’API avec seulement les autorisations visibles.
  6. Vos permissions bêta sont maintenant supprimées.

Solution :

  • Ne donnez pas le consentement administrateur dans le centre d’administration Microsoft Entra après avoir utilisé la méthode API : la méthode API accorde déjà le consentement administrateur.
  • Si vous supprimez accidentellement les permissions bêta, relancez l’Option B Étape 3 (accorder le consentement administrateur via l’API Graph) pour les restaurer. Si vous recevez une erreur Request_MultipleObjectsWithSameKeyValue, suivez les étapes pour mettre à jour les permissions déléguées.
  • Pour vérifier que les sept autorisations sont répertoriées, vérifiez le champ scope dans la réponse POST ou PATCH.

Application non trouvée lors de la validation

Symptôme : Rapports Application not found ou Invalid client ID erreurs de CLI.

Solution :

  1. Assurez-vous d’avoir copié l’ID d’application (client) au format GUID, et non l’ID de l’objet :

    • Accédez au centre d’administration Microsoft Entra>inscriptions d’applications>>Vue d’ensemble de votre application
    • Copiez la valeur sous Identifiant d’application (client)
    • Le format doit être : xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

  2. Vérifiez que l’application existe dans votre locataire :

    # Sign in to the correct tenant
az login

# List your app registrations
az ad app list --display-name "<The display name of your app>"

Comment enregistrer une application dans Microsoft Entra ID.

  • Last updated on