Condividi tramite

Guida alla risoluzione dei problemi relativi al credito ottenuto dai partner

  • Articolo

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

Scenari comuni di risoluzione dei problemi

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. Informazioni su chi può ricevere il PEC, come viene calcolato e come viene pagato.

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

Prerequisiti

Se si verificano problemi con pec, ad esempio l'accesso o le informazioni mancanti, iniziare controllando gli elementi seguenti.

Nota

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

  • Assicurarsi di esaminare la fattura G (nuova esperienza commerciale) e il file di riconciliazione. 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 di terze parti non sono idonei.

  • Verificare che l'utente (o il rivenditore indiretto impostato come rivenditore di record nel piano di Azure) disponga di un ruolo Amministra per conto di (AOBO) o di Controllo degli accessi in base al ruolo di Azure per la sottoscrizione/gruppo di risorse/risorsa. In alternativa:

    • Se si usa Azure Lighthouse, assicurarsi che l'ID partner sia stato collegato con almeno un account utente. Verificare anche che abbia accesso alla sottoscrizione o al gruppo di risorse del cliente.
    • Se si usa un'associazione di Controllo degli accessi in base al ruolo di Azure, assicurarsi che l'utente abbia un ruolo idoneo per pec e controllo degli accessi in base al ruolo di Azure impostato in ogni contesto del tenant del cliente.

  • Verificare se il cliente ha rimosso le autorizzazioni AOBO. Le autorizzazioni sono state impostate per impostazione predefinita al momento del provisioning del piano di Azure. Se sono stati rimossi, vedere Reinstate admin privileges for a customer's Azure Cloud Solution Provider (CSP) subscriptions (Reinstate admin privileges for a customer's Azure Cloud Solution Provider( CSP).

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

Scenari multipartner

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

Un'altra impostazione partner aggiuntiva di AOBO o altre autorizzazioni e l'impostazione di controllo degli accessi in base al ruolo aggiuntivo di Azure per gli utenti con autorizzazioni di controllo degli accessi in base al ruolo di Azure non influiscono sul pec per il partner di transazione.

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

Partner transazioni (BillTo) Controllo degli accessi in base al ruolo di Azure (per l'utente o Lighthouse con ruolo idoneo per la pec) AOBO (ruolo idoneo per la pec) Credito ottenuto dal partner
MPN1 MPN1 N/D Sì
MPN1 N/D MPN1 Sì
MPN1 MPN2 N/D Sì
MPN1 N/D MPN2 Sì
MPN1 MPN3 MPN1 Sì
MPN1 MPN1 MPN3 Sì
MPN1 MPN1 MPN2 Sì
MPN1 MPN2 MPN1 Sì
MPN1 MPN2 MPN3 Sì
MPN1 MPN3 MPN2 Sì
MPN1 MPN3 N/D No
MPN1 N/D MPN3 No
MPN1 N/D N/D No
MPN1 MPN3 MPN3 No

Trasferimenti di 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 usato prima del trasferimento, con autorizzazioni impostate per il vecchio "partner transazioni", le autorizzazioni punteranno comunque 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 autorizzazioni, ad esempio il controllo degli accessi in base al ruolo di Azure, prima del trasferimento. Possono farlo senza influire sul PEC del vecchio partner fino al trasferimento.

Aggiornamenti di PartnerID

Il Centro per i partner consente di modificare l'ID partner 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, tuttavia, il pec potrebbe essere interessato. In questa istanza, e quando pec risulta mancante, è consigliabile contattare il supporto tecnico (menzionare che di recente è stato eseguito il mapping della registrazione CSP a un'organizzazione diversa del Programma Microsoft AI Cloud Partner).

Come verificare le autorizzazioni AOBO

Quando un partner crea una sottoscrizione di Piano di Azure per un cliente, AOBO viene impostato sotto forma di "entità esterna. L'entità 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) erediterà tali autorizzazioni.

L'entità esterna, come illustrato nella portale di Azure, non include dettagli sul gruppo a cui viene eseguito il mapping nel tenant partner specifico.

Quando si visualizza l'entità esterna nella portale di Azure, viene visualizzato 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.

Nomi visualizzati non univoci.

È necessario usare AZ PowerShell o l'interfaccia della riga di comando di Azure per verificare con certezza del 100% che L'AOBO sia impostato correttamente, indicando il gruppo corretto 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 DI ID > Microsoft Entra. ObjectID viene visualizzato a destra del nome del gruppo.

Recupero dell'ID oggetto dall'interfaccia portale di Azure.

Prima di usare Azure Cloud Shell, è necessario configurare un account di archiviazione. Questo account comporta un costo mensile ridotto nella sottoscrizione di Azure disponibile nel contesto del 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, leggere l'aggiornamento sulla deprecazione. 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:

Esempio di shell della connessione al Centro per i partner.

Eseguire una query sulle informazioni sui gruppi di agenti:

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

L'oggetto ObjectID dei gruppi verrà visualizzato insieme ai relativi nomi:

Esempio di shell di ObjectID di gruppi.

Nota

Se non si ottiene un risultato, assicurarsi di aver eseguito la connessione all'account del Centro per i partner.

Nota

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

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

È importante usare l'ID tenant come valore per il parametro del tenant (anziché il nome di dominio del tenant) con un account utente che: - ha accesso a più directory/tenant, ad esempio l'account utente del Centro per i partner o - è stato aggiunto come guest a più tenant.

Pertanto, è necessario l'ID tenant per il cliente specificato.

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

    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 l'entità esterna delle sottoscrizioni di Azure del cliente:
    Get-AzRoleassignment | ? {$_.DisplayName -like "Foreign*"}

    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 il PEC tramite AOBO:

  • La sottoscrizione di Azure del cliente ha un'entità esterna con un'assegnazione di ruolo di Controllo degli accessi in base al ruolo di Azure idonea.
  • L'ObjectID del gruppo usato dall'entità esterna fa riferimento all'ObjectID del gruppo AdminAgent o HelpdeskAgent nel tenant partner.
  • "Tenant partner" indica il tenant partner con fatturazione diretta. Nel modello indiretto significa il provider indiretto o il 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 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
}
}
}

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

    Esempio di formato di output.

Come verificare le autorizzazioni di Azure Lighthouse e Azure PAL

Analogamente a 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 consente una definizione più granulare di gruppi e livelli di autorizzazione rispetto a AOBO.

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

I passaggi seguenti descrivono come identificare per quali clienti le autorizzazioni del ruolo controllo degli accessi in base al ruolo di Azure sono state delegate in modo permanente e a quali gruppi. È quindi possibile verificare se l'utente con l'associazione controllo degli accessi in base al ruolo di Azure è membro di tali gruppi.

Passaggio 1: Controllare le deleghe Lighthouse sui clienti

Verificare che le deleghe applicabili usino ruoli controllo degli accessi in base al ruolo 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.

    Esempio di Lighthouse per i servizi di Azure.

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

    Pagina Delle deleghe.

  • Aprire le deleghe nella colonna destra in "Assegnazioni di ruolo" per vedere quale gruppo di utenti nel tenant partner/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):

    Pagina Assegnazioni di ruolo

Passaggio 2: Controllare l'appartenenza al gruppo

Selezionare il nome visualizzato del gruppo. A tale scopo, vengono visualizzati i dettagli del gruppo. Selezionare "Membri" per controllare quale utente ha impostato il controllo degli accessi in base al ruolo di Azure ed è membro del rispettivo gruppo:

Appartenenza a un gruppo.

Passaggio 3: Controllare 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, tramite l'interfaccia utente o PowerShell, vedere Ricerca per categorie spiegare al cliente il collegamento all'amministratore del partner? in Collegare un account Azure a un PARTNERID.

Nota

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

Passaggio 4- Verificare la presenza di assegnazioni di gruppi associati a tempo

Poiché l'appartenenza al gruppo potrebbe non essere permanente, verificare se il gruppo è stato abilitato per la gestione degli accessi con privilegi. Cercare dove "Accesso con privilegi" sul lato sinistro in "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é l'assegnazione "ora di fine" è quando un utente viene rimosso automaticamente dal gruppo, la pec andrebbe persa per gli utenti che avevano impostato il controllo degli accessi in base al ruolo di Azure. Analogamente, il PEC verrebbe concesso solo dopo l'assegnazione "ora di inizio".

Gruppo di accesso con privilegi.

Come verificare l'assegnazione di singoli utenti e l'elenco di accesso alla rete di Azure

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 del cliente o nelle entità servizio.

Quando si usano singoli account utente come veicolo per ottenere la pec, il controllo implica solo la revisione delle autorizzazioni assegnate nella gestione delle sottoscrizioni di Azure per l'utente e la verifica che l'utente abbia impostato correttamente il controllo degli accessi in base al ruolo di Azure. Quando si usa un'entità servizio, il controllo del controllo degli accessi in base al ruolo di Azure deve essere 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 ruolo Controllo degli accessi in base al ruolo di Azure con almeno l'accesso in lettura alla sottoscrizione in questione.

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

    Pagina dei dettagli della sottoscrizione.

  • 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 sottoscrizione e se la colonna "Ruolo" mostra i ruoli controllo degli accessi in base al ruolo di Azure idonei per la 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

È anche possibile concedere autorizzazioni a un gruppo di utenti in cui l'appartenenza al gruppo dell'utente con il controllo degli accessi in base al ruolo di Azure deve essere verificata anche.

Controllo dell'accesso.

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 autorizzazioni potrebbero essere ancora temporanee o bloccate tramite assegnazioni di rifiuto.

L'uso dell'assegnazione di ruolo controllo degli accessi in base al ruolo di Azure con Privileged Identity Management (PIM) potrebbe essere associata al tempo. Sebbene sia possibile che gli utenti abbiano l'autorizzazione, potrebbero esistere solo per un breve periodo di tempo. Per verificare che l'assegnazione di ruolo controllo degli accessi in base al ruolo di Azure sia permanente, controllare l'amministrazione di PIM in portale di Azure. In particolare, controllare la posizione in cui le risorse di Azure nella sottoscrizione vengono gestite dai criteri PIM e se l'utente è soggetto a criteri.

La sottoscrizione di Azure non viene 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 Nega assegnazione per verificare se si applicano le assegnazioni Nega:

Nega assegnazioni.

Nota

Per completezza, i partner devono anche verificare che nei gruppi di risorse non esistano assegnazioni Nega all'interno della sottoscrizione.

Passaggio 3: Controllare 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 che Sia stato impostato Azure PAL, vedere Collegare un account Azure a un PartnerID.

Nota

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

Contenuto correlato