Questions fréquentes sur GDAP

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

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

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 extension automatique sur activé pour étendre une relation d’administrateur de six mois, jusqu’à ce que l’extension automatique soit terminée ou définie sur Désactivé.

Non. La relation GDAP ne prend pas en charge les abonnements achetés via des contrats d’entreprise.

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é.

• Si la relation GDAP avec votre client expire, demander une relation GDAP à nouveau.
• Vous pouvez utiliser analyse des relations GDAP pour suivre les dates d’expiration des relations GDAP et préparer leur renouvellement.

Pour étendre ou renouveler une relation GDAP, un partenaire ou un client doit définir extension automatique sur activé. En savoir plus sur Gérer l’extension automatique GDAP et API.

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

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

Oui. Vous pouvez étendre automatiquement n’importe quel GDAP actif.

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

Non. Les autorisations granulaires affectées aux groupes de sécurité continuent as-is.

Non. Vous ne pouvez pas étendre automatiquement la relation d’administration avec un rôle d’administrateur général.

La page relations granulaires arrivant à expiration est disponible uniquement pour les utilisateurs partenaires avec les rôles Administrateurs généraux et Agent d’administration. Cette page permet de filtrer les GDAPs arrivant à expiration dans différentes chronologies et de mettre à jour l’extension automatique (activer/désactiver) pour un ou plusieurs GDAPs.

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

Reportez-vous à Résoudre les problèmes d’authentification multifacteur Microsoft Entra et Impossible d’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 change pour obtenir des conseils.

Un partenaire doit demander l’administrateur d’authentification privilégié rôle Microsoft Entra lors de la création du premier GDAP.

• Ce rôle permet à un partenaire de réinitialiser un mot de passe et la méthode d’authentification d’un utilisateur administrateur ou non administrateur. Le rôle d’administrateur d’authentification privilégié fait partie des rôles configurés par 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 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. Pour plus d’informations, consultez Permettre aux utilisateurs de réinitialiser leurs propres mots de passe.

• Au sein d’un partenaire organisation, les personnes disposant de l’agent d’administration rôle reçoivent une notification d’arrêt.
• Au sein d’une organisation client, les personnes disposant du rôle administrateur général reçoivent une notification d’arrêt.

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

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.

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.

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.

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.

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électionner des utilisateurs et des 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).
• Vous pouvez spécifier un ou plusieurs locataires pour les types d’utilisateurs sélectionnés, ou vous pouvez spécifier tous les locataires.
• accès aux partenaires externes : 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 l’utilisateur fournisseur de services type d’utilisateur externe disponible dans les options de sélection invité ou externe.
• 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 d’inclusion 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 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. Pour plus d’informations, consultez :
• Expérience de l’API Graph : API bêta avec les nouvelles informations de type d’utilisateur externe
• stratégie d’accès conditionnel
• utilisateurs externes d’accès conditionnel

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.

Non. Le partenaire ne peut pas actuellement mettre fin à un GDAP dans 'état d’approbation en attente de. Il expirerait dans 90 jours si le client n’a aucune action.

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

Oui. Un partenaire peut gérer ses clients entre les régions sans créer de nouveaux locataires partenaires par région client. Elle s’applique uniquement au rôle de gestion des clients fourni par GDAP (Relations d’administration). Le rôle de transaction et les fonctionnalités sont toujours limités à votre territoire autorisé.

Non. Un fournisseur de services ne peut pas faire partie de l’organisation mutualisée, il s’exclue mutuellement.

1. Assurez-vous que GDAP est configuré correctement, notamment la façon dont vous accordez des autorisations pour les groupes de sécurité.
2. Vérifiez que vos autorisations de groupe de sécurité granulaires sont correctes.
3. Pour obtenir de l’aide, reportez-vous au FORUM aux questions Security Copilot.

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

Oui. Nous recommandons aux partenaires d’utiliser les API GDAP bêta pour la production et passer ultérieurement aux API v.1 lorsqu’elles 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.

Oui. Vous pouvez créer des relations GDAP à l’aide d’API, ce qui permet aux partenaires de mettre à l’échelle ce processus. Mais 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 développeur de l’Espace partenaires.

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.

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 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.

Utilisez le lien fourni pour rechercher le nom de la ressource : Vérifier les applications Microsoft internes dans les rapports de connexion - Active Directory. Par exemple, pour rechercher l’ID de ressource 00000003-0000-0000-c000-0000000000000 pour graph.microsoft.com : capture d’écran de

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 correct, et non le nom de la ressource.

• demande incorrecte Pour enterpriseApplicationId, n’utilisez pas de nom de ressource comme graph.microsoft.com.
• Requête correcte À la place, pour enterpriseApplicationId, utilisez l’ID de ressource, tel que 00000003-0000-0000-c000-000000000000000000000.

Par exemple, dans graph.microsoft.com ressource, seule l’étendue « profil » a été accordée. Nous devons maintenant ajouter un profil et user.read. 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.

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

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. Par 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 privilège d’administrateur délégué actif (DAP), et l’utilisateur est également membre du groupe sécurité des agents d’administration dans le locataire partenaire.
• Vous disposez d’une relation active de privilège d’administrateur délégué (GDAP) avec le locataire client avec au moins l’un des trois rôles GDAP suivants, et vous avez terminé l’attribution d’accès :
  • Administrateur général, Administrateur d’application ou Rôle d’administrateur d’application cloud.
  • L’utilisateur partenaire est membre du groupe de sécurité spécifié dans l’attribution d’accès.

• Pour gérer Azure avec le partitionnement par client (qui est la meilleure pratique recommandée), créez un groupe de sécurité (par exemple, Gestionnaires Azure) et l’imbriquer sous les agents d’administration.
• 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, lecteurs d’annuaire, le rôle le moins privilégié) au groupe de sécurité Gestionnaires Azure . 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és granulaires (GDAP).

Oui. Pour plus d’informations sur la restriction des 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.

Nous vous recommandons d’attribuer le rôle d’administrateur de support service. Pour plus d’informations, consultez rôles moins privilégiés par tâche dans Microsoft Entra.

• Pour réduire l’écart entre les rôles Microsoft Entra disponibles dans l’API de l’Espace partenaires et l’interface utilisateur, une liste de neuf rôles est disponible dans l’interface utilisateur de l’Espace partenaires en juillet 2024.
• Sous Collaboration :
  • Administrateur Microsoft Edge
  • Administrateur des visites virtuelles
  • Administrateur d’objectifs Viva
  • Administrateur Viva Pulse
  • Administrateur Yammer
• Sous Identité :
  • Administrateur de gestion des autorisations
  • Administrateur de flux de travail de cycle de vie
• Sous Autre :
  • Administrateur de personnalisation de l’organisation
  • Approbateur de messages organisationnels

Non. Le rôle le moins privilégié pour que les utilisateurs partenaires puissent créer des tickets de support pour leur client est l’administrateur de support 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.

Pour plus d’informations sur tous les rôles, consultez 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és granulaires (GDAP).

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

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é.

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

Nous vous recommandons de supprimer les agents partenaires du rôle de l’agent administrateur 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.).

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.

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.

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.

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 des clients dans l’Espace partenaires.

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’aide d’API.

Les administrateurs invités GDAP ne peuvent pas gérer leurs propres informations de sécurité à Mes informations de sécurité. Au lieu de cela, ils ont besoin de l’assistance 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 interlocataires.

Alignez-vous sur le principe de guiding de Confiance Zéro : Utilisez l’accès minimum aux privilèges:

• Nous vous recommandons d’utiliser un rôle le moins privilégié par les tâches de tâche et les tâches de charge de travail Charges de travail prises en charge par des privilèges d’administrateur délégués granulaires (GDAP) pris en charge par GDAP.
• Quand il est nécessaire de contourner les problèmes connus répertoriés, contactez votre client pour demander un rôle d’administrateur général lié à l’heure.
• Nous n' vous recommandons pas de remplacer le rôle Administrateur général par tous les rôles Microsoft Entra possibles.

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

DAP et GDAP coexistent pendant la période de transition. Toutefois, finalement, GDAP remplace DAP pour nous assurer que nous fournissons une solution plus sécurisée pour nos partenaires et clients. Nous vous recommandons de transférer vos clients vers GDAP dès que possible pour assurer la continuité.

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

DAP est actuellement accordé lorsqu’un nouveau locataire client est créé. Le 25 septembre 2023, Microsoft n’accorde plus de DAP pour la création de nouveaux clients et accorde 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 :

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. Jusqu’à janvier 2023, il était nécessaire que chaque groupe d’accès privilégié (ancien nom de la fonctionnalité PIM pour les groupes) soit dans un groupe . Cette restriction est désormais supprimée . Étant donné cette modification, il est possible d’activer plus de 500 groupes par locataire dans PIM, mais seuls 500 groupes peuvent être assignables à un rôle. Résumé:

• Les partenaires peuvent utiliser des et des groupes non assignables en rôle dans PIM. Cette option supprime efficacement la limite de 500 groupes/tenant dans PIM.
• Avec les dernières mises à jour, il existe deux façons d’intégrer 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.

GDAP est généralement disponible avec prise en charge de tous les services cloud commerciaux Microsoft (Microsoft 365, Dynamics 365, Microsoft Azureet charges de travail microsoft Power Platform). Pour plus d’informations sur la coexistence des autorisations DAP et GDAP, et sur la façon dont GDAP est prioritaire, recherchez ce FAQ sur la Comment les autorisations GDAP sont-elles prioritaires sur les autorisations DAP alors que DAP et GDAP coexistent ? question.

Vous pouvez effectuer cette action avec des API.

Non. Vos gains de PEC ne sont 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.

• 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 Microsoft 365 et Azure simultanément, et que DAP est supprimé, PEC n’est pas perdu.
• Si le client du partenaire dispose d’un DAP et qu’il passe à GDAP pour Microsoft 365, mais conservez Azure as-is (ils ne passent pas à GDAP) et DAP est supprimé, PEC n’est pas perdu, mais l’accès à l’abonnement Azure est perdu.
• Si un rôle RBAC est supprimé, PEC est perdu, mais la suppression de GDAP ne supprime pas RBAC.

Lorsque l’utilisateur fait partie du groupe de sécurité GDAP et du groupe d’agents DAP Admin et 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 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 les autorisations de lecteur global.

S’il existe trois clients ayant des attributions de rôles GDAP à un seul groupe de sécurité GDAP (et non aux agents d’administration) :

Le tableau suivant décrit ce qui se passe lorsqu’un utilisateur se connecte à un autre locataire client.

DAP et GDAP ne sont pas des types d’association éligibles pour les désignations des partenaires solutions. aDisabling ou transition de DAP vers GDAP n’affecte pas votre réalisation des désignations de partenaires solutions. En outre, le renouvellement des avantages de compétence hérités ou des avantages des partenaires solutions n’est pas affecté. Pour afficher les autres types d’associations partenaires éligibles à la désignation Des partenaires solutions, consultez désignations partenaires solutions.

En ce qui concerne la relation entre Azure Lighthouse et DAP/GDAP, considérez-les comme des chemins parallèles découplés vers des ressources Azure. Le départ ne devrait pas affecter l’autre.

• 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 client client. L’attribution de rôle RBAC Azure au groupe d’agents d’administration se trouve également dans le locataire client. Vous pouvez bloquer le chemin GDAP (les utilisateurs ne peuvent plus se connecter) alors que le chemin Azure Lighthouse n’est pas affecté. À l’inverse, vous pouvez séparer la relation Lighthouse (projection) sans affecter LE GDAP. Pour plus d’informations, consultez la documentation Azure Lighthouse.

Fournisseurs de services managés inscrits dans le programme Fournisseur de solutions cloud (CSP) en tant que revendeurs indirects ou facture directe partenaires peuvent désormais utiliser Microsoft 365 Lighthouse pour configurer GDAP pour n’importe quel client 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 Configuration 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.

La séquence appropriée à suivre pour ce scénario est la suivante :

1. Créez une relation GDAP pour Microsoft 365 et Azure.
2. Attribuez des rôles Microsoft Entra aux groupes de sécurité pour Microsoft 365 et Azure.
3. Configurez GDAP pour qu’il soit prioritaire sur DAP.
4. Supprimez DAP.

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

1. Supprimez 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 contributeur RBAC d’abonnement).
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 aux groupes de sécurité pour Microsoft 365 et Azure

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

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

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

Si vous avez une relation de revendeur existante avec le client, vous devez toujours établir une relation GDAP pour 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 lecteur d’annuaire .
3. Faites du groupe de sécurité un membre du groupe agent d’administration . Une fois ces étapes effectuées, vous pouvez gérer l’abonnement Azure de votre client à l’aide d’AOBO. Vous ne pouvez pas gérer l’abonnement par le biais de l’interface CLI/PowerShell.

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. Mais pour gérer cet abonnement, vous avez besoin de DAP ou DE GDAP.

À 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 : Administrateur général, Lecteurs d’annuaires, Lecteur général. Reportez-vous à accorder des autorisations granulaires aux groupes de sécurité.

Lorsqu’un fournisseur de solutions Cloud se connecte au portail Azure de son client (portal.azure.come) à l’aide de ses informations d’identification CSP et qu’une relation GDAP existe, 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 par conception.

Les partenaires doivent explicitement accorder 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.

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

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 ou attribuer des licences aux utilisateurs, ne peuvent pas journaliser les tickets pour le compte des clients et ne peuvent pas accéder et administrer des centres d’administration spécifiques au produit (par exemple, centre d’administration Teams).)

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 sg des agents d’administration 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’un GDAP actif existe avec l’un des trois rôles (Administrateur d’application cloud, Administrateur d’application, Administrateur général) API de consentement peuvent être utilisés. Si l’application utilise uniquement des autorisations d’application, elle doit être consentie manuellement, soit par le partenaire, soit par le client ayant l’un des trois rôles (Administrateur d’application cloud, Administrateur d’application, Administrateur général), en utilisant URL de consentement administrateur à l’échelle du locataire.

Si vous voyez l’erreur suivante :

« Nous ne pouvons pas valider votre demande « Créer une relation GDAP » pour l’instant. Soyez informé que les connexions anonymes ne sont pas autorisées pour ce service. Si vous croyez que vous avez reçu ce message en erreur, réessayez votre demande. Sélectionnez cette option pour en savoir plus sur les actions que vous pouvez effectuer. 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 au service de vérification d’identité de s’exécuter correctement. Il permet de s’assurer que votre compte n’est pas compromis et qu’il est conforme aux réglementations auxquelles Microsoft doit adhérer.

Ce 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 utilisez peut-être.
• Connectez-vous directement à partir de votre appareil local plutôt qu’à l’aide d’une machine virtuelle.

Si, après avoir essayé les étapes précédentes, vous n’êtes toujours pas en mesure de vous connecter, nous vous suggérons de consulter votre support technique informatique pour vérifier 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. Votre administrateur informatique doit résoudre le problème, par exemple, en répertoriant de façon sécurisée notre site ou en effectuant d’autres ajustements de paramètres réseau.

• Restreint (facture directe) : impossible de créer un nouveau GDAP (Relations d’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.
• Restreint (facture directe) + Actif (revendeur indirect) : pour une facture directe restreinte : impossible de créer un nouveau GDAP (Relations d’administration). Les GDAP existants et leurs attributions de rôles PEUVENT être mis à jour. Pour le revendeur indirect actif : nouveau GDAP PEUT être créé, les GDAP existants et leurs attributions de rôles PEUVENT être mises à jour. Lorsque le nouveau GDAP désactivé ne peut pas être créé, le GDAP existant et leurs attributions de rôles ne peuvent pas être mises à jour.

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