Migrer vos applications CPV/CSP pour utiliser des privilèges d’administrateur délégué granulaires

Article
07/04/2024

Rôles appropriés : Administrateur général | Administrateur de la gestion des utilisateurs

Important

Azure Active Directory (Azure AD) Graph est déconseillé depuis le 30 juin 2023. À l’avenir, nous n’effectuons aucun investissement supplémentaire dans Azure AD Graph. Les API Graph Azure AD n’ont pas de contrat SLA ou de maintenance au-delà des correctifs liés à la sécurité. Nous limiterons les investissements dans de nouvelles fonctions et fonctionnalités à Microsoft Graph.

Nous allons mettre hors service Azure AD Graph en étapes incrémentielles afin que vous ayez suffisamment de temps pour migrer vos applications vers les API Microsoft Graph. À une date ultérieure que nous annoncerons, nous bloquerons la création de toutes les nouvelles applications à l’aide d’Azure AD Graph.

Pour plus d’informations, consultez Important : Suppression du module Azure AD Graph et Dépréciation du module PowerShell.

Cet article explique comment mettre à jour vos applications fournisseur de Panneau de configuration (CPV) et de fournisseur de solutions Cloud (CSP) pour utiliser des privilèges d’administrateur délégué granulaires (GDAP). Le modèle GDAP permet d’appliquer les meilleures pratiques de sécurité dans le modèle d’application sécurisé et le modèle d’application Plateforme d’identités Microsoft, notamment en fournissant des droits minimaux et une infrastructure limitée dans le temps.

Comparaison de GDAP avec DAP

Le modèle GDAP remplace le modèle de privilèges d’administrateur délégués (DAP), et il n’est pas rétrocompatible. Le modèle DAP est déconseillé.

Avec le modèle d’agent d’administration DAP, vous pouvez accorder à votre application gérée par votre partenaire un ensemble d’autorisations configurées pour tous vos clients de votre locataire sans révision. Ce processus est appelé préconsent. Ce processus expose le locataire client d’une manière difficile pour un partenaire à gouverner. Il augmente potentiellement les utilisateurs et les tâches non privilégiés vers un contexte privilégié.

Le risque d’utilisation du préconsent est encore plus amplifié, car les partenaires ne peuvent pas examiner ou auditer les consentements. Bien que la page Microsoft Entra Enterprise Application affiche d’autres consentements, elle ne montre pas les applications auxquelles les préconsents ont consenti. Ce comportement hérité ne s’aligne pas sur le concept de droits minimum dans le Plateforme d’identités Microsoft.

Dans le modèle GDAP, le client ou un administrateur disposant d’une relation au nom de l’utilisateur (OBO) consent au client pour permettre aux applications gérées par le partenaire d’utiliser leur locataire. Ce comportement fournit une traçabilité pour le client et s’aligne sur le modèle d’application Plateforme d’identités Microsoft et l’infrastructure de modèle d’application sécurisée.

GDAP ne vous oblige pas à créer une relation ou un groupe de sécurité spécifique pour votre principal de service d’application.

Pour plus d’informations, consultez Utiliser l’infrastructure de modèle d’application sécurisée.

Autorisations d’application et rôles Microsoft Entra utilisateur

Vous pouvez attribuer des autorisations d’applications dans l’ID Microsoft Entra sous l’onglet Autorisations de l’API.

Avec GDAP, vous ne pouvez plus ajouter de rôles Microsoft Entra à une application à l’aide de relations ou par le biais de l’inclusion dans un groupe de sécurité. Les utilisateurs ont des rôles qui sont attribués directement via le Portail Azure ou indirectement par le biais de l’attribution de groupe. Les utilisateurs ne peuvent pas disposer d’autorisations d’application.

Le consentement de l’application est le processus d’un propriétaire de ressource qui accorde l’autorisation à une application cliente d’accéder aux ressources protégées, sous des autorisations spécifiques, pour le compte du propriétaire de la ressource.

Le tableau suivant répertorie les modèles de service d’application qui fonctionnent avec le consentement de l’application.

Modèle d'application	Consentement de l’application	OBO
Application multilocataire uniquement (DAP uniquement, non prise en charge dans GDAP)	Oui	Non
Application multilocataire + utilisateur	Oui	Non
Application multilocataire + utilisateur + OBO	Oui	Nécessite une relation GDAP

Le consentement explicite de l’application uniquement à un locataire client n’est pas pris en charge pour les développeurs d’applications tiers qui utilisent GDAP. Ce consentement d’application uniquement n’est pas compatible avec le contrat de droits minimum limité dans le temps que LE GDAP gère.

L’Espace partenaires fournit une API qui permet à un CPV ou csp de donner son consentement à son application via l’automatisation dans le locataire du client. L’application explicite + le consentement de l’utilisateur est requis pour chaque locataire client.

Le modèle d’application + utilisateur respecte le contrat de droits minimum limité dans le temps que GDAP gère. Pour plus d’informations, consultez l’article suivant :

Cette API nécessite que l’utilisateur partenaire appelant soit membre d’un groupe de sécurité qui a une relation GDAP avec le client/locataire cible. La relation GDAP et le groupe de sécurité associé doivent inclure au moins l’un de ces rôles confirmés :

Administrateur général
Administrateur d’application (remplacé Administrateur de rôle privilégié)
Administrateur d'applications cloud

Remarque

L’utilisation de Privileged Role Administrator n’est plus recommandée.

L’utilisateur partenaire doit également être membre du groupe de sécurité AdminAgents, qui est requis pour appeler les API de l’Espace partenaires.

Les partenaires peuvent fournir automatiquement le consentement à une application en configurant un compte d’administrateur OBO, en définissant des autorisations, en générant un jeton temporaire et en associant le compte à l’utilisateur.

Créez un compte d’utilisateur ou choisissez un compte d’utilisateur existant à utiliser comme compte CPV/CSP OBO (par exemple). AdminOnBehalfOf@contoso.onmicrosoft.com
Créez un groupe de sécurité à associer à la relation GDAP de votre client (par exemple , AdminOnBehalfOfSG).
Ajoutez votre utilisateur OBO (AdminOnBehalfOf@contoso.onmicrosoft.com) au groupe de sécurité GDAP du client (AdminOnBehalfOfSG).
Définissez les paramètres de relation GDAP suivants. Vous les utiliserez plus tard.
- Durée en jours.
- Demandé les rôles Microsoft Entra nécessaires pour l’OBO.
- Lorsque vous souhaitez automatiser le consentement de l’application, comme décrit dans la section précédente. La relation GDAP doit inclure au moins l’une des options suivantes : Administrateur d’application cloud, Administrateur d’application, Administrateur général pour effectuer l’opération de consentement à l’aide de l’API.
Le csp ou CPV crée une inscription d’application multilocataire ou utilise une inscription existante dans le locataire partenaire.

Enregistrez l’ID d’application (par exemple, A5000000-F000-4000-8000-3000000000000000).
Générez et renouvelez le jeton d’actualisation OBO à l’aide de l’application multilocataire + l’identité d’utilisateur AdminOnBehalfOf générée à l’étape 1.

Les exemples suivants montrent comment créer le jeton respectif à l’aide de la connexion interactive à usage unique. Vérifiez que la connexion utilise l’authentification multifacteur (MFA), car le jeton d’actualisation doit être créé via l’authentification multifacteur pour fonctionner pour les scénarios OBO.
Stockez le jeton d’actualisation de votre utilisateur OBO dans un emplacement sécurisé accessible à partir de votre application mutualisée. Azure Key Vault peut être une option, mais n’est pas nécessaire. Pour plus d’informations, consultez la vue d’ensemble d’Azure Key Vault et la documentation de l’API Key Vault.

Vérifiez que le jeton d’actualisation stocké est renouvelé au moins tous les 90 jours pour éviter l’expiration. Vous pouvez le faire dans votre code d’automatisation ou en développant une application ou un script autonome qui renouvelle le jeton. Chaque fois qu’un nouveau jeton d’accès est créé à partir du jeton d’actualisation stocké, un nouveau jeton d’actualisation avec une durée de vie de 90 jours est généré.

Chaque fois que vous devez vous authentifier auprès du client pour les opérations, obtenez le jeton d’actualisation le plus récent de votre magasin sécurisé et utilisez-le pour générer un jeton d’accès (et un nouveau jeton d’actualisation) pour l’authentification.
Pour chaque client qui utilisera votre application mutualisée et pour qui vous souhaitez exécuter des activités via l’administration déléguée, procédez comme suit :
1. Créez une relation GDAP à l’aide des informations définies à l’étape 4.
2. Soumettez la relation GDAP pour approbation.
3. Une fois la relation GDAP active, affectez le groupe de sécurité défini à l’étape 2 avec les rôles Microsoft Entra appropriés définis à l’étape 4.
4. Assurez-vous qu’un administrateur a accordé son consentement pour votre application dans le locataire du client. Pour l’approche de consentement automatique, vous pouvez le faire après l’établissement du GDAP. Pour un consentement manuel, l’administrateur d’un client peut le faire avant la configuration de GDAP.

Remarque

Vous pouvez utiliser le jeton d’actualisation généré à l’étape 6 pour l’authentification par rapport à chaque client. Vous n’avez pas besoin de prendre l’étape 6 pour chaque client séparément. Lorsque vous effectuez des opérations dans un locataire client, vous prenez le jeton initialement généré et échangez-le pour un jeton généré par rapport au client. Cela est possible en raison de la relation/des rôles GDAP et du consentement de l’application.

Pour configurer plusieurs clients à grande échelle, nous vous recommandons de procéder comme suit :

Pour les nouveaux clients où aucun privilège de délégation n’existe, incluez l’un des rôles de consentement requis dans votre demande de relation GDAP initiale (par exemple, Administrateur d’application cloud).

Sinon, si vous préférez la délégation à court terme de privilèges, évaluez si vous pouvez utiliser une deuxième demande de relation GDAP avec une courte durée (par exemple, un jour) à l’aide d’une autorisation qui autorise la délégation de consentement (comme l’administrateur d’application cloud). Cette approche permet de supprimer le rôle plus privilégié après avoir vérifié la fonction de consentement. Vous pouvez supprimer manuellement cette deuxième demande GDAP à tout moment.
Dans les cas de clients où existe un privilège de délégation et que le partenaire dispose d’un DAP, effectuez le consentement automatisé en bloc (par exemple, à l’aide du script new-PartnerCustomerApplicationConsentPowerShell).

Lorsque vous migrez de DAP vers GDAP à l’aide de l’outil de migration en bloc piloté par le partenaire, configurez les rôles respectifs qui permettent au partenaire de donner son consentement pour les clients migrés. Pour les clients qui n’ont que des délégations de rôle GDAP partielles, le partenaire demande au client d’approuver manuellement le rôle Administrateur d’application cloud (ou un rôle similaire dans la liste des prérequis du rôle).

Cette section décrit plus en détail l’application CPV/CSP API + consentement de l’utilisateur dans le client client.

Identifier les applications d’entreprise et les étendues (également appelées autorisations)

Pour chaque application pour laquelle vous envisagez de donner votre consentement, mappez les API et autorisations de l’application à la charge utile JSON. Vous trouverez les détails de votre application dans le Portail Azure en sélectionnant Microsoft Entra ID : Inscriptions d’applications « votre application », puis en sélectionnant l’onglet Autorisations d’API.

Suivez les étapes de vérification des applications Microsoft internes dans les rapports de connexion dans l’ID Microsoft Entra pour filtrer sur les applications Microsoft. Recherchez les API d’application d’entreprise référencées par votre application et obtenez leurs ID d’application spécifiques. Ces ID d’application seront attribués enterpriseApplicationId dans l’exemple JSON suivant.

Les ID suivants proviennent d’exemples d’autorisations d’application :

Nom de l’application	ID d’application == enterpriseApplicationId
Microsoft Entra ID	00000002-0000-0000-c000-000000000000
Microsoft Graph	00000003-0000-0000-c000-000000000000000

Incluez dans la propriété d’étendue les autorisations requises pour chaque API. La propriété d’étendue peut contenir toutes les autorisations (délimitées par des virgules) ou un sous-ensemble d’autorisations configurées sur l’application pour laquelle vous souhaitez fournir le consentement.

Exemple de charge utile JSON :

{
    "applicationId": "57667d41-992a-49b0-99d8-ddf68328373f",
    "applicationGrants": [
        {
            "enterpriseApplicationId":"00000002-0000-0000-c000-000000000000",
            "scope":"Directory.ReadWrite.All"
        },
        {
            "enterpriseApplicationId":"00000003-0000-0000-c000-000000000000",
            "scope":"Directory.ReadWrite.All"
        }
    ]
}

Remarque

Avant d’appeler l’API, vérifiez que le jeton d’authentification créé utilise le même ID d’application pour lequel vous souhaitez donner votre consentement dans le locataire du client. Vous pouvez utiliser un site web populaire tel que jwt.ms pour décoder votre jeton du porteur et vous assurer que vos ID d’application correspondent. Dans le jeton du porteur, "appID":"57667d41-992a-49b0-99d8-ddf68328373f" doit correspondre à la applicationID valeur de la charge utile JSON.

Obtenir des noms conviviaux pour les autorisations et les étendues

Les informations suivantes sont utiles si vous souhaitez découvrir les noms conviviaux des autorisations d’API d’application, comme indiqué dans la section Portail Azure Inscription d’application Microsoft Entra pour une application spécifique.

Obtenir la liste de vos applications

Exécutez graph api get application.

Obtenez la liste des ID d’application et des noms d’affichage. La id valeur est l’ID d’objet de l’application.

https://graph.microsoft.com/v1.0/applications?$select=id,displayName

Obtenez la valeur d’une application, qui contient l’API et les autorisations de requiredResourceAccess votre application comme indiqué dans le Portail Azure. Remplacez {applicationObjectId} par l’ID d’application de l’étape précédente.

https://graph.microsoft.com/v1.0/applications/{applicationObjectId}?$select=requiredResourceAccess](https://graph.microsoft.com/v1.0/applications/{applicationObjectId}?$select=requiredResourceAccess)

Exemple de réponse :

"requiredResourceAccess": [
    {
        "resourceAppId": "00000003-0000-0000-c000-000000000000",
        "resourceAccess": [
            {
                "id": "885f682f-a990-4bad-a642-36736a74b0c7",
                "type": "Scope"
            },
            {
                "id": "e1fe6dd8-ba31-4d61-89e7-88639da4683d",
                "type": "Scope"
            },
            {
                "id": "06da0dbc-49e2-44d2-8312-53f166ab848a",
                "type": "Scope"
            },
            {
                "id": "c5366453-9fb0-48a5-a156-24f0c49a4b84",
                "type": "Scope"
            }
        ]
    }
]

Obtenir un principal de service

Exécutez l’API Graph get servicePrincipal.

Obtenez la valeur d’un principal de oauth2PermissionScopes service spécifique. Remplacez {resourceAppId} par la valeur retournée dans le requiredResourceAccess tableau. (Il peut y en avoir plusieurs.)

https://graph.microsoft.com/v1.0/servicePrincipals?$filter=appid eq '{resourceAppId}'&$select=oauth2PermissionScopes

Recherchez les définitions d’étendue par ID dans la réponse et le nom convivial stocké dans la value propriété.

Exemple de réponse modifiée (réduite pour plus de clarté) :

{
    "adminConsentDisplayName": "Manage Delegated Admin relationships with customers",
    "id": "885f682f-a990-4bad-a642-36736a74b0c7",
    "isEnabled": true,
     "type": "Admin",
    "value": "DelegatedAdminRelationship.ReadWrite.All"
},
{
    "adminConsentDisplayName": "Sign in and read user profile",
    "id": "e1fe6dd8-ba31-4d61-89e7-88639da4683d",
    "isEnabled": true,
    "type": "User",
    "value": "User.Read"
},
{
    "adminConsentDisplayName": "Read directory data",
    "id": "06da0dbc-49e2-44d2-8312-53f166ab848a",
    "isEnabled": true,
    "type": "Admin",
    "value": "Directory.Read.All"
},
{
    "adminConsentDisplayName": "Read and write directory data",
    "id": "c5366453-9fb0-48a5-a156-24f0c49a4b84",
    "isEnabled": true,
    "type": "Admin",
    "value": "Directory.ReadWrite.All"
},

Principaux de sécurité manquants dans un locataire client

L’API de consentement de l’application nécessite que les API d’application (principaux de service) existent dans le locataire du client. Vous pouvez voir un message d’erreur comme l’exemple suivant lorsque vous consentez. Il signale que l’application n’existe pas dans le locataire du client.

« L’application tente d’accéder à un service « c5393580-f805-4401-95e8-94b7a6ef2fc2 » (API de gestion Office 365) pour lequel votre organisation « contosoxyz.onmicrosoft.com » n’a pas de principal de service. Contactez votre administrateur informatique pour passer en revue la configuration de vos abonnements de service ou donner votre consentement à l’application pour créer le principal de service requis. »

L’exemple d’erreur indique que l’API Gestion Office 365 n’est pas installée dans le locataire du client. Pour connaître les prérequis pour vous assurer que le principal de service est installé, consultez Prise en main des API de gestion Office 365.

Pour vérifier qu’un principal de service existe dans le locataire du client, vous pouvez appeler l’API Graph pour servicePrincipals ce locataire.

Pour l’application qui a besoin du consentement dans le locataire du client, vous pouvez interroger le tableau de l’application requiredResourceAccess . Dans ce tableau, pour chaque resourceAppId instance, vous pouvez appeler l’API dans le locataire cible. Remplacez {resourceIDvalue} par la resourceAppId valeur.

https://graph.microsoft.com/v1.0/servicePrincipals?$filter=appid eq '{resourceID value}'&$select=id,appId,appDisplayName

Par exemple :

https://graph.microsoft.com/v1.0/servicePrincipals?$filter=appid eq 'c5393580-f805-4401-95e8-94b7a6ef2fc2'&$select=id,appId,appDisplayName

Il s’agit du résultat si le principal de service est trouvé :

    "value": [
        {
            "id": "6cf71994-a896-4e8a-a7a4-6d64276bf370",
            "appId": "c5393580-f805-4401-95e8-94b7a6ef2fc2",
            "appDisplayName": "Office 365 Management APIs"
        }
    ]

Il s’agit du résultat si le principal de service est introuvable :

    "value": []

Votre résultat détermine votre chemin d’accès : omettre le principal de service, déterminer pourquoi un principal de service est manquant pour un client ou d’autres actions spécifiques à votre entreprise.

Si vous avez le rôle Administrateur général dans le locataire d’un client, vous pouvez donner votre consentement à l’application vous-même. Dans les cas où le client ne souhaite pas approuver le rôle Administrateur général, vous pouvez lui demander d’entrer l’URI dans un navigateur et de donner son consentement manuellement. Une fois le consentement terminé, votre application doit pouvoir s’exécuter avec le client GDAP.

Pour obtenir le consentement de votre application dans le locataire du client, construisez un URI comme suit. Remplacez {customertenant} par le locataire du client. Remplacez {appid} par l’application pour laquelle vous souhaitez fournir le consentement.

https://login.microsoftonline.com/{customertenant}.onmicrosoft.com/adminconsent?client_id={appid}

Entrez l’URI nouvellement construit dans un navigateur web et suivez les invites de connexion et de consentement.

Ressources

Les liens de ressources suivants sont un ordre de lecture suggéré :

Consentement de l’application GDAP
- Authentification de l’Espace partenaires : consentement du partenaire
- API CPV/CSP pour une application : consentement du client
Modèle d’application sécurisé
Plateforme d’identité Microsoft

Partager via

Migrer vos applications CPV/CSP pour utiliser des privilèges d’administrateur délégué granulaires

Comparaison de GDAP avec DAP

Autorisations d’application et rôles Microsoft Entra utilisateur

Identifier les applications d’entreprise et les étendues (également appelées autorisations)

Obtenir des noms conviviaux pour les autorisations et les étendues

Obtenir la liste de vos applications

Obtenir un principal de service

Principaux de sécurité manquants dans un locataire client

Ressources

Commentaires

Ressources supplémentaires

Partager via

Migrer vos applications CPV/CSP pour utiliser des privilèges d’administrateur délégué granulaires

Comparaison de GDAP avec DAP

Autorisations d’application et rôles Microsoft Entra utilisateur

Consentement d’application

Consentement explicite de l’application multilocataire uniquement

Application multilocataire explicite + consentement de l’utilisateur

Utilisation d’un compte d’administrateur pour fournir le consentement pour le compte des utilisateurs dans le modèle d’application sécurisé

API de consentement

Identifier les applications d’entreprise et les étendues (également appelées autorisations)

Obtenir des noms conviviaux pour les autorisations et les étendues

Obtenir la liste de vos applications

Obtenir un principal de service

Principaux de sécurité manquants dans un locataire client

Demander manuellement le consentement de l’application

Ressources

Commentaires

Ressources supplémentaires