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

Scénarios courants de résolution des problèmes

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 éligible au PEC, comment il est calculé et comment il est payé.

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.

• Vérifiez que vous examinez la facture G (nouvelle expérience commerciale) et le fichier de reconquête. Le plan Azure et le PEC ne sont pas affichés sur la facture D (héritée) ou le fichier de reconversion.

• 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’épargne Azure, les machines virtuelles Azure SPOT et les produits tiers 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, vérifiez que votre PartnerID a été 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 ont été définies par défaut lorsque le plan Azure a été provisionné. S’ils ont été supprimés, consultez Rétablir les privilèges d’administrateur pour les abonnements Azure fournisseur de solutions Cloud (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.

Scénarios multipartner

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

Un autre paramètre partenaire AOBO ou d’autres autorisations et la définition d’azure RBAC supplémentaires pour les utilisateurs disposant d’autorisations RBAC Azure n’affecteront pas PEC pour le partenaire de transaction.

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

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

Par conséquent, si AOBO ou un autre modèle d’autorisation a été utilisé avant le transfert, avec les autorisations définies pour l’ancien « partenaire de transaction », les autorisations pointent toujours vers l’ancien partenaire 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.

Mises à jour partnerID

L’Espace partenaires vous permet de modifier l’ID partenaire 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 cette instance, et lorsque PEC s’avère manquant, nous vous recommandons de contacter le support technique (mentionnez que vous avez récemment remappé votre inscription CSP à une autre organisation du programme Microsoft AI Cloud Partner).

Comment vérifier les autorisations AOBO

Lorsqu’un partenaire crée un abonnement Azure Plan 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 de ces 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.

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

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

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

• Via 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 petit coût mensuel dans l’abonnement Azure disponible dans le contexte du locataire. Vous pouvez supprimer le partage après les étapes suivantes.

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') }

Les ObjectID groupes seront affichés avec leurs noms :

É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 répertoires/locataires, tels que votre compte d’utilisateur espace partenaires ou - a été ajouté en tant qu’invités à plusieurs locataires.

Par conséquent, vous avez besoin de l’ID de locataire pour le client donné.

• Via Portail Azure : vous pouvez facilement obtenir l’ID de locataire à partir de la liste des clients dans l’Espace partenaires. L’ID de locataire est étiqueté « ID Microsoft » :

  

• Via 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é

Chaque aspect doit correspondre à la réception du PEC via 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 du plan Azure) ont été vendus et qui 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 https://learn.microsoft.com/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 :

  

Comment vérifier les autorisations Azure Lighthouse et Azure PAL

Comme AOBO, Azure Lighthouse permet aux 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 permet une définition plus précise 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 défini à l’aide de l’interface utilisateur 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 définitivement et à quels groupes. Ensuite, vous pouvez vérifier si l’utilisateur ayant 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) où 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 locataire partenaire/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 d’Azure PAL ; aucun autre utilisateur administrateur ne peut le faire. Consultez Comment faire expliquer le lien d’administrateur partenaire (PAL) à mon client ? dans Lier un compte Azure à un PartnerID pour plus d’informations sur la façon dont l’utilisateur peut vérifier si Azure PAL a été défini, via l’interface utilisateur ou PowerShell.

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

Comment vérifier l’attribution d’utilisateurs individuelle 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 en tant que véhicule pour gagner PEC, la vérification implique simplement d’examiner les autorisations attribuées dans la gestion des abonnements Azure pour l’utilisateur et de vérifier que l’utilisateur a correctement défini Azure RBAC. Lorsqu’un principal de service est utilisé, la vérification du RBAC Azure doit se produire via 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 des 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 dans un groupe de ressources.

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

Bien qu’il semble que les utilisateurs aient accès, leurs autorisations peuvent toujours être temporaires ou bloquées par le biais d’affectations de refus.

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 ressources Azure de l’abonnement sont gérées par des stratégies PIM 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 :

Étape 3 : vérifier si l’utilisateur a configuré Azure PAL

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

Contenu connexe

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