Questions fréquemment posées sur le GDAP

Rôles appropriés : tous les utilisateurs intéressés dans l’Espace partenaires

Les autorisations d’administration déléguées granulaires (GDAP) permettent aux partenaires d’accéder aux charges de travail de leurs clients d’une manière plus précise et limitée dans le temps, ce qui peut aider à résoudre les problèmes de sécurité des clients.

Avec GDAP, les partenaires peuvent fournir davantage de services aux clients qui peuvent être mal à l’aise avec les niveaux élevés d’accès aux partenaires.

GDAP aide également les clients qui ont des exigences réglementaires pour fournir uniquement un accès au moins privilégié aux partenaires.

Configuration des GDAP

Qui pouvez demander une relation GDAP ?

Une personne disposant du rôle d’agent Administration au sein d’une organisation partenaire peut créer une demande de relation GDAP.

Une demande de relation GDAP expire-t-elle si le client n’effectue aucune action ?

Oui. Les demandes de relation GDAP expirent après 90 jours.

Puis-je créer une relation GDAP avec un client permanent ?

Non. Les relations GDAP permanentes avec les clients ne sont pas possibles pour des raisons de sécurité. La durée maximale d’une relation GDAP est de deux ans. Vous pouvez définir l’extension automatique sur Activé pour étendre une relation d’administrateur de six mois, jusqu’à ce qu’elle se termine ou que l’extension automatique soit définie sur Désactivé.

Une relation GDAP avec un autorenew/auto-réenrend client peut-elle s’étendre ?

Oui. Une relation GDAP peut s’étendre automatiquement de six mois jusqu’à ce qu’elle se termine ou que l’extension automatique soit définie sur Désactivé.

Que dois-je faire lorsque la relation GDAP avec un client expire ?

Si la relation GDAP avec votre client expire, demandez à nouveau une relation GDAP.

Vous pouvez utiliser l’analytique des relations GDAP pour suivre les dates d’expiration des relations GDAP et préparer leur renouvellement.

Comment un client peut-il étendre ou renouveler une relation GDAP ?

Pour étendre ou renouveler une relation GDAP, le partenaire ou le client doit définir l’extension automatique sur Activé.

Un GDAP actif peut-il bientôt être mis à jour pour s’étendre automatiquement ?

Oui, si LE GDAP est actif, il peut être étendu.

Quand l’extension automatique s’étend-elle en action ?

Supposons qu’un GDAP est créé pendant 365 jours avec l’extension automatique définie sur Activé. Le 365e jour, la date de fin sera mise à jour efficacement d’ici 180 jours.

Les e-mails sont-ils envoyés lorsque l’extension automatique est activée/désactivée ?

Aucun e-mail n’est envoyé au partenaire et au client.

Un GDAP créé avec PLT (Partner Led Tool), MLT (Microsoft Led Tool), l’interface utilisateur de l’Espace partenaires, l’API Espace partenaires peut-elle être étendue automatiquement ?

Oui, n’importe quel GDAP actif peut être étendu automatiquement.

Le consentement du client est-il nécessaire de définir l’extension automatique sur les GDAP actifs existants ?

Non, le consentement du client n’est pas nécessaire pour définir l’extension automatique sur Activé sur un GDAP actif existant.

Les autorisations granulaires doivent-ils être réaffectées aux groupes de sécurité après l’extension automatique ?

Non, les autorisations granulaires affectées aux groupes de sécurité continuent comme c’est le cas.

Une relation d’administrateur avec le rôle Global Administration istrator peut-elle être étendue automatiquement ?

Non, la relation d’administration avec le rôle Global Administration istrator ne peut pas être étendue automatiquement.

Pourquoi ne puis-je pas voir la page Relations granulaires expirées dans l’espace de travail Clients ?

La page Relations granulaires arrivant à expiration dans les GDAPs expire sur différentes chronologie, permet de mettre à jour un ou plusieurs GDAPs pour l’extension automatique (activer/désactiver) est disponible uniquement pour les utilisateurs partenaires disposant de rôles global Administration istrateurs et Administration Agent.

Si une relation GDAP expire, les abonnements existants du client sont-ils affectés ?

Non. Aucun changement n’est apporté aux abonnements existants d’un client quand une relation GDAP expire.

Comment un client peut-il réinitialiser son mot de passe et son appareil MFA s’il est verrouillé hors de son compte et ne peut pas accepter une demande de relation GDAP d’un partenaire ?

Reportez-vous à La résolution des problèmes d’authentification multifacteur Microsoft Entra et ne pouvez pas utiliser l’authentification multifacteur Microsoft Entra pour vous connecter aux services cloud après avoir perdu votre téléphone ou le numéro de téléphone modifié pour obtenir des conseils.

Quels rôles un partenaire a-t-il besoin pour réinitialiser un mot de passe administrateur et un appareil MFA si un administrateur client est verrouillé hors de son compte et ne peut pas accepter une demande de relation GDAP d’un partenaire ?

Le partenaire doit demander le rôle Administrateur d’authentification privilégié Microsoft Entra lors de la création du premier GDAP pour pouvoir réinitialiser le mot de passe et la méthode d’authentification d’un utilisateur (administrateur ou non administrateur). Le rôle d’authentification privilégiée Administration istrator fait partie des rôles configurés par MLT (Microsoft Led Tool) et est prévu pour être disponible avec le GDAP par défaut pendant le flux Créer un client (prévu pour septembre).

Le partenaire peut avoir l’administrateur du client à essayer de réinitialiser le mot de passe. Par précaution, le partenaire doit configurer la réinitialisation de mot de passe en libre-service (SSPR) pour ses clients. Reportez-vous à Autoriser les utilisateurs à réinitialiser leurs propres mots de passe.

Qui reçoit un e-mail de notification d’arrêt de relation GDAP ?

Au sein d’une organisation partenaire, les personnes disposant du rôle d’agent Administration reçoivent une notification d’arrêt.

Au sein d’une organisation cliente , les personnes disposant du rôle d’administrateur général reçoivent une notification d’arrêt.

Puis-je voir quand un client supprime LE GDAP dans les journaux d’activité ?

Oui. Les partenaires peuvent voir quand un client supprime le GDAP dans les journaux d’activité de l’Espace partenaires.

Dois-je créer une relation GDAP avec tous mes clients ?

Non. GDAP est une fonctionnalité facultative pour les partenaires qui souhaitent gérer les services de leurs clients de manière plus précise et limitée dans le temps. Vous pouvez choisir les clients avec lesquels vous souhaitez créer une relation GDAP.

Si j’ai plusieurs clients, dois-je avoir plusieurs groupes de sécurité pour ces clients ?

La réponse dépend de la façon dont vous souhaitez gérer vos clients.

• Si vous souhaitez que vos utilisateurs partenaires puissent gérer tous les clients, vous pouvez placer tous vos utilisateurs partenaires dans un groupe de sécurité et qu’un groupe peut gérer tous vos clients.

• Si vous préférez avoir différents utilisateurs partenaires gérant différents clients, affectez ces utilisateurs partenaires à des groupes de sécurité distincts pour l’isolation des clients.

Les revendeurs indirects peuvent-ils créer des demandes de relation GDAP dans l’Espace partenaires ?

Oui. Les revendeurs indirects (et les fournisseurs indirects et les partenaires de facturation directe) peuvent créer des demandes de relation GDAP dans l’Espace partenaires.

Pourquoi un utilisateur partenaire avec GDAP n’a-t-il pas accès à une charge de travail en tant qu’AOBO (Administration Au nom de) ?

Dans le cadre de la configuration de GDAP, vérifiez que les groupes de sécurité créés dans le locataire partenaire avec les utilisateurs partenaires sont sélectionnés. Vérifiez également que les rôles Microsoft Entra souhaités sont attribués au groupe de sécurité. Reportez-vous à Attribuer des rôles Microsoft Entra.

Quelle est l’étape suivante recommandée si la stratégie d’accès conditionnel définie par le client bloque tous les accès externes, y compris l’accès du fournisseur de solutions Cloud (AOBO) au locataire du client ?

Les clients peuvent désormais exclure les fournisseurs de services cloud de la stratégie d’accès conditionnel afin que les partenaires puissent passer au GDAP sans être bloqués.

Inclure des utilisateurs : cette liste d’utilisateurs inclut généralement tous les utilisateurs qu’une organisation cible dans une stratégie d’accès conditionnel.

Les options suivantes sont disponibles pour inclure lors de la création d’une stratégie d’accès conditionnel :

• Sélection de l’option Utilisateurs et groupes
  • Utilisateurs invités ou externes (préversion)
    • Cette sélection fournit plusieurs choix qui peuvent être utilisés pour cibler des stratégies d’accès conditionnel à des types d’utilisateurs invités ou externes spécifiques et à des locataires spécifiques contenant ces types d’utilisateurs. Il existe plusieurs types d’utilisateurs invités ou externes qui peuvent être sélectionnés, et plusieurs sélections peuvent être effectuées :
      • Les utilisateurs du fournisseur de services, par exemple un fournisseur de solutions Cloud (CSP).
    • Un ou plusieurs locataires peuvent être spécifiés pour les types d’utilisateurs sélectionnés, ou vous pouvez spécifier tous les locataires.

Accès partenaire externe : les stratégies d’accès conditionnel qui ciblent des utilisateurs externes peuvent interférer avec l’accès au fournisseur de services, par exemple des privilèges d’administrateur délégué granulaires. Pour plus d’informations, consultez Présentation des privilèges d’administrateur délégué granulaires (GDAP). Pour les stratégies destinées à cibler les locataires du fournisseur de services, utilisez le type d’utilisateur externe Utilisateur du fournisseur de services disponible dans les options de sélection Utilisateurs invités ou externes.

Exclure les utilisateurs : lorsque les organisations incluent et excluent un utilisateur ou un groupe, l’utilisateur ou le groupe est exclu de la stratégie, car une action d’exclusion remplace une action include dans la stratégie.

Les options suivantes sont disponibles pour exclure lors de la création d’une stratégie d’accès conditionnel :

• Utilisateurs invités ou externes
  • Cette sélection fournit plusieurs choix qui peuvent être utilisés pour cibler des stratégies d’accès conditionnel à des types d’utilisateurs invités ou externes spécifiques et à des locataires spécifiques contenant ces types d’utilisateurs. Il existe plusieurs types d’utilisateurs invités ou externes qui peuvent être sélectionnés, et plusieurs sélections peuvent être effectuées :
    • Utilisateurs de fournisseurs de services, par exemple un fournisseur de solutions cloud (CSP)
  • Un ou plusieurs locataires peuvent être spécifiés pour les types d’utilisateurs sélectionnés, ou vous pouvez spécifier tous les locataires.

Pour plus d’informations, consultez l’article suivant :

• Expérience de l’API Graph : API bêta avec les nouvelles informations de type d’utilisateur externe
• Stratégie d’accès conditionnel
• Accès conditionnel aux utilisateurs externes

Ai-je besoin d’une relation GDAP pour créer des tickets de support bien que je dispose d’un support Premier pour les partenaires ?

Oui, quel que soit le plan de support dont vous disposez, le rôle le moins privilégié pour les utilisateurs partenaires afin de pouvoir créer des tickets de support pour leur client est l’administrateur du support technique du service.

Le GDAP dans l’état En attente d’approbation peut-il être arrêté par le partenaire ?

Non, le partenaire ne peut pas mettre fin à un GDAP dans l’état En attente d’approbation. Il expirerait dans 90 jours si le client n’a aucune action.

Une fois qu’une relation GDAP est terminée, puis-je réutiliser le même nom de relation GDAP pour créer une relation ?

Seulement après 365 jours (propre-up) après l’arrêt ou l’expiration de la relation GDAP, vous pouvez réutiliser le même nom pour créer une relation GDAP.

GDAP API

Les API sont-elles disponibles pour créer une relation GDAP avec les clients ?

Pour plus d’informations sur les API et le GDAP, consultez la documentation du développeur de l’Espace partenaires.

Puis-je utiliser les API GDAP bêta pour la production ?

Oui. Nous vous recommandons d’utiliser les API GDAP bêta pour la production et passer ultérieurement aux API v.1 lorsqu’ils deviennent disponibles.

Bien qu’il existe un avertissement, « L’utilisation de ces API dans les applications de production n’est pas prise en charge », que les instructions génériques concernent n’importe quelle API bêta sous Graph et ne s’appliquent pas aux API graph GDAP bêta.

Puis-je créer plusieurs relations GDAP avec différents clients à la fois ?

Oui. Les relations GDAP peuvent être créées à l’aide d’API, ce qui permet aux partenaires de mettre à l’échelle ce processus. Toutefois, la création de plusieurs relations GDAP n’est pas disponible dans l’Espace partenaires. Pour plus d’informations sur les API et le GDAP, consultez la documentation du développeur de l’Espace partenaires.

Plusieurs groupes de sécurité peuvent-ils être affectés dans une relation GDAP à l’aide d’un appel d’API ?

L’API fonctionne pour un groupe de sécurité à la fois, mais vous pouvez mapper plusieurs groupes de sécurité à plusieurs rôles dans l’Espace partenaires.

Comment puis-je demander plusieurs autorisations de ressources pour mon application ?

Effectuez des appels individuels pour chaque ressource. Lorsque vous effectuez une requête POST unique, transmettez une seule ressource et ses étendues correspondantes.

Par exemple, pour demander des autorisations pour les deux https://graph.windows.net/Directory.AccessAsUser.All et https://graph.microsoft.com/Organization.Read.All, effectuez deux demandes différentes, une pour chacune d’elles.

Comment puis-je trouver l’ID de ressource d’une ressource donnée ?

Utilisez le lien fourni pour rechercher le nom de la ressource : vérifiez les applications Microsoft internes dans les rapports de connexion - Active Directory. Exemple :

Pour rechercher l’ID de ressource (exemple : 0000003-0000-0000-c000-000000000000000000) graph.microsoft.com :

Que dois-je faire si je rencontre l’erreur « Request_UnsupportedQuery » avec le message : « Clause de filtre de requête non prise en charge ou non valide spécifiée pour la propriété « appId » de la ressource « ServicePrincipal » ?

Cette erreur se produit généralement lorsqu’un identificateur incorrect est utilisé dans le filtre de requête.

Pour le résoudre, vérifiez que vous utilisez la propriété enterpriseApplicationId avec l’ID de ressource approprié, et non le nom de la ressource.

• Demande incorrecte

  Pour enterpriseApplicationId, n’utilisez pas de nom de ressource comme graph.microsoft.com.

  

• Demande correcte

  Au lieu de cela, pour enterpriseApplicationId, utilisez l’ID de ressource, tel que 00000003-0000-0000-c000-0000000000000000000.

  

Comment puis-je ajouter de nouvelles étendues à la ressource d’une application qui a déjà été consentée dans le locataire client ?

Exemple : Précédemment, dans graph.microsoft.com ressource, seule l’étendue « profil » a été accordée. Maintenant, nous voulons ajouter un profil et user.read également.

Pour ajouter de nouvelles étendues à une application précédemment consentée :

1. Utilisez la méthode DELETE pour révoquer le consentement de l’application existant du locataire du client.

2. Utilisez la méthode POST pour créer un consentement d’application avec les étendues supplémentaires.

   Remarque

   Si votre application nécessite des autorisations pour plusieurs ressources, exécutez la méthode POST séparément pour chaque ressource.

Comment faire spécifier plusieurs étendues pour une seule ressource (enterpriseApplicationId) ?

Concaténer les étendues requises à l’aide d’une virgule suivie d’un espace. Exemple : « scope » : « profile, User.Read »

Que dois-je faire si je reçois une erreur « 400 Demande incorrecte » avec le message « Jeton non pris en charge. Impossible d’initialiser le contexte d’autorisation » ?

1. Vérifiez que les propriétés « displayName » et « applicationId » dans le corps de la demande sont exactes et correspondent à l’application que vous essayez de donner votre consentement au locataire du client.

2. Vérifiez que vous utilisez la même application pour générer le jeton d’accès que vous tentez de donner votre consentement au client.

   Exemple : Si l’ID d’application est « 12341234-1234-1234-12341234 », la revendication « appId » dans le jeton d’accès doit également être « 12341234-1234-1234-12341234 ».

3. Vérifiez que l’une des conditions suivantes est remplie :

   • Vous disposez d’un Administration privilège délégué actif (DAP), et l’utilisateur est également membre du groupe de sécurité des agents Administration dans le locataire partenaire.

   • Vous disposez d’une relation Administration Privilège (GDAP) granulaire active avec le locataire client avec au moins l’un des trois rôles GDAP suivants, et vous avez terminé l’attribution d’accès :

     • Global Administration istrator, Application Administration istrator ou Cloud Application Administration istrator Role.
     • L’utilisateur partenaire est membre du groupe de sécurité spécifié dans l’attribution d’accès.

Rôles

Quels rôles GDAP sont nécessaires pour accéder à un abonnement Azure ?

• Pour gérer Azure avec le partitionnement par client (qui est la meilleure pratique recommandée), créez un groupe de sécurité (tel qu’Azure Managers) et imbriquez-le sous Administration agents.

• Pour accéder à un abonnement Azure en tant que propriétaire pour un client, vous pouvez affecter n’importe quel rôle intégré Microsoft Entra (par exemple, les lecteurs d’annuaire, le rôle le moins privilégié) au groupe de sécurité Azure Managers.

  Pour connaître les étapes de configuration d’Azure GDAP, consultez Charges de travail prises en charge par des privilèges d’administrateur délégué granulaires (GDAP).

Existe-t-il des conseils sur les rôles les moins privilégiés que je peux affecter aux utilisateurs pour des tâches spécifiques ?

Oui. Pour plus d’informations sur la façon de restreindre les autorisations d’administrateur d’un utilisateur en affectant des rôles avec privilèges minimum dans Microsoft Entra, consultez Rôles privilégiés minimum par tâche dans Microsoft Entra.

Quel est le rôle le moins privilégié que je peux attribuer au locataire d’un client et être toujours en mesure de créer des tickets de support pour le client ?

Nous vous recommandons d’attribuer le rôle d’administrateur de support du service. Pour plus d’informations, consultez Rôles avec privilèges minimum par tâche dans Microsoft Entra.

Puis-je ouvrir des tickets de support pour un client dans une relation GDAP à partir de laquelle tous les rôles Microsoft Entra ont été exclus ?

Non. Le rôle le moins privilégié pour les utilisateurs partenaires afin de pouvoir créer des tickets de support pour leur client est l’administrateur du support technique du service. Par conséquent, pour pouvoir créer des tickets de support pour le client, un utilisateur partenaire doit être dans un groupe de sécurité et affecté à ce client avec ce rôle.

Où puis-je trouver des informations sur tous les rôles et charges de travail inclus dans GDAP ?

Pour plus d’informations sur tous les rôles, consultez les rôles intégrés Microsoft Entra.

Pour plus d’informations sur les charges de travail, consultez Charges de travail prises en charge par des privilèges d’administrateur délégué granulaires (GDAP).

Quel rôle GDAP donne accès au centre de Centre d'administration Microsoft 365 ?

De nombreux rôles sont utilisés pour Centre d'administration Microsoft 365 Center. Pour plus d’informations, consultez les rôles du centre d’administration Microsoft 365 couramment utilisés.

Puis-je créer des groupes de sécurité personnalisés pour GDAP ?

Oui. Créez un groupe de sécurité, attribuez des rôles approuvés, puis attribuez des utilisateurs de locataire partenaire à ce groupe de sécurité.

Quels rôles GDAP donnent un accès en lecture seule aux abonnements du client et ne permettent donc pas à l’utilisateur de les gérer ?

L’accès en lecture seule aux abonnements du client est fourni par le lecteur global, le lecteur d’annuaire et les rôles de prise en charge du niveau 2 du partenaire.

Quel rôle dois-je attribuer à mes agents partenaires (actuellement Administration agents) si je voudrais qu’ils gèrent le locataire client, mais ne modifient pas les abonnements du client ?

Nous vous recommandons de supprimer les agents partenaires du rôle d’agent Administration et de les ajouter à un groupe de sécurité GDAP uniquement. Ainsi, ils peuvent administrer des services (gestion des services et demandes de service de journalisation, par exemple), mais ils ne peuvent pas acheter et gérer des abonnements (modifier la quantité, annuler, planifier des modifications, etc.).

Que se passe-t-il si un client accorde des rôles GDAP à un partenaire, puis supprime des rôles ou interrompt la relation GDAP ?

Les groupes de sécurité affectés à la relation perdent l’accès à ce client. La même chose se produit si un client met fin à une relation DAP.

Un partenaire peut-il continuer à effectuer des transactions pour un client après avoir supprimé toute relation GDAP avec le client ?

Oui, la suppression des relations GDAP avec un client n’arrête pas la relation de revendeur des partenaires avec le client. Les partenaires peuvent toujours acheter des produits pour le client et gérer le budget Azure et d’autres activités connexes.

Certains rôles dans ma relation GDAP avec mon client peuvent-ils avoir plus de temps à expiration que d’autres ?

Non. Tous les rôles d’une relation GDAP ont le même temps d’expiration : durée choisie lors de la création de la relation.

Ai-je besoin de GDAP pour répondre aux commandes des clients nouveaux et existants dans l’Espace partenaires ?

Non. Vous n’avez pas besoin de GDAP pour remplir les commandes pour les clients nouveaux et existants. Vous pouvez continuer à utiliser le même processus pour répondre aux commandes client dans l’Espace partenaires.

Dois-je attribuer un rôle d’agent partenaire à tous les clients ou puis-je attribuer un rôle d’agent partenaire à un seul client ?

Les relations GDAP sont par client. Vous pouvez avoir plusieurs relations par client. Chaque relation GDAP peut avoir des rôles différents et utiliser différents groupes Microsoft Entra au sein de votre locataire CSP.

Dans l’Espace partenaires, l’attribution de rôle fonctionne au niveau de la relation client-à-GDAP. Si vous souhaitez attribuer des rôles multicustomer, vous pouvez automatiser l’utilisation d’API.

Un utilisateur partenaire peut-il avoir des rôles GDAP et un compte invité ?

Les comptes invités sont pris en charge par GDAP, mais pas avec la relation DAP.

Ai-je besoin de DAP/GDAP pour l’approvisionnement d’abonnements Azure ?

Non, vous n’avez pas besoin de DAP ou DE GDAP pour acheter Azure Plans et approvisionner des abonnements Azure pour un client. Le processus de création d’un abonnement Azure pour un client est documenté à l’adresse Créer un abonnement pour le client d’un partenaire - Microsoft Cost Management + Facturation. Par défaut, le groupe agents Administration dans le locataire du partenaire devient le propriétaire des abonnements Azure approvisionnés pour le client. Connectez-vous au Portail Azure à l’aide de votre ID espace partenaires.

Pour approvisionner l’accès au client, vous avez besoin d’une relation GDAP. La relation GDAP doit inclure au minimum le rôle Microsoft Entra des lecteurs d’annuaire. Pour approvisionner l’accès dans Azure, utilisez la page de contrôle d’accès (IAM). Pour AOBO, connectez-vous à l’Espace partenaires et utilisez la page Gestion des services pour approvisionner l’accès au client.

Quels rôles Microsoft Entra sont pris en charge par GDAP ?

GDAP prend actuellement uniquement en charge les rôles intégrés Microsoft Entra. Les rôles Microsoft Entra personnalisés ne sont pas pris en charge.

Pourquoi les administrateurs GDAP + utilisateurs B2B ne peuvent-ils pas ajouter de méthodes d’authentification dans aka.ms/mysecurityinfo ?

Les administrateurs invités GDAP ne peuvent pas gérer leurs propres informations de sécurité sur My Security-Info. Au lieu de cela, ils auront besoin de l’aide de l’administrateur client dans lequel ils sont invités pour toute inscription, mise à jour ou suppression des informations de sécurité. Les organisations peuvent configurer des stratégies d’accès interlocataires pour approuver l’authentification multifacteur à partir du locataire CSP approuvé. Sinon, les administrateurs invités GDAP sont limités aux méthodes inscrites uniquement par l’administrateur des locataires (sms ou voix). Pour plus d’informations, consultez stratégies d’accès entre locataires.

DAP et GDAP

GDAP remplace-t-il DAP ?

Oui. Pendant la période de transition, DAP et GDAP coexistent, les autorisations GDAP étant prioritaires sur les autorisations DAP pour Microsoft 365, Dynamics 365 et les charges de travail Azure .

Puis-je continuer à utiliser DAP ou dois-je transférer tous mes clients vers GDAP ?

DAP et GDAP coexistent pendant la période de transition. Toutefois, GDAP remplacera finalement DAP pour nous assurer que nous fournissons une solution plus sécurisée pour nos partenaires et clients. Il est recommandé de passer vos clients à GDAP dès que possible pour assurer la continuité.

Bien que DAP et GDAP coexistent, y aura-t-il des modifications apportées à la façon dont une relation DAP est créée ?

Il n’existe aucune modification du flux de relation DAP existant alors que DAP et GDAP coexistent.

Quels rôles Microsoft Entra seraient accordés pour le GDAP par défaut dans le cadre de Créer un client ?

Un privilège DAP est actuellement accordé quand un locataire client est créé. À compter du 25 septembre 2023, Microsoft n’accordera plus de DAP pour la création de nouveaux clients et accordera plutôt le GDAP par défaut avec des rôles spécifiques. Les rôles par défaut varient selon le type de partenaire, comme indiqué dans le tableau suivant :

Rôles Microsoft Entra accordés pour le GDAP par défaut	Partenaires de facturation directe	Fournisseurs indirects	Revendeurs indirects	Partenaires de domaine	fournisseurs de Panneau de configuration (CPV)	Advisor	Désactivé du GDAP par défaut (Aucun DAP)
1. Lecteurs d’annuaire. Peut lire les informations d’annuaire de base. Couramment utilisé pour accorder à l’annuaire l’accès en lecture aux applications et aux invités.	x	x	x	x	x
2. Enregistreurs d’annuaires. Peut lire et écrire des informations d’annuaire de base. Pour accorder l’accès aux applications, non destiné aux utilisateurs.	x	x	x	x	x
3. Licence Administration istrateur. Peut gérer les licences de produit pour les utilisateurs et les groupes.	x	x	x	x	x
4. Support du service Administration istrator. Peut lire des informations sur l’intégrité du service et gérer les tickets de support.	x	x	x	x	x
5. Administration istrateur utilisateur. Peut gérer tous les aspects des utilisateurs et groupes, notamment la réinitialisation des mots de passe pour les administrateurs limités.	x	x	x	x	x
6. Rôle privilégié Administration istrateur. Peut gérer les attributions de rôles dans Microsoft Entra et tous les aspects de Privileged Identity Management.	x	x	x	x	x
7. Support technique Administration istrateur. Peut réinitialiser les mots de passe pour les administrateurs non administrateurs et les administrateurs du support technique.	x	x	x	x	x
8. Authentification privilégiée Administration istrateur. Peut accéder aux informations de méthode d’authentification d’affichage, de définition et de réinitialisation pour n’importe quel utilisateur (administrateur ou non administrateur).	x	x	x	x	x
9. Application cloud Administration istrator. Peut créer et gérer tous les aspects des inscriptions d’applications et des applications d’entreprise, à l’exception du proxy d’application.	x	x		x	x
10. Application Administration istrator. Peut créer et gérer tous les aspects des inscriptions d’applications et des applications d’entreprise.	x	x		x	x
11. Lecteur global. Peut lire tout ce qu’un administrateur général peut, mais ne peut rien mettre à jour.	x	x	x	x	x
12. Fournisseur d’identité externe Administration istrateur. Peut gérer la fédération entre les organisations Microsoft Entra et les fournisseurs d’identité externes.				x
13. Nom de domaine Administration istrateur. Peut gérer les noms de domaine dans le cloud et localement.				x

Comment le GDAP fonctionnera-t-il avec Privileged Identity Management dans Microsoft Entra ?

Les partenaires peuvent implémenter Privileged Identity Management (PIM) sur un groupe de sécurité GDAP dans le locataire du partenaire pour élever l’accès de quelques utilisateurs à privilèges élevés, juste-à-temps (JIT) pour leur accorder des rôles à privilèges élevés comme les administrateurs de mot de passe avec suppression automatique de l’accès.

Pour activer cette implémentation, l’abonnement à Microsoft Entra ID P2 est requis par PIM gratuitement. Les partenaires Microsoft peuvent se connecter pour obtenir les détails.

Jusqu’en janvier 2023, il était nécessaire que chaque groupe d’accès privilégié (ancien nom de la fonctionnalité PIM pour les groupes ) se trouve dans un groupe assignable de rôle. Cette restriction a été supprimée. Étant donné cela, il est possible d’activer plus de 500 groupes par locataire dans PIM, mais jusqu’à 500 groupes peuvent être assignables à un rôle.

Résumé :

• Les partenaires peuvent utiliser des groupes assignables de rôle et non assignables à un rôle dans PIM. Cela supprime efficacement la limite de 500 groupes/locataires dans PIM.

• Avec les dernières mises à jour, il y aura deux façons d’intégrer un groupe à PIM (UX-wise) : à partir du menu PIM ou du menu Groupes . Quel que soit le mode de choix, le résultat net est le même.

  • La possibilité d’intégrer des groupes assignables/non assignables à un rôle via le menu PIM est déjà disponible.

  • La possibilité d’intégrer des groupes assignables/non assignables à un rôle via le menu Groupes est déjà disponible.

• Pour plus d’informations, consultez Privileged Identity Management (PIM) pour les groupes (préversion) - Microsoft Entra.

Comment DAP et GDAP coexistent-ils si un client achète Microsoft Azure et Microsoft 365 ou Dynamics 365 ?

GDAP est généralement disponible avec prise en charge de tous les services cloud commerciaux Microsoft (Microsoft 365, Dynamics 365, Microsoft Azure et les charges de travail Microsoft Power Platform ). Pour plus d’informations sur la façon dont DAP et GDAP peuvent coexister et comment GDAP est prioritaire, consultez Comment le GDAP est prioritaire sur DAP.

J’ai une grande base de clients (10 000 comptes clients, par exemple). Comment faire transition de DAP à GDAP ?

Cette action peut être effectuée par les API.

Mon partenaire obtiendra-t-il des gains de crédit (PEC) quand je passe du DAP au GDAP ? Y aura-t-il un effet sur partner Administration Link (PAL) ?

Non. Vos gains de PEC ne seront pas affectés lorsque vous passez au GDAP. Il n’y a aucun changement à la PAL avec la transition, ce qui vous permet de continuer à gagner PEC.

Le PEC est-il affecté lorsque DAP/GDAP est supprimé ?

• Si le client d’un partenaire dispose uniquement de DAP et que DAP est supprimé, PEC n’est pas perdu.
• Si le client d’un partenaire dispose d’un DAP et qu’il passe à GDAP pour Bureau et Azure simultanément, et que DAP est supprimé, PEC n’est pas perdu.
• Si le client du partenaire a DAP et qu’il passe à GDAP pour Bureau, mais conservez Azure tel quel (il ne passe pas à GDAP) et DAP est supprimé, PEC ne sera pas perdu, mais l’accès à l’abonnement Azure sera perdu.
• Si un rôle RBAC est supprimé, PEC est perdu, mais la suppression du GDAP ne supprime pas RBAC.

Comment les autorisations GDAP sont-elles prioritaires sur les autorisations DAP alors que DAP et GDAP coexistent ?

Lorsque l’utilisateur fait partie du groupe de sécurité GDAP et du groupe d’agents DAP Administration et que le client a des relations DAP et GDAP, l’accès GDAP est prioritaire au niveau du partenaire, du client et de la charge de travail.

Par exemple, si un utilisateur partenaire se connecte pour une charge de travail donnée et qu’il y a DAP pour le rôle d’administrateur général et GDAP pour le rôle lecteur global, l’utilisateur partenaire obtient uniquement des autorisations de lecteur global.

S’il existe trois clients ayant des attributions de rôles GDAP à un seul groupe de sécurité GDAP (pas Administration agents) :

Client	Relation avec le partenaire
Client 1	DAP (pas GDAP)
Client 2	DAP + GDAP (les deux)
Client 3	GDAP (pas DAP)

Le tableau suivant décrit quand un utilisateur se connecte à un autre locataire client.

Exemple d’utilisateur	Exemple de locataire client	Comportement	Commentaires
Utilisateur 1	Client 1	DAP	Cet exemple est DAP tel qu’il est.
Utilisateur 1	Client 2	DAP	Il n’existe aucune attribution de rôle GDAP au groupe d’agents Administration, ce qui entraîne un comportement DAP.
Utilisateur 1	Client 3	Pas d’accès	Il n’existe aucune relation DAP. Par conséquent, le groupe d’agents Administration n’a pas accès au client 3.
Utilisateur 2	Client 1	DAP	Cet exemple est DAP tel qu’il est
Utilisateur 2	Client 2	GDAP	GDAP est prioritaire sur DAP, car il existe un rôle GDAP affecté à l’utilisateur 2 via le groupe de sécurité GDAP, même si l’utilisateur fait partie du groupe d’agents Administration.
Utilisateur 2	Client 3	GDAP	Cet exemple est un client GDAP uniquement.
Utilisateur 3	Client 1	Pas d’accès	Il n’existe aucune attribution de rôle GDAP au client 1.
Utilisateur 3	Client 2	GDAP	L’utilisateur 3 ne fait pas partie du groupe d’agents Administration, ce qui entraîne un comportement GDAP uniquement.
Utilisateur 3	Client 3	GDAP	Comportement GDAP uniquement

La désactivation du DAP ou la transition vers LE GDAP affectera-t-elle mes avantages de compétence hérités ou les désignations des partenaires solutions que j’ai obtenues ?

DAP et GDAP ne sont pas des types d’association éligibles pour les désignations des partenaires de solutions et la désactivation ou la transition de DAP vers GDAP n’affecte pas votre niveau de désignation des partenaires solutions. Votre renouvellement des avantages de compétence hérités ou des avantages des partenaires solutions n’est pas également affecté.

Accédez aux désignations partenaires des solutions de l’Espace partenaires pour voir quels autres types d’associations partenaires sont éligibles pour les désignations des partenaires solutions.

Comment le GDAP fonctionne-t-il avec Azure Lighthouse ? Est-ce que GDAP et Azure Lighthouse se touchent les uns les autres ?

En ce qui concerne les relations entre Azure Lighthouse et DAP/GDAP, considérez-les comme des chemins parallèles découplés vers des ressources Azure. L’interruption d’une relation ne doit pas impacter l’autre en principe.

• Dans le scénario Azure Lighthouse, les utilisateurs du locataire partenaire ne se connectent jamais au locataire client et n’ont pas d’autorisations Microsoft Entra dans le locataire client. Leurs attributions de rôle RBAC Azure sont également conservées dans le locataire partenaire.

• Dans le scénario GDAP, les utilisateurs du locataire partenaire se connectent au locataire client et l’attribution de rôle RBAC Azure au groupe d’agents Administration se trouve également dans le locataire du client. Vous pouvez bloquer le chemin GDAP (les utilisateurs ne peuvent plus se connecter) alors que le chemin Azure Lighthouse n’est pas affecté. De la même façon, quand vous interrompez la relation Lighthouse (projection), cela n’a aucun impact sur GDAP. Pour plus d’informations, consultez la documentation Azure Lighthouse .

Comment le GDAP fonctionne-t-il avec Microsoft 365 Lighthouse ?

Les fournisseurs de services managés inscrits dans le programme fournisseur de solutions Cloud (CSP) en tant que revendeurs indirects ou partenaires de facturation directe peuvent désormais utiliser Microsoft 365 Lighthouse pour configurer GDAP pour n’importe quel locataire client. Étant donné qu’il existe plusieurs façons pour les partenaires de gérer leur transition vers GDAP, cet Assistant permet aux partenaires Lighthouse d’adopter des recommandations de rôle spécifiques à leurs besoins métier. Il leur permet également d’adopter des mesures de sécurité telles que l’accès juste-à-temps (JIT). Les msps peuvent également créer des modèles GDAP via Lighthouse pour enregistrer et réappliquer facilement les paramètres qui permettent l’accès client le moins privilégié. Pour plus d’informations et pour afficher une démonstration, consultez l’Assistant Installation de Lighthouse GDAP.

Les msps peuvent configurer GDAP pour n’importe quel locataire client dans Lighthouse. Pour accéder aux données de charge de travail du client dans Lighthouse, une relation GDAP ou DAP est requise. Si GDAP et DAP coexistent dans un locataire client, les autorisations GDAP sont prioritaires pour les techniciens MSP dans les groupes de sécurité compatibles GDAP. Pour plus d’informations sur la configuration requise pour Microsoft 365 Lighthouse, consultez Configuration requise pour Microsoft 365 Lighthouse.

Quelle est la meilleure façon de passer à GDAP et de supprimer DAP sans perdre l’accès aux abonnements Azure si j’ai des clients avec Azure ?

Pour ce scénario, il est indispensable d’effectuer les étapes dans cet ordre :

1. Créer une relation GDAP à la fois pour Microsoft 365 et Azure.
2. Attribuez des rôles Microsoft Entra aux groupes de sécurité pour Microsoft 365 et Azure.
3. Configurer GDAP pour qu’il soit prioritaire par rapport à DAP.
4. Supprimer DAP.

Important

Si vous ne suivez pas ces étapes, les agents de Administration existants qui gèrent Azure peuvent perdre l’accès aux abonnements Azure pour le client.

La séquence suivante peut entraîner la perte d’accès aux abonnements Azure :

1. Supprimer DAP.

   Vous ne perdez pas nécessairement l’accès à un abonnement Azure en supprimant DAP. Mais à ce stade, vous ne pouvez pas parcourir l’annuaire du client pour effectuer des attributions de rôles RBAC Azure (par exemple, attribuer un nouvel utilisateur client en tant que RBAC d’abonnement contributeur).

2. Créez une relation GDAP pour Microsoft 365 et Azure ensemble.

   Vous risquez de perdre l’accès à l’abonnement Azure à cette étape dès que GDAP est configuré.

3. Attribuer des rôles Microsoft Entra à des groupes de sécurité pour Microsoft 365 et Azure

   Vous retrouverez l’accès aux abonnements Azure une fois la configuration d’Azure GDAP terminée.

J’ai des clients qui ont des abonnements Azure sans DAP. Si je les déplace vers GDAP pour Microsoft 365, vais-je perdre l’accès aux abonnements Azure ?

Si vous avez des abonnements Azure sans DAP que vous gérez en tant que propriétaire, en ajoutant GDAP pour Microsoft 365 à ce client, vous risquez de perdre l’accès aux abonnements Azure. Pour éviter cela, déplacez le client vers Azure GDAP en même temps que vous déplacez le client vers Microsoft 365 GDAP.

Important

Si ces étapes ne sont pas suivies, les agents de Administration existants qui gèrent Azure peuvent perdre l’accès aux abonnements Azure pour le client.

Un lien de relation unique peut-il être utilisé avec plusieurs clients ?

Non. Les relations, une fois acceptées, ne sont pas réutilisables.

Si j’ai une relation de revendeur avec les clients sans DAP et qui n’ont aucune relation GDAP, puis-je accéder à leur abonnement Azure ?

Si vous avez une relation de revendeur existante avec le client, vous devez toujours établir une relation GDAP pour pouvoir gérer leurs abonnements Azure.

1. Créez un groupe de sécurité (par exemple, Azure Managers) dans Microsoft Entra.
2. Créez une relation GDAP avec le rôle de lecteur d’annuaire.
3. Faites du groupe de sécurité un membre du groupe d’agents Administration.

Une fois cette opération effectuée, vous serez en mesure de gérer l’abonnement Azure de votre client via AOBO. L’abonnement ne peut pas être géré via l’interface CLI/PowerShell.

Puis-je créer un plan Azure pour les clients sans DAP et qui n’ont aucune relation GDAP ?

Oui, vous pouvez créer un plan Azure même s’il n’existe pas de DAP ou DE GDAP avec une relation de revendeur existante ; Toutefois, pour gérer cet abonnement, vous aurez besoin de DAP ou DE GDAP.

Pourquoi la section Détails de l’entreprise dans la page Compte sous Clients n’affiche-t-elle plus les détails lorsque DAP est supprimé ?

À mesure que les partenaires passent du DAP au GDAP, ils doivent s’assurer que les éléments suivants sont en place pour afficher les détails de l’entreprise :

• Relation GDAP active.
• Les rôles Microsoft Entra suivants sont attribués : Global Administration istrator, Directory Reader, Global Reader. Reportez-vous à accorder des autorisations granulaires aux groupes de sécurité.

Pourquoi mon nom d’utilisateur est-il remplacé par « user_somenumber » dans portal.azure.com lorsqu’une relation GDAP existe ?

Lorsqu’un fournisseur de solutions Cloud se connecte à la Portail Azure de son client (portal.azure.come) à l’aide de ses informations d’identification CSP et qu’il existe une relation GDAP, le fournisseur de solutions Cloud remarque que son nom d’utilisateur est « user_ » suivi d’un certain nombre. Il n’affiche pas son nom d’utilisateur réel comme dans DAP. C'est la procédure normale.

Quelles sont les chronologie pour Arrêter DAP et accorder le GDAP par défaut avec la création d’un nouveau client ?

Type de client	Date de disponibilité	Comportement de l’API de l’Espace partenaires (POST /v1/customers) enableGDAPByDefault : true	Comportement de l’API de l’Espace partenaires (POST /v1/customers) enableGDAPByDefault : false	Comportement de l’API de l’Espace partenaires (POST /v1/customers) Aucune modification apportée à la demande ou à la charge utile	Comportement de l’interface utilisateur de l’Espace partenaires
Sandbox	25 septembre 2023 (API uniquement)	DAP = Non. GDAP par défaut = Oui	DAP = Non. GDAP par défaut = Non	DAP = Oui. GDAP par défaut = Non	GDAP par défaut = Oui
Production	10 octobre 2023 (API + interface utilisateur)	DAP = Non. GDAP par défaut = Oui	DAP = Non. GDAP par défaut = Non	DAP = Oui. GDAP par défaut = Non	Opt-in/out disponible : GDAP par défaut
Production	27 novembre 2023 (lancement en disponibilité générale terminé le 2 décembre)	DAP = Non. GDAP par défaut = Oui	DAP = Non. GDAP par défaut = Non	DAP = Non. GDAP par défaut = Oui	Opt-in/out disponible : GDAP par défaut

Les partenaires doivent accorder explicitement des autorisations granulaires aux groupes de sécurité dans le GDAP par défaut.
Depuis le 10 octobre 2023, DAP n’est plus disponible avec les relations de revendeur. Le lien de relation de revendeur de demandes mis à jour est disponible dans l’interface utilisateur de l’Espace partenaires et l’URL de propriété « /v1/customers/relationship requests » du contrat d’API retourne l’URL d’invitation à envoyer à l’administrateur du locataire client.

Un partenaire doit-il accorder des autorisations granulaires aux groupes de sécurité dans le GDAP par défaut ?

Oui, les partenaires doivent accorder explicitement des autorisations granulaires aux groupes de sécurité dans le GDAP par défaut pour gérer le client.

Quelles actions un partenaire avec une relation revendeur peut-il effectuer, mais aucun DAP et aucun GDAP n’est effectué dans l’Espace partenaires ?

Les partenaires disposant d’une relation de revendeur uniquement sans DAP ou GDAP peuvent créer des clients, passer et gérer des commandes, télécharger des clés logicielles, gérer Azure RI. Ils ne peuvent pas afficher les détails de l’entreprise client, ne peuvent pas afficher les utilisateurs ni attribuer de licences aux utilisateurs, ne peuvent pas journaliser les tickets pour le compte des clients et ne peuvent pas accéder aux centres d’administration spécifiques au produit (par exemple, centre d’administration Teams).)

Quelle action un partenaire doit-il effectuer pour passer du DAP au GDAP en ce qui concerne le consentement ?

Pour qu’un partenaire ou un CPV accède à un locataire client et le gère, le principal de service de son application doit être accepté dans le locataire du client. Lorsque DAP est actif, il doit ajouter le principal de service de l’application au Administration Agents SG dans le locataire partenaire. Avec GDAP, le partenaire doit s’assurer que son application est consentée dans le locataire client. Si l’application utilise des autorisations déléguées (Application + Utilisateur) et qu’il existe un GDAP actif avec l’un des trois rôles (Application cloud Administration istrator, Application Administration istrator, API de consentement global Administration istrator) peuvent être utilisés. Si l’application utilise uniquement des autorisations d’application, elle doit être accordée manuellement, soit par le partenaire, soit par le client ayant l’un des trois rôles (Application cloud Administration istrator, Application Administration istrator, Global Administration istrator), à l’aide de l’URL de consentement administrateur à l’échelle du locataire.

Quelle action doit effectuer un partenaire pour une erreur 715-123220 ou des connexions anonymes ne sont pas autorisées pour ce service ?

Si vous voyez l’erreur suivante :

« Nous ne pouvons pas valider votre demande « Créer une nouvelle relation GDAP » pour l’instant. Soyez informé que les connexions anonymes ne sont pas autorisées pour ce service. Si vous pensez que vous avez reçu ce message en erreur, réessayez votre demande. Cliquez pour en savoir plus sur l’action que vous pouvez entreprendre. Si le problème persiste, contactez le support technique et le code de message de référence 715-123220 et ID de transaction : guid. »

Modifiez la façon dont vous vous connectez à Microsoft pour permettre à notre service de vérification d’identité de s’exécuter correctement. Nous pouvons donc nous assurer que votre compte n’a pas été compromis et qu’il est conforme aux réglementations que Microsoft doit respecter.

Choses que vous pouvez faire :

• Effacez le cache de votre navigateur.
• Désactivez la prévention du suivi sur votre navigateur ou ajoutez notre site à votre liste d’exceptions/sécurisées.
• Désactivez tout programme ou service de réseau privé virtuel (VPN) que vous pourriez utiliser.
• Connecter directement à partir de votre appareil local plutôt que via un ordinateur virtuel.

Après avoir essayé ces étapes, vous n’êtes toujours pas en mesure de vous connecter, nous vous suggérons de consulter votre support technique informatique pour case activée vos paramètres pour voir s’ils peuvent vous aider à identifier ce qui provoque le problème. Parfois, le problème se trouve dans les paramètres réseau de votre entreprise, auquel cas votre administrateur informatique doit résoudre le problème par exemple, en mettant en liste sécurisée notre site ou d’autres ajustements de paramètres réseau.

Quelles actions GDAP sont autorisées pour un partenaire désactivé (restreint, suspendu) ?

• Restreint (facture directe) : impossible de créer un nouveau GDAP (relations Administration). Les GDAP existants et leurs attributions de rôles PEUVENT être mis à jour.
• Suspendu (facture directe/fournisseur indirect/revendeur indirect) : impossible de créer un nouveau GDAP. Les GDAP existants et leurs attributions de rôles NE PEUVENT pas être mis à jour.
• Restricted (Direct Bill) + Active (Indirect Reseller) : nouveau GDAP (relations Administration) PEUT être créé. Les GDAP existants et leurs attributions de rôles PEUVENT être mis à jour.

Offres

La gestion des abonnements Azure est-elle incluse dans cette version de GDAP ?

Oui. La version actuelle de GDAP prend en charge tous les produits : Microsoft 365, Dynamics 365, Microsoft Power Platform et Microsoft Azure.