Condividi tramite

Guida alla risoluzione dei problemi relativi al credito ottenuto dai partner

Ruoli appropriati: Amministratore gestione utenti | Agente amministratore | Amministratore fatturazione | Agente di vendita

Risolvere i problemi relativi agli scenari comuni

Con la nuova esperienza commerciale di Azure, i partner possono ricevere sconti tramite il credito ottenuto dai partner (PEC) per i servizi gestiti. Il PEC viene concesso solo ai partner con autorizzazioni idonee. Scopri chi ha diritto alla PEC, come viene calcolata e viene pagata.

Questo articolo fornisce indicazioni di base per la risoluzione dei problemi se la pec non viene concessa.

Prerequisiti

Se riscontri problemi con PEC, come l'accesso o informazioni mancanti, inizia controllando i seguenti elementi.

Nota

Solo i provider indiretti e i partner con fatturazione diretta sono idonei per ottenere il PEC.

  • Assicurati di guardare il file di fatturazione e riconciliazione G (nuova esperienza commerciale). Il piano di Azure e la PEC non vengono visualizzati nella fattura D (legacy) o nel file di riconciliazione.

  • Verificare che il contratto del Programma Microsoft AI Cloud Partner sia attivo.

  • Verificare che l'offerta sia idonea. Le offerte legacy di Azure, le istanze riservate di Azure, i piani di risparmio di Azure, le macchine virtuali SPOT di Azure e i prodotti non Microsoft non sono idonei.

  • Conferma che tu (o il rivenditore indiretto impostato come rivenditore registrato nel piano di Azure) disponga di un ruolo di Amministratore per Conto di (AOBO) o di un ruolo di Controllo degli Accessi in Base ai Ruoli di Azure (Azure RBAC) per la sottoscrizione/gruppo di risorse/risorsa. In alternativa:

    • Se si usa Azure Lighthouse, assicurarsi che il PartnerID sia collegato ad almeno un account utente. Verificare anche che abbia accesso alla sottoscrizione o al gruppo di risorse del cliente.
    • Se si utilizza un'associazione di Controllo degli accessi in base al ruolo di Azure: assicurarsi che l'utente abbia un ruolo idoneo per PEC e il Controllo degli accessi in base al ruolo di Azure impostato in ciascun contesto del tenant del cliente.

  • Verifica se il cliente ha rimosso le tue autorizzazioni AOBO. Le autorizzazioni vengono impostate per impostazione predefinita al momento del provisioning del piano di Azure. Se vengono rimossi, vedere Reintegrare i privilegi di amministratore per le sottoscrizioni di Azure Cloud Solution Provider (CSP) di un cliente.

  • Verificare di disporre dell'accesso amministratore per l'intero giorno.

  • Verificare di aver esaminato le colonne corrette nei file di riconciliazione. Per altre informazioni, vedere Fatturazione del piano di Azure: Informazioni sul file di riconciliazione della fattura.

Informazioni sugli scenari con più partner

Per PEC, è importante solo che il partner di transazione imposti una delle opzioni di autorizzazione disponibili. Per il modello indiretto, potrebbe essere il provider o il rivenditore o entrambi.

Un altro partner che imposta AOBO o altre autorizzazioni aggiuntive e che imposta il controllo degli accessi in base al ruolo di Azure per gli utenti con autorizzazioni di controllo degli accessi in base al ruolo di Azure non influisce sulla PEC per il partner che effettua la transazione.

Nella tabella seguente, MPN1 è un provider indiretto, MPN2 è il rivenditore indiretto collegato alla transazione come rivenditore di record. MPN3 è un altro partner CSP (rivenditore diretto o indiretto):

Partner commerciale (BillTo) Azure RBAC (per l'utente o Lighthouse con ruolo idoneo per la PEC) AOBO (Ruolo Idoneo per la PEC) PEC
del produttore 1 del produttore 1 Non disponibile Sì
del produttore 1 Non disponibile del produttore 1 Sì
del produttore 1 del produttore 2 Non disponibile Sì
del produttore 1 Non disponibile del produttore 2 Sì
del produttore 1 del produttore 3 del produttore 1 Sì
del produttore 1 del produttore 1 del produttore 3 Sì
del produttore 1 del produttore 1 del produttore 2 Sì
del produttore 1 del produttore 2 del produttore 1 Sì
del produttore 1 del produttore 2 del produttore 3 Sì
del produttore 1 del produttore 3 del produttore 2 Sì
del produttore 1 del produttore 3 Non disponibile NO
del produttore 1 Non disponibile del produttore 3 NO
del produttore 1 Non disponibile Non disponibile NO
del produttore 1 del produttore 3 del produttore 3 NO

Informazioni sui trasferimenti delle sottoscrizioni di Azure

Quando un partner trasferisce una sottoscrizione di Azure da o a un altro partner, non vengono modificate autorizzazioni per questo trasferimento.

Pertanto, se AOBO o un altro modello di autorizzazione è stato utilizzato prima del trasferimento, con le autorizzazioni impostate per il "partner di transazione" precedente, le autorizzazioni puntano ancora al partner precedente dopo il trasferimento. Ma ora un altro partner diventa il "partner di transazione".

Per i trasferimenti di sottoscrizioni di Azure, è consigliabile che il nuovo partner di destinazione aggiunga permessi, come Azure RBAC, prima del trasferimento. Possono farlo senza influire sul PEC del vecchio partner fino al trasferimento.

Informazioni sugli aggiornamenti di PartnerID

Il Centro per i partner consente di modificare il PartnerID associato alla registrazione CSP. L'aggiornamento del PartnerID a un altro ID percorso del programma Microsoft AI Cloud Partner all'interno della stessa organizzazione globale del Programma Microsoft AI Cloud Partner (un altro ID percorso del programma Microsoft AI Cloud Partner con lo stesso ID globale del Programma Microsoft AI Cloud Partner) non influisce sul PEC.

Quando il PartnerID viene modificato in un ID di posizione in un'altra organizzazione del Programma Microsoft AI Cloud Partner, il PEC potrebbe tuttavia essere influenzato. In questo caso, e quando la PEC risulta mancante, si consiglia di contattare l'assistenza. Indica che di recente hai rimappato la tua iscrizione CSP a un'altra organizzazione del Microsoft AI Cloud Partner Program.

Verificare le autorizzazioni di amministratore per conto di (AOBO)

Quando un partner crea una sottoscrizione del piano di Azure per un cliente, AOBO viene impostato sotto forma di entità esterna. L'entità principale esterna eredita le autorizzazioni di proprietario per la sottoscrizione di Azure. Le autorizzazioni AOBO indicano che un determinato gruppo nel tenant del Centro per i partner CSP (agenti di amministrazione) eredita le autorizzazioni.

L'entità esterna, come illustrato nel portale di Azure, non include dettagli sul gruppo a cui è associato nel tenant del partner specifico.

Quando si visualizza l'entità esterna nel portale di Azure, viene mostrato un nome partner, ad esempio "Entità esterna per 'Contoso'", ma "Contoso" è solo il nome visualizzato del tenant di Microsoft Entra del partner e non è univoco.

Screenshot che mostra nomi visualizzati non univoci.

Usare AZ PowerShell o l'interfaccia della riga di comando di Azure per verificare con certezza del 100% che l'AOBO sia impostato correttamente, che punti al gruppo corretto e nel tenant CSP corretto.

Passaggio 1- Identificare gli objectID dei gruppi di agenti del partner di transazione

  • Tramite portale di Azure: i partner possono accedere al portale di Azure nel proprio tenant e cercare i rispettivi gruppi in Gruppi ID > di Microsoft Entra. ObjectID viene visualizzato a destra del nome del gruppo.

Screenshot che mostra come ottenere un ID oggetto dall'interfaccia del portale di Azure.

Prima di usare Azure Cloud Shell, è necessario configurare un account di archiviazione. Questo account comporta un piccolo costo mensile nella sottoscrizione di Azure disponibile nel contesto tenant. È possibile eliminare la condivisione dopo i passaggi successivi.

Nota

I moduli Azure AD e MSOnline PowerShell sono deprecati a partire dal 30 marzo 2024. Per maggiori informazioni, consultare l'aggiornamento sulla disattivazione. Dopo questa data, il supporto per questi moduli è limitato all'assistenza alla migrazione a Microsoft Graph PowerShell SDK e alle correzioni di sicurezza. I moduli deprecati continueranno a funzionare fino al 30 marzo 2025.

È consigliabile eseguire la migrazione a Microsoft Graph PowerShell per interagire con Microsoft Entra ID (in precedenza Azure AD). Per domande comuni sulla migrazione, consultare le Domande frequenti sulla migrazione. Nota: le versioni 1.0.x di MSOnline potrebbero subire interruzioni dopo il 30 giugno 2024.

Assicurarsi di avere installato e aggiornato i moduli seguenti alla versione più recente:

Se necessario, usare quanto segue cmdlets da Windows PowerShell per installare questi moduli:

Install-Module -Name AzureAD -Force

Install-Module -Name Az -AllowClobber -Force

Prima di tutto, connettersi al tenant del Centro per i partner con l'account utente del Centro per i partner e ottenere gli ID oggetto del gruppo AdminAgents e HelpdeskAgents:

Connect-AzureAD -TenantDomain CSPtenantname.onmicrosoft.com

Accedere con le credenziali del Centro per i partner:

Screenshot che mostra un esempio di Shell di una connessione al Centro per i partner.

Interrogare le informazioni sui gruppi di agenti:

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

Viene visualizzato il ObjectID nome dei gruppi insieme ai relativi nomi:

Screenshot che mostra una finestra della shell con un esempio dell'ObjectID dei gruppi.

Nota

Se non ottieni un risultato, assicurati di esserti connesso al tuo account del Centro partner.

Nota

I rivenditori indiretti non visualizzano un gruppo SalesAgents. Questo passaggio deve essere eseguito una sola volta, poiché AOBO in ogni tenant del cliente utilizza gli stessi ID.

Passaggio 2: Confrontare gli OBJECTID con quelli usati dall'entità esterna

È importante usare il TenantID come valore per il parametro tenant (anziché il nome di dominio del tenant) con un account utente che:

  • Ha accesso a più directory e tenant, ad esempio l'account utente del Centro per i partner, oppure
  • È stato aggiunto come ospite a più inquilini.

Pertanto, è necessario il TenantID per il cliente.

  • Tramite il portale di Azure: è possibile ottenere facilmente il TenantID dall'elenco dei clienti nel Centro per i partner. L'ID tenant è etichettato come ID Microsoft:

    Screenshot che mostra l'ID Microsoft come tenantId.

  • Tramite PowerShell: connettersi alla sottoscrizione di Azure del cliente con credenziali valide. Le credenziali devono avere l'autorizzazione per leggere la sottoscrizione di Azure e AzureAD del tenant del cliente:

    Connect-AzAccount -Tenant $CustomerTenantID
    • Leggere le assegnazioni di ruolo per il Principale esterno delle sottoscrizioni di Azure del cliente Azure:
    Get-AzRoleassignment | ? {$_.DisplayName -like "Foreign*"}

    Screenshot che mostra un'assegnazione di ruolo di esempio della shell.

    • L'ObjectID risultante deve corrispondere all'ObjectID del gruppo AdminAgent o HelpDeskAgent identificato nel passaggio 1.

Riepilogo

Ogni aspetto deve corrispondere per ricevere la PEC tramite AOBO:

  • La sottoscrizione di Azure del cliente ha un principale esterno con un'assegnazione idonea di ruolo RBAC di Azure.
  • L'ObjectID del gruppo usato dall'entità esterna fa riferimento all'ObjectID del gruppo AdminAgent o HelpdeskAgent nel tenant partner.
  • Il "Partner tenant" si riferisce al tenant partner con fatturazione diretta. Nel modello indiretto, si riferisce al provider indiretto o al tenant partner rivenditore indiretto.

Script di esempio

Questa sezione contiene script di esempio che consentono di raccogliere le informazioni tra più sottoscrizioni e archiviarle in un oggetto . File CSV. Questi script sono concepiti come esempi e forniti così come sono senza supporto. Anche se gli script non apportano modifiche nell'installazione, devono essere testati accuratamente e la personalizzazione potrebbe essere necessaria per lo scenario di partner/cliente concreto.

  • Presentazione dei dettagli di AOBO per un singolo cliente: questo esempio usa i moduli Microsoft Entra ID e 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
}
}
  • Elenco dei dettagli di AOBO per più clienti: questo codice è solo a scopo illustrativo.
    • Ottenere un elenco di tutte le sottoscrizioni di clienti CSP e di tutte le entità esterne e identificare se esiste una mancata corrispondenza. Questo codice può essere usato anche per raccogliere informazioni per il supporto.
    • Controllare quali sottoscrizioni di Azure (diritti del piano di Azure) sono state vendute e quali sono accessibili con le credenziali correnti.
    • Per i rivenditori indiretti, questo script funziona anche. Ma tutte le sottoscrizioni avrebbero la nota "non venduta" anche se sono il partner del record per questa vendita.
### 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
}
}
}

  • L'output di questo script può quindi essere formattato come segue:

    Screenshot che mostra un esempio di formato di output.

Analogamente ad AOBO, Azure Lighthouse consente ai gruppi di utenti nel tenant di gestione (partner) di ereditare le autorizzazioni delegate nella sottoscrizione di Azure del cliente. La differenza è che supporta una definizione più granulare dei gruppi e dei livelli di autorizzazione rispetto ad AOBO.

Per questo modello di autorizzazione, è più semplice verificare se è stato configurato correttamente usando l'interfaccia utente del portale di Azure. Solo il partner può fornire la verifica completa che la configurazione di Azure Lighthouse sia corretta.

La procedura seguente descrive come identificare i clienti a cui sono state delegate in modo permanente le autorizzazioni del ruolo Controllo degli accessi in base al ruolo di Azure e a quali gruppi. È quindi possibile verificare se l'utente con l'associazione Controllo degli accessi in base al ruolo di Azure è un membro di tali gruppi.

Passaggio 1: Controllare le deleghe Lighthouse sui clienti

Verificare che le autorizzazioni applicabili utilizzino ruoli di controllo degli accessi basati su ruoli di Azure idonei per la PEC.

  • Aprire portale di Azure (con un utente dal tenant di gestione del partner). Cercare quindi "Lighthouse" e selezionare Clienti personali.

    Screenshot che mostra un esempio di Lighthouse dei servizi di Azure.

  • Nella panoramica del cliente scegliere Deleghe sul lato sinistro. In questo modo verrà visualizzato l'elenco delle risorse (sottoscrizioni o gruppi di risorse) in cui è stato fornito l'accesso delegato:

    Screenshot che mostra la pagina Deleghe.

  • Aprire le deleghe nella colonna di destra in Assegnazioni di ruolo per vedere quale gruppo di utenti nel partner/tenant di gestione eredita ogni tipo di autorizzazioni (vedere la colonna Ruolo ). È anche possibile verificare se tali autorizzazioni sono permanenti (vedere la colonna "Tipo di accesso):

    Screenshot che mostra la pagina Assegnazioni di ruolo.

Passaggio 2: Controllare l'appartenenza al gruppo

Selezionare il nome visualizzato del gruppo. Facendo ciò, si aprono i dettagli del gruppo. Selezionare "Membri" per controllare quale utente ha configurato il controllo degli accessi basato sui ruoli di Azure ed è membro del rispettivo gruppo.

Screenshot che mostra l'appartenenza al gruppo.

Passaggio 3 - Verificare se l'utente ha configurato Azure PAL

Solo l'utente che ha impostato Azure PAL può controllare l'assegnazione di Azure PAL. Nessun altro utente amministratore può farlo. Per altre informazioni su come l'utente può verificare se Azure PAL è stato impostato, con l'interfaccia utente o PowerShell, vedere Collegare un account Azure a un PartnerID.

Nota

Azure PAL deve usare un PartnerID che fa parte della stessa organizzazione Microsoft AI Cloud Partner Program che è il partner di transazione per questa sottoscrizione di Azure. Nel modello indiretto, può essere il PartnerID del provider o il rivenditore specifico collegato a questa vendita.

Passaggio 4 - Verificare la presenza di assegnazioni di gruppi a termine temporale

Poiché l'appartenenza al gruppo potrebbe non essere permanente, verificare se il gruppo è stato abilitato per la gestione degli accessi con privilegi. Guarda dove si trova "Accesso con privilegi" sul lato sinistro, sotto "Attività", nelle impostazioni del gruppo. Se true, controllare se l'utente ha un'assegnazione attiva e l'intervallo di tempo per questa assegnazione.

Nota

Poiché quando l'assegnazione "ora di fine" è raggiunta, un utente viene rimosso automaticamente dal gruppo, la PEC andrebbe persa per gli utenti che avevano impostato Azure RBAC. Analogamente, il PEC verrebbe concesso solo dopo l'assegnazione "ora di inizio".

Screenshot che mostra un gruppo di accesso con privilegi.

Verificare l'assegnazione di un singolo utente e Azure PAL

In alcuni casi, potrebbe essere più adatto lavorare con singoli account utente con autorizzazioni per le sottoscrizioni di Azure. Questi account possono essere account utente guest (da qualsiasi tenant) o account utente creati nel tenant cliente o principal di servizio.

Quando si usano singoli account utente come veicolo per ottenere PEC, il controllo comporta la revisione delle autorizzazioni assegnate nella gestione delle sottoscrizioni di Azure per l'utente e la verifica del controllo degli accessi in base al ruolo di Azure impostato correttamente dall'utente. Quando si usa un'entità servizio, il controllo del controllo degli accessi in base al ruolo di Azure viene eseguito tramite PowerShell.

Passaggio 1: Esaminare le autorizzazioni nella gestione delle sottoscrizioni di Azure

  • Apri il portale di Azure. Assicurarsi di aver eseguito l'accesso come utente con un ruolo Azure RBAC che abbia almeno l'accesso in lettura alla sottoscrizione in questione.

  • Cercare "Sottoscrizioni" nella barra di ricerca per aprire i dettagli della sottoscrizione:

    Screenshot che mostra la pagina dei dettagli dell'abbonamento.

  • Passare a "Controllo di accesso (IAM)" nei dettagli della sottoscrizione. Selezionare quindi "Assegnazioni di ruolo" per esaminare gli utenti che hanno accesso a livello di abbonamento e verificare se la colonna "Ruolo" mostra ruoli Azure RBAC idonei per PEC. Se le autorizzazioni sono state impostate a livello di gruppo di risorse, la stessa visualizzazione "Controllo di accesso (IAM)" è disponibile anche all'interno di un gruppo di risorse.

Nota

** È possibile concedere autorizzazioni anche a un gruppo di utenti, dove è necessario verificare l'appartenenza al gruppo dell'utente per il quale è impostato il controllo degli accessi in base al ruolo di Azure.

Screenshot che mostra il controllo di accesso della sottoscrizione di Azure.

Passaggio 2: assicurarsi che le autorizzazioni siano permanenti e che non vengano applicate assegnazioni negate

Anche se potrebbe sembrare che gli utenti abbiano accesso, le loro autorizzazioni potrebbero essere comunque temporanee o bloccate tramite assegnazioni Nega.

L'uso dell'assegnazione del ruolo di controllo degli accessi di Azure tramite Privileged Identity Management (PIM) potrebbe essere limitato nel tempo. Sebbene sia possibile che gli utenti abbiano l'autorizzazione, potrebbero esistere solo per un breve periodo di tempo. Per verificare che l'assegnazione del ruolo RBAC di Azure sia permanente, controllare l'amministrazione di PIM nel portale di Azure. In particolare, verificare dove i criteri PIM gestiscono le risorse di Azure nella sottoscrizione e se l'utente è soggetto a criteri.

Screenshot che mostra che la sottoscrizione di Azure non è gestita tramite PIM.

Inoltre, l'elenco delle autorizzazioni potrebbe mostrare all'utente le autorizzazioni per la sottoscrizione, ma potrebbero esserci assegnazioni di rifiuto che impediscono comunque all'utente di accedere a un elemento. In "Controllo di accesso (IAM)" selezionare la scheda di assegnazione Nega per verificare se le assegnazioni Nega sono applicabili.

Screenshot che mostra la pagina dei risultati Nega assegnazioni.

Nota

Per completezza, i partner devono anche verificare che nei gruppi di risorse non esistano assegnazioni di negazione nell'ambito della sottoscrizione.

Passaggio 3 - Verificare se l'utente ha configurato Azure PAL

Solo l'utente che ha configurato Azure PAL può controllare le assegnazioni di Azure PAL. Nessun altro utente amministratore può farlo. Per altre informazioni su come l'utente può verificare se Azure PAL è stato impostato, vedere Collegare un account Azure a un PartnerID.

Nota

Azure PAL deve usare un PartnerID che fa parte della stessa organizzazione Microsoft AI Cloud Partner Program, che è il partner di transazione per questa sottoscrizione di Azure. Nel modello indiretto, può essere il PartnerID del provider o il PartnerID del rivenditore associato a questa vendita.

Contenuto correlato

  • Last updated on