Guide de résolution des problèmes de crédit obtenu par le partenaire

Rôles appropriés : Administrateur de gestion des utilisateurs | Agent d’administration | Administrateur de facturation | Agent commercial

Résoudre les problèmes de scénarios courants

Avec la nouvelle expérience commerciale Azure, les partenaires peuvent recevoir des remises via le crédit partenaire gagné (PEC) pour les services gérés. Le PEC n’est accordé qu’aux partenaires disposant d’autorisations éligibles. Découvrez qui est admissible au CEP, comment il est calculé et est versé.

Cet article fournit des conseils de dépannage de base si le PEC n’est pas accordé.

Prérequis

Si vous rencontrez des problèmes avec PEC, tels que l’accès ou les informations manquantes, commencez par vérifier les éléments suivants.

Remarque

Seuls les fournisseurs indirects et les partenaires de facture directe sont éligibles à la PEC.

• Assurez-vous de consulter le fichier de facturation et de rapprochement G (new commerce experience). Le plan Azure et le PEC ne sont pas affichés sur la facture D (héritée) ou le fichier de rapprochement.

• Vérifiez que votre contrat de programme Microsoft AI Cloud Partner est actif.

• Vérifiez que votre offre est éligible. Les offres Azure héritées, les instances réservées Azure, les plans d’économies Azure, les machines virtuelles Azure SPOT et les produits non Microsoft ne sont pas éligibles.

• Vérifiez que vous (ou le revendeur indirect défini en tant que revendeur d’enregistrement sur le plan Azure) disposez d’un rôle Administrateur valide pour le compte (AOBO) ou le rôle de contrôle d’accès en fonction du rôle Azure (Azure RBAC) pour l’abonnement/le groupe de ressources/la ressource. Sinon :

  • Si vous utilisez Azure Lighthouse, assurez-vous que votre PartnerID est lié à au moins un compte d’utilisateur. Vérifiez également qu’il a accès à l’abonnement/au groupe de ressources de ce client.
  • Si vous utilisez une association RBAC Azure, assurez-vous que l’utilisateur a un rôle éligible pour PEC et Azure RBAC défini dans chaque contexte de locataire client.

• Vérifiez si le client a supprimé vos autorisations AOBO. Les autorisations sont définies par défaut lors de l’approvisionnement du plan Azure. S’ils sont supprimés, consultez Rétablir les privilèges d’administrateur pour les abonnements Azure Cloud Solution Provider (CSP) d’un client.

• Veillez à disposer d’un accès administrateur pour la journée entière.

• Vérifiez que vous examinez les colonnes appropriées dans vos fichiers de rapprochement. Pour plus d’informations, consultez facturation du plan Azure : À propos de votre fichier de rapprochement de facture.

Comprendre les scénarios multipartenaires

Pour PEC, il est seulement important que le partenaire de transaction définisse l’une des options d’autorisation disponibles. Pour le modèle indirect, il peut s’agir du fournisseur, du revendeur ou des deux.

La définition d’un AOBO ou d’autres autorisations supplémentaires et la définition d’un RBAC Azure supplémentaire pour les utilisateurs disposant d’autorisations RBAC Azure n’affectent pas le PEC pour le partenaire de transaction.

Dans le tableau suivant, MPN1 est un fournisseur indirect, MPN2 est le revendeur indirect lié à la transaction en tant que revendeur officiel. MPN3 est un autre partenaire CSP (revendeur direct ou autre revendeur) :

Partenaire transacting (BillTo)	RBAC Azure (pour l’utilisateur ou Lighthouse avec un rôle éligible au PEC)	AOBO (rôle éligible au PEC)	PEC
MPN1	MPN1	S/O	Oui
MPN1	S/O	MPN1	Oui
MPN1	MPN2	S/O	Oui
MPN1	S/O	MPN2	Oui
MPN1	MPN3	MPN1	Oui
MPN1	MPN1	MPN3	Oui
MPN1	MPN1	MPN2	Oui
MPN1	MPN2	MPN1	Oui
MPN1	MPN2	MPN3	Oui
MPN1	MPN3	MPN2	Oui
MPN1	MPN3	S/O	Non
MPN1	S/O	MPN3	Non
MPN1	S/O	S/O	Non
MPN1	MPN3	MPN3	Non

Comprendre les transferts d’abonnement Azure

Lorsqu’un partenaire transfère un abonnement Azure depuis ou vers un autre partenaire, aucune autorisation n’est modifiée pour ce transfert.

Ainsi, si AOBO ou un autre modèle d’autorisation a été utilisé avant le transfert, avec des autorisations définies pour le précédent « partenaire de transaction », les autorisations pointent toujours vers le partenaire précédent après le transfert. Mais maintenant, un autre partenaire devient le « partenaire de transaction ».

Pour tous les transferts d’abonnement Azure, il est recommandé que le nouveau partenaire cible ajoute des autorisations, telles qu’Azure RBAC, avant le transfert. Ils peuvent le faire en toute sécurité sans affecter le PEC de l’ancien partenaire jusqu’au transfert.

Comprendre les mises à jour de PartnerID

L’Espace partenaires vous permet de modifier le PartnerID associé à votre inscription CSP. La mise à jour du PartnerID vers un autre ID d’emplacement du programme Microsoft AI Cloud Partner au sein de la même organisation mondiale du Programme Microsoft AI Cloud Partner (un autre ID d’emplacement du programme Microsoft AI Cloud Partner sous le même ID global du programme Microsoft AI Cloud Partner) n’affecte pas le programme PEC.

Lorsque l’ID de partenaire est remplacé par un ID d’emplacement dans une autre organisation du programme Microsoft AI Cloud Partner, toutefois, PEC peut être affecté. Dans ce cas, et lorsque PEC s’avère manquant, nous vous recommandons de contacter le support. Mentionnez que vous avez récemment remappé votre inscription CSP à une autre organisation du programme Microsoft AI Cloud Partner Program.

Vérifier les autorisations d’administrateur au nom de (AOBO)

Lorsqu’un partenaire crée un abonnement au plan Azure pour un client, AOBO est défini sous la forme d’un principal étranger. Le principal étranger hérite des autorisations de propriétaire sur l’abonnement Azure. Les autorisations AOBO signifient qu’un certain groupe dans le locataire de l’Espace partenaires CSP (agents d’administration) hérite des autorisations.

Le principal étranger, comme indiqué dans le Portail Azure, n’inclut pas de détails sur le groupe auquel il est mappé dans le locataire partenaire spécifique.

Lorsque vous affichez le principal étranger dans l’Portail Azure, il affiche un nom de partenaire, tel que « Principal étranger pour « Contoso », mais « Contoso » est uniquement le nom complet du locataire Microsoft Entra du partenaire, et il n’est pas unique.

Utilisez AZ PowerShell ou Azure CLI pour vérifier avec une certitude de 100% que l’AOBO est correctement défini, pointant vers le groupe approprié et dans le locataire CSP approprié.

Étape 1 : identifier les objectID des groupes d’agents du partenaire de transaction

• Par le biais du portail Azure : les partenaires peuvent se connecter au portail Azure dans leur propre locataire et rechercher les groupes respectifs dans les groupes d’ID > Microsoft Entra. ObjectID s’affiche à droite du nom du groupe.

• Par le biais de PowerShell : démarrez PowerShell ( PowerShell local ou Azure Cloud Shell).

Avant d’utiliser Azure Cloud Shell, vous devez configurer un compte de stockage. Ce compte entraîne un faible coût mensuel dans l’abonnement Azure disponible dans le contexte du locataire. Vous pouvez supprimer le partage après les étapes suivantes.

Remarque

Les modules Azure AD et MSOnline PowerShell sont dépréciés depuis le 30 mars 2024. Pour en savoir plus, lisez les informations de dépréciation. Passé cette date, la prise en charge de ces modules est limitée à une assistance de migration vers le SDK et les correctifs de sécurité Microsoft Graph PowerShell. Les modules déconseillés continueront de fonctionner jusqu’au 30 mars 2025.

Nous vous recommandons de migrer vers Microsoft Graph PowerShell pour interagir avec Microsoft Entra ID (anciennement Azure AD). Pour explorer les questions courantes sur la migration, reportez-vous au FAQ sur la migration. Remarque : Les versions 1.0.x de MSOnline peuvent connaître une interruption après le 30 juin 2024.

Vérifiez que les modules suivants sont installés et mis à jour vers la version la plus récente :

• Module AzureAD
• Module AZ PowerShell (non requis pour Cloud Shell)

Si nécessaire, utilisez les éléments suivants cmdlets à partir de windows PowerShell pour installer ces modules :

Install-Module -Name AzureAD -Force

Install-Module -Name Az -AllowClobber -Force

Tout d’abord, connectez-vous au locataire de l’Espace partenaires avec votre compte d’utilisateur de l’Espace partenaires et obtenez les ID d’objet du groupe AdminAgents et HelpdeskAgents :

Connect-AzureAD -TenantDomain CSPtenantname.onmicrosoft.com

Connectez-vous avec vos informations d’identification de l’Espace partenaires :

Interrogez les informations sur les groupes d’agents :

Get-AzureADGroup | Where-Object { $_.DisplayName.Endswith('Agents') }

Le ObjectID des groupes s’affiche avec leurs noms :

Remarque

Si vous n’obtenez pas de résultat, assurez-vous de vous connecter à votre compte Espace partenaires.

Remarque

Les revendeurs indirects ne voient pas de groupe SalesAgents. Cette étape ne doit être effectuée qu’une seule fois, car AOBO dans chaque locataire client utilise les mêmes ID.

Étape 2 : comparer les ObjectID aux objets utilisés par le principal étranger

Il est important d’utiliser TenantID comme valeur pour le paramètre de locataire (plutôt que le nom de domaine du locataire) avec un compte d’utilisateur qui :

• A accès à plusieurs annuaires et locataires, tels que votre compte d’utilisateur de l’Espace partenaires, ou
• A été ajouté en tant qu’invité à plusieurs locataires.

Vous avez donc besoin du TenantID du client.

• Par le biais du portail Azure : vous pouvez obtenir facilement le TenantID à partir de la liste des clients dans l’Espace partenaires. L’ID de locataire est étiqueté Microsoft ID :

  

• Par le biais de PowerShell : connectez-vous à l’abonnement Azure du client avec des informations d’identification valides. Les informations d’identification doivent être autorisées à lire l’abonnement Azure et AzureAD du locataire client :

  Connect-AzAccount -Tenant $CustomerTenantID
  

  • Lisez les attributions de rôles pour le principal étranger des abonnements Azure du client :

  Get-AzRoleassignment | ? {$_.DisplayName -like "Foreign*"}
  

  

  • L’ObjectID résultant doit correspondre à l’ObjectID du groupe AdminAgent ou HelpDeskAgent identifié à l’étape 1.

Résumé

Tous les aspects doivent correspondre pour recevoir le PEC par le biais de l’AOBO :

• L’abonnement Azure du client dispose d’un principal étranger disposant d’une attribution de rôle RBAC Azure éligible.
• L’ObjectID du groupe utilisé par le principal étranger fait référence à l’ObjectID du groupe AdminAgent ou HelpdeskAgent dans le locataire partenaire.
• « Locataire partenaire » signifie le locataire partenaire de facturation directe. Dans le modèle indirect, cela signifie que le fournisseur indirect ou le locataire du partenaire de revendeur indirect.

Exemples de scripts

Cette section contient des exemples de scripts qui peuvent aider à collecter les informations sur plusieurs abonnements et les stocker dans un . Fichier CSV. Ces scripts sont destinés en tant qu’exemples et fournis en l’absence de prise en charge. Bien que les scripts n’apportent pas de modifications dans l’installation, ils doivent être soigneusement testés et la personnalisation peut être nécessaire pour le scénario concret partenaire/client.

• Liste des détails AOBO pour un seul client : cet exemple utilise les modules Microsoft Entra ID et Azure PowerShell.

### Install-Module -Name AzureAD -Force ###
### Install-Module -Name Az -AllowClobber -Force ###
### Variables ####
$CSVname = "c:tempAOBOchecker.csv"
$CustomertenantId = ""
### Get Agent-Groups Object IDs and write to CSV - This step needs to be done with a Partner Center User ###
Connect-AzureAD -TenantDomain $PartnerTenantDomain
$Headers = "GroupName`tObjectID`tPartnerTenantName`tPartnerTenantID" >>$CSVname
$PartnerTenant = Get-AzureADTenantDetail
$groups = Get-AzureADGroup | Where-Object { $_.DisplayName.Endswith('Agents') }
ForEach ($Group in $Groups)
{
$NewLine = $Group.DisplayName + "`t" + $Group.ObjectID + "`t" + $PartnerTenant.DisplayName + "`t" + $PartnerTenant.ObjectID
$NewLine >>$CSVname
}
### Get list of Azure Subscriptions for a customer, get list of Foreign Principals and add them to the same CSV ###
Clear-AzContext -Scope CurrentUser -Force
Connect-AzAccount -Tenant $CustomertenantId
$CustomerTenant = Get-AzureADTenantDetail
$CustomerTenantSubscriptions = Get-AzSubscription -TenantId $CustomertenantId
ForEach ($Subscription in $CustomerTenantSubscriptions)
{
$Roles = Get-AzRoleassignment -Scope /subscriptions/$Subscription | ? {$_.DisplayName -like "Foreign*"}
ForEach ($Role in $Roles)
{
$NewLine = $CustomerTenant.Domain + "`t" + $CustomerTenant.CustomerId + "`t" + $Subscription.Id + "`t" + $Role.DisplayName + "`t" + $Role.ObjectID + "`t" + $Role.RoleDefinitionName
$NewLine >>$CSVname
}
}

• Description des détails AOBO pour plusieurs clients : ce code est destiné à des fins d’illustration uniquement.
  • Obtenez la liste de tous les abonnements des clients CSP et de tous les principaux étrangers et identifiez s’il existe une incompatibilité. Ce code peut également être utilisé pour collecter des informations pour la prise en charge.
  • Vérifiez quels abonnements Azure (droits au plan Azure) ont été vendus et lesquels sont accessibles avec les informations d’identification actuelles.
  • Pour les revendeurs indirects, ce script fonctionne également. Mais tous les abonnements auraient la note « non vendue » même s’ils sont le partenaire d’enregistrement pour cette vente.

### Note - below examples use interactive login experience and aren't suitable for production use ###
### See /partner-center/develop/enable-secure-app-model#powershell for info on how to authenticate to each customer tenant silently using secure app model ###
### Below examples use AzureAD, AZ and Partner Center PowerShell modules ###
### Install-Module -Name AzureAD -Force ###
### Install-Module -Name Az -AllowClobber -Force ###
### Install-Module -Name PartnerCenter -Force ###
### Variables ####
$PartnertenantDomain = "xyz.onmicrosoft.com"
$PartnerTenantID = ""
$CSVname = "c:tempAOBOchecker.csv"
### Get Agent-Groups Object IDs and write to CSV ###
Connect-AzureAD -TenantDomain $PartnerTenantDomain
$Headers = "GroupName`tObjectID`tPartnerTenantName`tPartnerTenantID" >>$CSVname
$PartnerTenant = Get-AzureADTenantDetail
$groups = Get-AzureADGroup | Where-Object { $_.DisplayName.Endswith('Agents') }
ForEach ($Group in $Groups)
{
$NewLine = $Group.DisplayName + "`t" + $Group.ObjectID + "`t" + $PartnerTenant.DisplayName + "`t" + $PartnerTenant.ObjectID
$NewLine >>$CSVname
}
### Get list of CSP Customers, get List of Azure Subscriptions, get list of Foreign Principals and add them to the same CSV ###
Connect-PartnerCenter -TenantID $PartnertenantID
$Customers = Get-PartnerCustomer
$Headers = "`r`nCustomerTenantName`tCustomerTenantID`tSubscriptionId`tForeignPrincipalName`tObjectID`tAzureRBACRole`tTimeChecked`tNotes`tCredentialsUsedForAccessCheck" >>$CSVname
Foreach ($customer in $Customers)
{
$AzurePlanId = Get-PartnerCustomerSubscription -CustomerId $Customer.CustomerId | ? {$_.OfferName -eq "Azure Plan"}
if ($AzurePlanID -eq $null)
{
Write-Host "Customer $($Customer.Name) does not have Azure Plan"
}
else
{
$AzurePlanSubscriptionsSold = Get-PartnerCustomerAzurePlanEntitlement -CustomerId $Customer.CustomerId -SubscriptionId $AzurePlanId.SubscriptionId
}
Clear-AzContext -Scope CurrentUser -Force
Connect-AzAccount -Tenant $Customer.CustomerId
$CurrentUser = Get-azcontext
$CustomerTenantSubscriptionsAccessible = Get-AzSubscription -TenantId $Customer.CustomerId
$SoldAndAccessibleSubscriptions = $AzurePlanSubscriptionsSold | Where {$CustomerTenantSubscriptionsAccessible -Contains $_}
$SoldButNotAccessibleSubscriptions = $AzurePlanSubscriptionsSold | Where {$CustomerTenantSubscriptionsAccessible -notcontains $_}
$NotSoldButAccessibleSubscriptions = $CustomerTenantSubscriptionsAccessible | Where {$AzurePlanSubscriptionsSold -notcontains $_}
ForEach ($Subscription in $SoldAndAccessibleSubscriptions)
{
$Roles = Get-AzRoleassignment -Scope /subscriptions/$Subscription | ? {$_.DisplayName -like "Foreign*"}
ForEach ($Role in $Roles)
{
$CurrentTime = Get-Date -format "dd-MMM-yyyy HH:mm:ss"
$NewLine = $Customer.Domain + "`t" + $Customer.CustomerId + "`t" + $Subscription.Id + "`t" + $Role.DisplayName + "`t" + $Role.ObjectID + "`t" + $Role.RoleDefinitionName + "`t" + $CurrentTime + "`t" + "Access with current credentials and sold as CSP Partner" + "`t" + $CurrentUser.Account.Id
$NewLine >>$CSVname
}
}
ForEach ($Subscription in $SoldButNotAccessibleSubscriptions)
{
$CurrentTime = Get-Date -format "dd-MMM-yyyy HH:mm:ss"
$NewLine = $Customer.Domain + "`t" + $Customer.CustomerId + "`t" + "N/A" + "`t" + "N/A" + "`t" + "N/A" + "`t" + "N/A" + "`t" + $CurrentTime + "`t" + "Sold via CSP, but no access with current credentials" + "`t" + $CurrentUser.Account.Id
$NewLine >>$CSVname
}
ForEach ($Subscription in $NotSoldButAccessibleSubscriptions)
{
$Roles = Get-AzRoleassignment -Scope /subscriptions/$Subscription | ? {$_.DisplayName -like "Foreign*"}
ForEach ($Role in $Roles)
{
$CurrentTime = Get-Date -format "dd-MMM-yyyy HH:mm:ss"
$NewLine = $Customer.Domain + "`t" + $Customer.CustomerId + "`t" + $Subscription.Id + "`t" + $Role.DisplayName + "`t" + $Role.ObjectID + "`t" + $Role.RoleDefinitionName + "`t" + $CurrentTime + "`t" + "Access with current credentials, but not sold as CSP Partner" + "`t" + $CurrentUser.Account.Id
$NewLine >>$CSVname
}
}
}

• La sortie de ce script peut ensuite être mise en forme comme suit :

  

Vérifier les autorisations Azure Lighthouse et le lien d’administration du partenaire Azure (PAL)

À l’instar d’AOBO, Azure Lighthouse permet à des groupes d’utilisateurs du locataire de gestion (partenaire) d’hériter des autorisations déléguées dans l’abonnement Azure du client. La différence est qu’il prend en charge une définition plus granulaire des groupes et des niveaux d’autorisation qu’AOBO.

Pour ce modèle d’autorisation, il est plus facile de vérifier s’il a été correctement configuré à l’aide de l’interface utilisateur du portail Azure. Seul le partenaire peut fournir une vérification complète que la configuration d’Azure Lighthouse est correcte.

Les étapes suivantes décrivent comment identifier les clients auxquels les autorisations de rôle RBAC Azure ont été déléguées de manière permanente et à quels groupes. Ensuite, vous pouvez vérifier si l’utilisateur avec l’association RBAC Azure est membre de ces groupes.

Étape 1 : Vérifier les délégations Lighthouse sur les clients

Vérifiez que les délégations applicables utilisent des rôles RBAC Azure éligibles à la PEC.

• Ouvrez Portail Azure (avec un utilisateur à partir du locataire de gestion du partenaire). Recherchez ensuite « Lighthouse » et sélectionnez Mes clients.

  

• Dans la vue d’ensemble du client, choisissez Délégations sur le côté gauche. Cela ouvre la liste des ressources (abonnements ou groupes de ressources) pour lesquelles l’accès délégué a été fourni :

  

• Ouvrez les délégations dans la colonne de droite sous Attributions de rôles pour voir quel groupe d’utilisateurs dans le partenaire/locataire de gestion hérite de chaque type d’autorisations (voir la colonne Rôle ). Vous pouvez également voir si ces autorisations sont permanentes (voir la colonne « Type d’accès ») :

  

Étape 2 : Vérifier l’appartenance au groupe

Sélectionnez le nom complet du groupe. Pour ce faire, les détails du groupe s’ouvrent. Sélectionnez « Membres » pour contrôler l’utilisateur avec azure RBAC défini et membre du groupe respectif :

Étape 3 – Vérifier si l’utilisateur a configuré Azure PAL

Seul l’utilisateur qui a défini Azure PAL peut vérifier l’attribution Azure PAL. Aucun autre utilisateur admin ne peut le faire. Pour plus d’informations sur la façon dont l’utilisateur peut vérifier si Azure PAL a été défini, que ce soit avec l’interface utilisateur ou PowerShell, consultez Lier un compte Azure à un PartnerID.

Remarque

Azure PAL doit utiliser un PartnerID qui fait partie de la même organisation Microsoft AI Cloud Partner Program que le partenaire de transaction pour cet abonnement Azure. Dans le modèle indirect, il peut s’agir soit du PartnerID du fournisseur, soit du revendeur spécifique attaché à cette vente.

Étape 4 - Vérifier les affectations de groupe à liaison temporelle

Étant donné que l’appartenance au groupe peut ne pas être permanente, vérifiez si le groupe a été activé pour la gestion des accès privilégiés. Regardez où « Accès privilégié » sur le côté gauche sous « Activité » dans les paramètres du groupe. Si la valeur est true, vérifiez si l’utilisateur a une affectation active et le délai de cette affectation.

Remarque

Étant donné que l’affectation « heure de fin » est lorsqu’un utilisateur est automatiquement supprimé du groupe, le PEC est perdu pour les utilisateurs ayant défini RBAC Azure. De même, le PEC ne serait accordé qu’après l’affectation « heure de début ».

Vérifier l’attribution d’un utilisateur individuel et Azure PAL

Dans certains cas, il peut être plus approprié d’utiliser des comptes d’utilisateur individuels disposant d’autorisations sur les abonnements Azure. Ces comptes peuvent être des comptes d’utilisateur invités (à partir de n’importe quel locataire) ou des comptes d’utilisateur créés dans le locataire client ou les principaux de service.

Lorsque vous utilisez des comptes d’utilisateur individuels comme moyen d’obtenir des PEC, la vérification implique l’examen des autorisations attribuées à l’utilisateur dans la gestion des abonnements Azure et la vérification du paramètre RBAC Azure défini correctement par l’utilisateur. Lorsque vous utilisez un principal de service, la vérification du RBAC Azure s’effectue par le biais de PowerShell.

Étape 1 : passer en revue les autorisations dans la gestion des abonnements Azure

• Ouvrez le portail Azure. Vérifiez que vous êtes connecté en tant qu’utilisateur disposant d’un rôle RBAC Azure avec au moins un accès en lecture à l’abonnement en question.

• Recherchez « Abonnements » dans la barre de recherche pour ouvrir les détails de l’abonnement :

  

• Accédez à « Contrôle d’accès (IAM) » dans les détails de l’abonnement. Sélectionnez ensuite « Attributions de rôles » pour passer en revue les utilisateurs qui ont accès à un niveau d’abonnement et si la colonne « Rôle » affiche les rôles RBAC Azure éligibles à la PEC. Si les autorisations ont été définies au niveau d’un groupe de ressources, la même vue « Contrôle d’accès (IAM) » est également disponible au sein d’un groupe de ressources.

Remarque

Les autorisations peuvent également être accordées à un groupe d’utilisateurs où l’appartenance au groupe de l’utilisateur disposant d’un jeu RBAC Azure doit également être vérifiée.

Étape 2 : vérifier que les autorisations sont permanentes et qu’aucune affectation de refus ne s’applique

Bien qu’il puisse sembler que les utilisateurs aient accès, leurs autorisations peuvent être temporaires ou bloquées par le biais d’attributions Refuser.

L’utilisation de l’attribution de rôle Azure RBAC Azure Privileged Identity Management (PIM) peut être liée au temps. Bien que vous voyiez des utilisateurs disposant d’autorisations, ils n’existent peut-être qu’une courte durée. Pour vérifier que l’attribution de rôle RBAC Azure est permanente, vérifiez l’administration PIM dans Portail Azure. Plus précisément, vérifiez où les stratégies PIM gèrent les ressources Azure dans l’abonnement et si l’utilisateur est soumis à des stratégies.

En outre, la liste des autorisations peut indiquer à l’utilisateur des autorisations sur l’abonnement, mais il peut y avoir des affectations de refus qui empêchent toujours l’utilisateur d’accéder à quelque chose. Dans « Contrôle d’accès (IAM) », sélectionnez l’onglet Refuser l’affectation pour voir si les affectations de refus s’appliquent :

Remarque

Pour l’exhaustivité, les partenaires doivent également vérifier que sur les groupes de ressources, aucune attribution de refus n’existe dans l’abonnement.

Étape 3 – Vérifier si l’utilisateur a configuré Azure PAL

Seul l’utilisateur qui a configuré Azure PAL peut vérifier les attributions Azure PAL. Aucun autre utilisateur admin ne peut le faire. Pour plus d’informations sur la façon dont l’utilisateur peut vérifier si Azure PAL a été défini, consultez Lier un compte Azure à un PartnerID.

Remarque

Azure PAL doit utiliser un PartnerID qui fait partie de la même organisation du programme de partenariat Microsoft AI Cloud, qui est le partenaire de transaction pour cet abonnement Azure. Dans le modèle indirect, il peut s’agir soit du PartnerID du fournisseur, soit du PartnerID du revendeur attaché à cette vente.

Contenu connexe

• Crédit Partenaires – Vue d’ensemble
• Rôles et autorisations pour le crédit partenaire gagné