Leitfaden zur Problembehandlung mit dem vom Partner erworbenen Guthaben
Geeignete Rollen: Benutzerverwaltungsadministrator | Administrator-Agent | Abrechnungsadministrator | Vertriebsmitarbeiter
AKS-Problembehandlung
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 für PEC berechtigt ist, wie es berechnet wird und wie es bezahlt 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.
Stellen Sie sicher, dass Sie die G-Rechnung (neue Commerce-Erfahrung) und die Neukonfigurationsdatei betrachten. Azure-Plan und PEC werden nicht auf der Rechnung D (Legacy) oder der Neukonfigurationsdatei angezeigt.
Vergewissern Sie sich, dass Ihr Microsoft AI Cloud Partner Program-Vertrag aktiv ist.
Vergewissern Sie sich, dass Ihr Angebot berechtigt ist. (Ältere Azure-Angebote, Azure Reserved Instances, Azure Savings Plans, Azure SPOT VMs und Produkte von Drittanbietern 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 wurde. Ü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 wurden standardmäßig festgelegt, wenn der Azure-Plan bereitgestellt wurde. Wenn sie entfernt wurden, lesen Sie administratorrechte für die Abonnements eines Azure Cloud Solution Provider (CSP) eines Kunden erneut.
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.
Szenarien mit mehreren Partnern
Für PEC ist es nur wichtig, dass der Transacting-Partner 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.
Eine weitere Partnereinstellung zusätzliche AOBO- oder andere Berechtigungen und das Festlegen zusätzlicher Azure RBAC für Benutzer mit Azure RBAC-Berechtigungen wirkt sich nicht auf die PEC für den Transacting-Partner aus.
Siehe folgende Tabelle. MPN1 ist ein indirekter Anbieter, MPN2 ist der indirekte Wiederverkäufer, der mit der Transaktion als Datensatzhändler verknüpft ist, und MPN3 ist ein weiterer CSP-Partner (direkt oder ein anderer indirekter Wiederverkäufer):
| Transacting-Partner (BillTo) | Azure RBAC (für Benutzer oder Leuchtturm mit PEC-berechtigter Rolle) | AOBO (PEC-berechtigte Rolle) | PEC |
|---|---|---|---|
| MPN1 | MPN1 | N/V | Ja |
| MPN1 | N/V | MPN1 | Ja |
| MPN1 | MPN2 | N/V | Ja |
| MPN1 | N/V | MPN2 | Ja |
| MPN1 | MPN3 | MPN1 | Ja |
| MPN1 | MPN1 | MPN3 | Ja |
| MPN1 | MPN1 | MPN2 | Ja |
| MPN1 | MPN2 | MPN1 | Ja |
| MPN1 | MPN2 | MPN3 | Ja |
| MPN1 | MPN3 | MPN2 | Ja |
| MPN1 | MPN3 | N/V | No |
| MPN1 | N/V | MPN3 | No |
| MPN1 | – | – | No |
| MPN1 | MPN3 | MPN3 | No |
Azure-Abonnementübertragung
Wenn ein Partner ein Azure-Abonnement von oder an einen anderen Partner überträgt, werden keine Berechtigungen für diese Übertragung geändert.
Wenn AOBO oder ein anderes Berechtigungsmodell vor der Übertragung verwendet wurde, wobei berechtigungen für den alten "Transacting-Partner" festgelegt sind, verweisen die Berechtigungen nach der Übertragung weiterhin auf den alten 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-Updates
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 PEC nicht vorhanden ist, empfehlen wir, sich an den Support zu wenden (erwähnen Sie, dass Sie Ihre CSP-Registrierung kürzlich erneut einer anderen Organisation des Microsoft AI Cloud Partner Program zugeordnet haben).
So überprüfen Sie AOBO-Berechtigungen
Wenn ein Partner ein Azure Plan-Abonnement für einen Kunden erstellt, wird AOBO in Form eines "Fremdprinzipals" festgelegt. Der Fremdprinzipal erbt Besitzerberechtigungen für das Azure-Abonnement. Die AOBO-Berechtigungen bedeuten, dass eine bestimmte Gruppe im CSP Partner Center-Mandanten (Admin Agents) diese 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.
Die Verwendung von AZ PowerShell oder Azure CLI ist erforderlich, um sicherzustellen, dass der AOBO korrekt festgelegt ist und auf die richtige Gruppe im richtigen CSP-Mandanten verweist.
Schritt 1 : Identifizieren der ObjectIDs der Agentgruppen des Transacting-Partners
- Über Azure-Portal: Partner können sich bei der Azure-Portal in ihrem eigenen Mandanten anmelden und nach den jeweiligen Gruppen in Microsoft Entra ID > Groups 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. Dieses Konto verursacht im Mandantenkontext eine geringe monatliche Kosten im Azure-Abonnement. 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 Gruppen werden zusammen mit ihren Namen angezeigt:
Hinweis
Wenn Sie kein Ergebnis erhalten, stellen Sie sicher, dass Sie mit Ihrem Partner Center-Konto verbunden sind.
Hinweis
Indirekte Wiederverkäufer sehen keine SalesAgents-Gruppe. Dieser Schritt muss nur einmal ausgeführt werden, da AOBO in jedem Kundenmandanten dieselben 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/Mandanten hat, z. B. Ihr Partner Center-Benutzerkonto, oder - wurde als Gäste zu mehreren Mandanten hinzugefügt.
Daher benötigen Sie die TenantID für den angegebenen Kunden.
Über Azure-Portal: Sie können die TenantID einfach aus der Kundenliste im Partner Center abrufen. Die tenantID ist mit der Bezeichnung "Microsoft-ID" gekennzeichnet:
Ü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 mit dem Empfang von PEC über AOBO übereinstimmen:
- 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 Plan-Berechtigungen) 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 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
}
}
}
Die Ausgabe dieses Skripts kann dann wie folgt formatiert werden:
Überprüfen von Azure Lighthouse-Berechtigungen und Azure PAL
Wie AOBO ermöglicht Azure Lighthouse Gruppen von Benutzern im (Partner)-Verwaltungsmandanten, delegierte Berechtigungen im Azure-Abonnement des Kunden zu erben. Der Unterschied besteht darin, dass im Vergleich zu AOBO eine genauere Definition der Gruppen und Berechtigungsebenen möglich ist.
Für dieses Berechtigungsmodell ist es einfacher zu überprüfen, ob es mit der Azure-Portal-Benutzeroberfläche ordnungsgemäß festgelegt 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 identifizieren, für welche Kunden die Azure RBAC-Rollenberechtigungen dauerhaft delegiert wurden und an welche Gruppen. Anschließend können Sie überprüfen, ob der Benutzer, der über die Azure RBAC-Zuordnung verfügt, 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, in denen delegierter Zugriff bereitgestellt wurde:
Öffnen Sie die Delegierungen in der rechten Spalte unter "Rollenzuweisungen", um zu sehen, welche Benutzergruppe im Partner-/Verwaltungsmandanten jede Art von 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; dies kann kein anderer Administratorbenutzer tun. Weitere Informationen dazu, wie der Benutzer überprüfen kann, ob Azure PAL festgelegt wurde, finden Sie Gewusst wie unter "Verknüpfen eines Azure-Kontos mit einer PartnerID", um weitere Informationen darüber zu erhalten, wie der Benutzer überprüfen kann, ob Azure PAL entweder über die Benutzeroberfläche oder powerShell festgelegt wurde.
Hinweis
Azure PAL sollte eine PartnerID verwenden, die Teil derselben Microsoft AI Cloud Partner Program-Organisation ist, die der Transacting-Partner für dieses Azure-Abonnement ist. Im indirekten Modell kann dies entweder die PartnerID des Anbieters oder der spezifische Wiederverkäufer sein, der diesem Verkauf zugeordnet 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.
So überprüfen Sie die Zuweisung einzelner Benutzer 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.
Bei der Verwendung einzelner Benutzerkonten als Fahrzeug zum Sammeln von PEC umfasst die Prüfung nur die Überprüfung der zugewiesenen Berechtigungen in der Azure-Abonnementverwaltung für den Benutzer und die Überprüfung, dass der Benutzer Azure RBAC ordnungsgemäß festgelegt hat. Wenn ein Dienstprinzipal verwendet wird, muss die Überprüfung von Azure RBAC über PowerShell erfolgen.
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 auch die gleiche Ansicht "Access Control (IAM)" in 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, sind ihre Berechtigungen möglicherweise weiterhin temporär oder über Verweigerungszuweisungen blockiert.
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 Azure-Ressourcen im Abonnement von PIM-Richtlinien verwaltet werden, und ob der Benutzer Richtlinien unterliegen.
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; dies kann kein anderer Administratorbenutzer 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 PartnerID.
Hinweis
Azure PAL sollte eine PartnerID verwenden, die Teil derselben Microsoft AI Cloud Partner Program-Organisation ist, die der Transacting-Partner für dieses Azure-Abonnement ist. Im indirekten Modell kann dies entweder die PartnerID des Anbieters oder die PartnerID des Händlers sein, der diesem Verkauf zugeordnet ist.