Leitfaden zur Problembehandlung mit dem vom Partner erworbenen Guthaben

Geeignete Rollen: Benutzerverwaltungsadministrator | Administrator-Agent | Abrechnungsadministrator | Vertriebsmitarbeiter

Behandeln allgemeiner Probleme

Mit der neuen Azure-Commerce-Oberfläche können Partner Rabatte über die PEC (Partner Earned Credits) für Dienstverwaltungen erhalten. PEC wird nur Partnern mit den entsprechenden Berechtigungen gewährt. Erfahren Sie , wer Anspruch auf PEC hat, wie er berechnet und ausgezahlt wird.

Dieser Artikel enthält grundlegende Anleitungen zur Problembehandlung, wenn PEC nicht gewährt wird.

Voraussetzungen

Wenn Sie Probleme mit PEC haben, z. B. Zugriff oder fehlende Informationen, überprüfen Sie zunächst die folgenden Elemente.

Hinweis

Nur indirekte Anbieter und Direktrechnungspartner sind berechtigt, PEC zu verdienen.

• Achten Sie darauf, dass Sie sich die Rechnungs- und Abstimmungsdatei G (New Commerce Experience) ansehen. Azure-Plan und PEC werden in der Rechnung oder Abstimmungsdatei "D" (Legacy) nicht angezeigt.

• Vergewissern Sie sich, dass Ihr Microsoft AI Cloud Partner Program-Vertrag aktiv ist.

• Vergewissern Sie sich, dass Ihr Angebot berechtigt ist. Legacy-Azure-Angebote, Azure Reserved Instances, Azure Savings Plans, Azure SPOT-VMs und Produkte, die nicht von Microsoft stammen, sind nicht berechtigt.

• Vergewissern Sie sich, dass Sie (oder der indirekte Wiederverkäufer, der als Vertriebspartner des Datensatzes im Azure-Plan festgelegt ist) über eine gültige Rolle "Verwalten im Auftrag von (AOBO) oder azure role-based access control (Azure RBAC)"-Rolle für die Abonnement-/Ressourcengruppe/Ressource verfügen. Alternativ:

  • Wenn Sie Azure Lighthouse verwenden, stellen Sie sicher, dass Ihre PartnerID mit mindestens einem Benutzerkonto verknüpft ist. Überprüfen Sie außerdem, ob sie Zugriff auf die Abonnement-/Ressourcengruppe dieses Kunden hat.
  • Wenn Sie eine Azure RBAC-Zuordnung verwenden, stellen Sie sicher, dass der Benutzer in jedem Kundenmandantenkontext über eine berechtigte Rolle für PEC und Azure RBAC verfügt.

• Überprüfen Sie, ob der Kunde Ihre AOBO-Berechtigungen entfernt hat. Die Berechtigungen werden standardmäßig festgelegt, wenn der Azure-Plan bereitgestellt wurde. Wenn sie entfernt werden, finden Sie weitere Informationen unter Wiederherstellen von Administratorrechten für die Azure Cloud Solution Provider (CSP)-Abonnements eines Kunden.

• Vergewissern Sie sich, dass Sie den ganzen Tag über Administratorzugriff verfügen.

• Vergewissern Sie sich, dass Sie die richtigen Spalten in Ihren Abstimmungsdateien überprüfen. Weitere Informationen finden Sie unter Azure plan billing: About your invoice reconciliation file.

Grundlegendes zu Szenarien mit mehreren Partnern

Für PEC ist es nur wichtig, dass der Transaktionspartner eine der verfügbaren Berechtigungsoptionen festgelegt hat. Für das indirekte Modell kann es sich um den Anbieter oder den Händler oder beides handeln.

Ein anderer Partner, der zusätzliche AOBO- oder andere Berechtigungen und zusätzliche Azure RBAC für Benutzer mit Azure RBAC-Berechtigungen festlegt, wirkt sich nicht auf PEC für den Transaktionspartner aus.

In der folgenden Tabelle ist MPN1 ein indirekter Anbieter, MPN2 ist der indirekte Vertriebspartner, der mit der Transaktion als eingetragener Vertriebspartner verknüpft ist. MPN3 ist ein weiterer CSP-Partner (direkter oder anderer indirekter Reseller):

Transacting-Partner (BillTo)	Azure RBAC (für Benutzer oder Leuchtturm mit PEC-berechtigter Rolle)	AOBO (PEC-berechtigte Rolle)	PEC
Hersteller-Art.nr. 1	Hersteller-Art.nr. 1	N/V	Ja
Hersteller-Art.nr. 1	N/V	Hersteller-Art.nr. 1	Ja
Hersteller-Art.nr. 1	Hersteller-Art.nr. 2	N/V	Ja
Hersteller-Art.nr. 1	N/V	Hersteller-Art.nr. 2	Ja
Hersteller-Art.nr. 1	Hersteller-Art.nr. 3	Hersteller-Art.nr. 1	Ja
Hersteller-Art.nr. 1	Hersteller-Art.nr. 1	Hersteller-Art.nr. 3	Ja
Hersteller-Art.nr. 1	Hersteller-Art.nr. 1	Hersteller-Art.nr. 2	Ja
Hersteller-Art.nr. 1	Hersteller-Art.nr. 2	Hersteller-Art.nr. 1	Ja
Hersteller-Art.nr. 1	Hersteller-Art.nr. 2	Hersteller-Art.nr. 3	Ja
Hersteller-Art.nr. 1	Hersteller-Art.nr. 3	Hersteller-Art.nr. 2	Ja
Hersteller-Art.nr. 1	Hersteller-Art.nr. 3	N/V	Nein
Hersteller-Art.nr. 1	N/V	Hersteller-Art.nr. 3	Nein
Hersteller-Art.nr. 1	N/V	N/V	Nein
Hersteller-Art.nr. 1	Hersteller-Art.nr. 3	Hersteller-Art.nr. 3	Nein

Grundlegendes zu Azure-Abonnementübertragungen

Wenn ein Partner ein Azure-Abonnement von oder an einen anderen Partner überträgt, werden keine Berechtigungen für diese Übertragung geändert.

Wenn also vor der Übertragung AOBO oder ein anderes Berechtigungsmodell verwendet wurde, wobei die Berechtigungen für den vorherigen "Transaktionspartner" festgelegt wurden, verweisen die Berechtigungen auch nach der Übertragung auf den vorherigen Partner. Aber jetzt wird ein anderer Partner zum "Transacting-Partner".

Für alle Azure-Abonnementübertragungen empfiehlt es sich, vor der Übertragung Berechtigungen wie Azure RBAC durch den neuen Zielpartner zu erstellen. Sie können dies sicher tun, ohne die PEC des alten Partners bis zur Übertragung zu beeinträchtigen.

PartnerID-Aktualisierungen verstehen

Mit Partner Center können Sie die PartnerID ändern, die Ihrer CSP-Registrierung zugeordnet ist. Das Aktualisieren der PartnerID auf eine andere Standort-ID des Microsoft AI Cloud Partner Program innerhalb derselben globalen Microsoft AI Cloud Partner Program-Organisation (eine andere Microsoft AI Cloud Partner Program-Standort-ID unter derselben globalen MICROSOFT AI Cloud Partner Program-ID) hat keine Auswirkungen auf PEC.

Wenn die PartnerID in eine Standort-ID in einer anderen Microsoft AI Cloud Partner Program-Organisation geändert wird, kann PEC jedoch beeinträchtigt werden. In diesem Fall und wenn sich herausstellt, dass PEC fehlt, empfehlen wir, sich an den Support zu wenden. Erwähnen Sie, dass Sie Ihre CSP-Registrierung kürzlich einer anderen Microsoft AI Cloud-Partnerprogramm-Organisation neu zugeordnet haben.

Überprüfen des Administrators im Auftrag von (AOBO)-Berechtigungen

Wenn ein Partner ein Azure-Planabonnement für einen Kunden erstellt, wird AOBO in Form eines ausländischen Prinzipals festgelegt. Der Fremdprinzipal erbt Besitzerberechtigungen für das Azure-Abonnement. Die AOBO-Berechtigungen bedeuten, dass eine bestimmte Gruppe im CSP Partner Center-Mandanten (Administrator-Agents) die Berechtigungen erbt.

Der Fremdprinzipal, wie im Azure-Portal dargestellt, enthält keine Details dazu, welcher Gruppe sie im bestimmten Partnermandanten zugeordnet ist.

Wenn Sie den Fremdprinzipal im Azure-Portal anzeigen, wird ein Partnername wie "Fremdprinzipal für 'Contoso' ..." angezeigt, aber "Contoso" ist nur der Anzeigename des Microsoft Entra-Mandanten des Partners, und es ist nicht eindeutig.

Verwenden Sie AZ PowerShell oder Azure CLI, um mit 100% Sicherheit zu überprüfen, ob der AOBO ordnungsgemäß festgelegt ist, auf die richtige Gruppe verweist und sich im richtigen CSP-Mandanten befindet.

Schritt 1 : Identifizieren der ObjectIDs der Agentgruppen des Transacting-Partners

• Über das Azure-Portal: Partner können sich mit ihrem eigenen Mandanten beim Azure-Portal anmelden und in Microsoft Entra ID-Gruppen >nach den entsprechenden Gruppen suchen. Die ObjectID wird rechts neben dem Gruppennamen angezeigt.

• Über PowerShell: Starten Sie PowerShell ( entweder lokale PowerShell oder Azure Cloud Shell).

Bevor Sie Azure Cloud Shell verwenden, müssen Sie ein Speicherkonto einrichten. Für dieses Konto fallen geringe monatliche Kosten im Azure-Abonnement an, das im Mandantenkontext verfügbar ist. Sie können die Freigabe nach den folgenden Schritten löschen.

Hinweis

Azure AD- und MSOnline PowerShell-Module sind ab dem 30. März 2024 veraltet. Weitere Informationen finden Sie im Update zur Unterstützungseinstellung. Nach diesem Datum wird die Unterstützung für diese Module auf die Migrationsunterstützung für das Microsoft Graph PowerShell-SDK und Sicherheitskorrekturen beschränkt. Die veralteten Module funktionieren weiterhin bis zum 30. März 2025.

Es wird empfohlen, für die Interaktion mit Microsoft Entra ID (früher Azure AD) zu Microsoft Graph PowerShell zu migrieren. Informationen zu allgemeinen Migrationsfragen finden Sie in den häufig gestellten Fragen zur Migration. Hinweis: Bei der Version 1.0.x von MSOnline können nach dem 30. Juni 2024 Unterbrechungen auftreten.

Stellen Sie sicher, dass die folgenden Module installiert und auf die neueste Version aktualisiert werden:

• AzureAD-Modul
• AZ PowerShell-Modul (für Cloud Shell nicht erforderlich)

Verwenden Sie bei Bedarf die folgenden cmdlets PowerShell-Fenster, um diese Module zu installieren:

Install-Module -Name AzureAD -Force

Install-Module -Name Az -AllowClobber -Force

Stellen Sie zunächst eine Verbindung mit dem Partner Center-Mandanten mit Ihrem Partner Center-Benutzerkonto her, und rufen Sie die ObjectIDs der Gruppe "AdminAgents" und "HelpdeskAgents" ab:

Connect-AzureAD -TenantDomain CSPtenantname.onmicrosoft.com

Melden Sie sich mit Ihren Partner Center-Anmeldeinformationen an:

Fragen Sie die Informationen zu den Agentgruppen ab:

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

Die ObjectID der Gruppen wird zusammen mit ihren Namen angezeigt:

Hinweis

Wenn Sie kein Ergebnis erhalten, stellen Sie sicher, dass Sie eine Verbindung mit Ihrem Partner Center-Konto hergestellt haben.

Hinweis

Indirekten Vertriebspartnern wird keine SalesAgents-Gruppe angezeigt. Dieser Schritt muss nur einmal ausgeführt werden, da AOBO in jedem Kundenmandanten die gleichen IDs verwendet.

Schritt 2: Vergleichen von ObjectIDs mit den vom Fremdprinzipal verwendeten

Es ist wichtig, die TenantID als Wert für den Mandantenparameter (anstelle des Mandantendomänennamens) mit einem Benutzerkonto zu verwenden, das entweder:

• Zugriff auf mehrere Verzeichnisse und Mandanten hat, z. B. Ihr Partner Center-Benutzerkonto, oder
• Wurde als Gäste zu mehreren Mandanten hinzugefügt.

Sie benötigen also die TenantID für den Kunden.

• Über das Azure-Portal: Sie können die TenantID einfach aus der Kundenliste in Partner Center abrufen. Die tenantID ist mit Microsoft ID beschriftet:

  

• Über PowerShell: Stellen Sie eine Verbindung mit dem Azure-Abonnement des Kunden mit gültigen Anmeldeinformationen her. Die Anmeldeinformationen sollten über die Berechtigung zum Lesen des Azure-Abonnements und AzureAD des Kundenmandanten verfügen:

  Connect-AzAccount -Tenant $CustomerTenantID
  

  • Lesen von Rollenzuweisungen für den Fremdprinzipal der Azure-Abonnements des Kunden:

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

  

  • Die resultierende ObjectID sollte mit der ObjectID der in Schritt 1 identifizierten Gruppe "AdminAgent" oder "HelpDeskAgent" übereinstimmen.

Zusammenfassung

Jeder Aspekt muss zusammenpassen, um PEC über AOBO zu erhalten:

• Das Azure-Abonnement des Kunden verfügt über einen Fremdprinzipal mit berechtigter Azure RBAC-Rollenzuweisung.
• Die ObjectID der gruppe, die vom Fremdprinzipal verwendet wird, bezieht sich auf die ObjectID der Gruppe "AdminAgent" oder "HelpdeskAgent" im Partnermandanten.
• "Partnermandant" bezeichnet den direkten Partnermandanten. Im indirekten Modell bedeutet dies den indirekten Anbieter oder den indirekten Partnermandanten.

Beispielskripts

Dieser Abschnitt enthält Beispielskripts, mit denen die Informationen über mehrere Abonnements hinweg gesammelt und in einer gespeichert werden können. CSV-Datei. Diese Skripts sind als Beispiele gedacht und werden ohne Unterstützung bereitgestellt. Obwohl die Skripts keine Änderungen im Setup vornehmen, sollten sie gründlich getestet werden, und für das konkrete Partner-/Kundenszenario kann eine Anpassung erforderlich sein.

• Auflisten von AOBO-Details für einen einzelnen Kunden: In diesem Beispiel werden Microsoft Entra-ID und Azure PowerShell-Module verwendet.

### 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
}
}

• AOBO-Details für mehrere Kunden auflisten: Dieser Code dient nur zur Veranschaulichung.
  • Rufen Sie eine Liste aller Abonnements von CSP-Kunden und allen Fremdprinzipalen ab, und ermitteln Sie, ob eine Übereinstimmung besteht. Dieser Code kann auch verwendet werden, um Informationen zur Unterstützung zu sammeln.
  • Überprüfen Sie, welche Azure-Abonnements (Azure-Planberechtigungen) verkauft wurden und auf welche mit den aktuellen Anmeldeinformationen zugegriffen werden kann.
  • Bei indirekten Wiederverkäufern funktioniert dieses Skript ebenfalls. Aber alle Abonnements würden die Notiz "nicht verkauft" haben, auch wenn sie der Partner des Datensatzes für diesen Verkauf sind.

### 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
}
}
}

• Die Ausgabe dieses Skripts kann dann wie folgt formatiert werden:

  

Überprüfen von Azure Lighthouse-Berechtigungen und Azure Partner Admin Link (PAL)

Wie AOBO ermöglicht Azure Lighthouse Benutzergruppen im (Partner-)Verwaltungsmandanten, delegierte Berechtigungen im Azure-Abonnement des Kunden zu erben. Der Unterschied besteht darin, dass es eine detailliertere Definition von Gruppen und Berechtigungsstufen unterstützt als AOBO.

Für dieses Berechtigungsmodell ist es einfacher, mithilfe der Benutzeroberfläche des Azure-Portals zu überprüfen, ob es ordnungsgemäß eingerichtet wurde. Nur der Partner kann die vollständige Überprüfung bereitstellen, ob das Azure Lighthouse-Setup korrekt ist.

In den folgenden Schritten wird beschrieben, wie Sie ermitteln, an welche Kunden die Azure RBAC-Rollenberechtigungen dauerhaft delegiert wurden und an welche Gruppen. Anschließend können Sie überprüfen, ob der Benutzer mit der Azure RBAC-Zuordnung Mitglied dieser Gruppen ist.

Schritt 1 – Überprüfen von Lighthouse-Delegationen auf Kunden

Überprüfen Sie, ob anwendbare Delegierungen PEC-berechtigte Azure RBAC-Rollen verwenden.

• Öffnen Sie Azure-Portal (mit einem Benutzer aus dem Verwaltungsmandanten des Partners). Suchen Sie dann nach "Lighthouse" und wählen Sie "Meine Kunden" aus.

  

• Wählen Sie in der Kundenübersicht "Delegationen " auf der linken Seite aus. Dadurch wird die Liste der Ressourcen (Abonnements oder Ressourcengruppen) geöffnet, für die delegierter Zugriff bereitgestellt wurde:

  

• Öffnen Sie die Delegierungen in der rechten Spalte unter Rollenzuweisungen , um zu sehen, welche Benutzergruppe im Partner-/Verwaltungsmandanten die einzelnen Berechtigungen erbt (siehe Spalte Rolle ). Sie können auch sehen, ob diese Berechtigungen dauerhaft sind (siehe Spalte "Zugriffstyp"):

  

Schritt 2 – Überprüfen der Gruppenmitgliedschaft

Wählen Sie den Anzeigenamen der Gruppe aus. Öffnen Sie dazu die Gruppendetails. Wählen Sie "Mitglieder" aus, um zu steuern, welcher Benutzer Azure RBAC festgelegt hat und Mitglied der jeweiligen Gruppe ist:

Schritt 3 – Überprüfen, ob der Benutzer Azure PAL eingerichtet hat

Nur der Benutzer, der Azure PAL festgelegt hat, kann die Azure PAL-Zuweisung überprüfen. Kein anderer Admin-Benutzer kann das tun. Weitere Informationen dazu, wie der Benutzer überprüfen kann, ob Azure PAL entweder über die Benutzeroberfläche oder PowerShell festgelegt wurde, finden Sie unter Verknüpfen eines Azure-Kontos mit einer PartnerID.

Hinweis

Azure PAL sollte eine PartnerID verwenden, die Teil derselben Microsoft AI Cloud-Partnerprogrammorganisation ist, die auch der Transaktionspartner für dieses Azure-Abonnement ist. Im indirekten Modell kann es sich entweder um die PartnerID des Anbieters oder des spezifischen Resellers handeln, der an diesen Verkauf angehängt ist.

Schritt 4 – Überprüfen auf zeitgebundene Gruppenzuweisungen

Da die Gruppenmitgliedschaft möglicherweise nicht dauerhaft ist, überprüfen Sie, ob die Gruppe für die Verwaltung des privilegierten Zugriffs aktiviert wurde. Suchen Sie, wo "Privilegierter Zugriff" auf der linken Seite unter "Aktivität" in den Gruppeneinstellungen angezeigt wird. Wenn true, überprüfen Sie, ob der Benutzer über eine aktive Zuweisung und den Zeitrahmen für diese Zuordnung verfügt.

Hinweis

Da die Zuordnung "Endzeit" ist, wenn ein Benutzer automatisch aus der Gruppe entfernt wird, gehen PEC für Benutzer verloren, die Azure RBAC festgelegt haben. Ebenso würde PEC erst nach der Zuordnung "Startzeit" gewährt werden.

Überprüfen der individuellen Benutzerzuweisung und Azure PAL

In einigen Fällen ist es möglicherweise besser geeignet, mit einzelnen Benutzerkonten mit Berechtigungen für Azure-Abonnements zu arbeiten. Diese Konten können Gastbenutzerkonten (von jedem Mandanten) oder Benutzerkonten sein, die im Kundenmandanten oder Dienstprinzipal erstellt wurden.

Wenn Sie einzelne Benutzerkonten als Vehikel zum Erwerben von PEC verwenden, umfasst die Überprüfung die Überprüfung der für den Benutzer zugewiesenen Berechtigungen in der Azure-Abonnementverwaltung und die Überprüfung des korrekten Benutzers Azure RBAC. Wenn Sie einen Dienstprinzipal verwenden, erfolgt die Überprüfung von Azure RBAC über PowerShell.

Schritt 1 – Überprüfen von Berechtigungen in der Azure-Abonnementverwaltung

• Öffnen Sie das Azure-Portal. Stellen Sie sicher, dass Sie als Benutzer angemeldet sind, der über eine Azure RBAC-Rolle mit mindestens Lesezugriff auf das betreffende Abonnement verfügt.

• Suchen Sie in der Suchleiste nach "Abonnements", um Abonnementdetails zu öffnen:

  

• Wechseln Sie in den Abonnementdetails zu "Access Control (IAM)". Wählen Sie dann "Rollenzuweisungen" aus, um Benutzer zu überprüfen, die Zugriff auf Abonnementebene haben und wenn in der Spalte "Rolle" PEC-berechtigte Azure RBAC-Rollen angezeigt werden. Wenn Berechtigungen auf Ressourcengruppenebene festgelegt wurden, ist die gleiche Ansicht "Access Control (IAM)" auch innerhalb einer Ressourcengruppe verfügbar.

Hinweis

Berechtigungen können auch einer Gruppe von Benutzern erteilt werden, für die auch die Gruppenmitgliedschaft des Benutzers mit Azure RBAC-Satz überprüft werden muss.

Schritt 2 – Sicherstellen, dass Berechtigungen dauerhaft sind und keine Verweigerungszuweisungen gelten

Obwohl es so aussieht, als hätten Benutzer Zugriff, können ihre Berechtigungen dennoch temporär sein oder durch Zuweisungen verweigern blockiert werden.

Die Verwendung der Azure RBAC-Rollenzuweisung (Privileged Identity Management, PIM) ist möglicherweise zeitgebunden. Obwohl Möglicherweise Benutzer mit Berechtigung angezeigt werden, sind sie möglicherweise nur für kurze Zeit vorhanden. Um zu überprüfen, ob die Azure RBAC-Rollenzuweisung dauerhaft ist, überprüfen Sie die PIM-Verwaltung in Azure-Portal. Überprüfen Sie insbesondere, wo PIM-Richtlinien Azure-Ressourcen im Abonnement verwalten und ob der Benutzer Richtlinien unterliegt.

Außerdem kann in der Liste der Berechtigungen angezeigt werden, dass der Benutzer über Berechtigungen für das Abonnement verfügt. Möglicherweise gibt es jedoch Verweigerungszuweisungen, die den Zugriff des Benutzers auf etwas blockieren. Wählen Sie in "Access Control (IAM)" die Registerkarte "Zuordnung verweigern " aus, um festzustellen, ob Verweigerungszuweisungen gelten:

Hinweis

Zur Vollständigkeit sollten Partner auch überprüfen, ob in Ressourcengruppen keine Verweigerungszuweisungen innerhalb des Abonnements vorhanden sind.

Schritt 3 – Überprüfen, ob der Benutzer Azure PAL eingerichtet hat

Nur der Benutzer, der Azure PAL eingerichtet hat, kann die Azure PAL-Zuweisungen überprüfen. Kein anderer Admin-Benutzer kann das tun. Weitere Informationen dazu, wie der Benutzer überprüfen kann, ob Azure PAL festgelegt wurde, finden Sie unter Verknüpfen eines Azure-Kontos mit einer Partner-ID.

Hinweis

Azure PAL sollte eine PartnerID verwenden, die Teil derselben Microsoft AI Cloud-Partnerprogrammorganisation ist, die der Transaktionspartner für dieses Azure-Abonnement ist. Im indirekten Modell kann es sich entweder um die PartnerID des Anbieters oder um die PartnerID des Resellers handeln, die an diesen Verkauf angehängt ist.

Zugehöriger Inhalt

• Vom Partner erworbenes Guthaben – Übersicht
• Rollen und Berechtigungen für vom Partner erworbenes Guthaben