Share via

Guía para la solución de problemas relacionados con el crédito obtenido por el asociado

  • Artículo

Roles adecuados: Administrador global | Administrador de control de usuarios | Agente administrador | Administrador de facturación | Agente de ventas

Solución de problemas de escenarios comunes

Con la nueva experiencia comercial de Azure, los partners pueden recibir descuentos a través del crédito obtenido por los partners (PEC) para los servicios administrados. PEC solo se concede a los asociados con permisos aptos. Averigüe quién es elegible para PEC, cómo se calcula y cómo se paga.

En este artículo se proporcionan instrucciones básicas de solución de problemas si no se concede PEC.

Requisitos previos

Si tiene problemas con PEC, como el acceso o la información que falta, empiece comprobando los siguientes elementos.

Nota:

Solo los proveedores indirectos y los asociados de factura directa pueden ganar PEC.

  • Asegúrese de que está viendo la factura de G (nueva experiencia comercial) y el archivo de conciliación. El plan de Azure y pec no se muestran en la factura D (heredado) ni en el archivo de conciliación.

  • Confirme que el contrato de Microsoft AI Cloud Partner Program está activo.

  • Confirme que la oferta es apta. (Las ofertas heredadas de Azure, las instancias reservadas de Azure, los planes de ahorro de Azure, las máquinas virtuales de Azure SPOT y los productos de terceros no son aptas).

  • Confirme que (o el revendedor indirecto establecido como revendedor de registro en el plan de Azure) tiene un rol válido Administración ister en nombre de (AOBO) o de control de acceso basado en rol (Azure RBAC) de Azure para el rol de suscripción, grupo de recursos o recurso. O bien:

    • Si usa Azure Lighthouse, asegúrese de que el PartnerID se ha vinculado con al menos una cuenta de usuario. Compruebe también que tiene acceso a la suscripción o grupo de recursos de ese cliente.
    • Si usa una asociación de RBAC de Azure, asegúrese de que el usuario tiene un rol apto para PEC y Azure RBAC establecido en cada contexto de inquilino del cliente.

  • Compruebe si el cliente ha quitado los permisos de AOBO. Los permisos se establecieron de forma predeterminada cuando se aprovisionó el plan de Azure. Si se han quitado, consulte Restablecer privilegios de administrador para las suscripciones de Azure Proveedor de soluciones en la nube (CSP) de un cliente.

  • Confirme que tiene acceso de administrador durante todo el día.

  • Confirme que está revisando las columnas correctas en los archivos de conciliación. Para más información, consulte Facturación del plan de Azure: Acerca del archivo de conciliación de facturas.

Escenarios multiparte

Para PEC, solo es importante que el asociado de transacción haya establecido cualquiera de las opciones de permisos disponibles. Para el modelo indirecto, podría ser el proveedor o el revendedor, o ambos.

Otra configuración de asociado adicional AOBO u otros permisos y establecer RBAC de Azure adicional para los usuarios con permisos de RBAC de Azure no afectará al PEC para el asociado de transacción.

Vea la siguiente tabla. MPN1 es un proveedor indirecto, MPN2 es el revendedor indirecto vinculado a la transacción como revendedor de registro y MPN3 es otro asociado de CSP (directo u otro revendedor indirecto):

Asociado de transacción (BillTo) RBAC de Azure (para usuario o Lighthouse con rol apto para PEC) AOBO (rol apto para PEC) PEC
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

Transferencias de suscripciones de Azure

Cuando un asociado transfiere una suscripción de Azure de o a otro asociado, no se cambian permisos para esta transferencia.

Por lo tanto, si se usó AOBO u otro modelo de permisos antes de la transferencia, con los permisos establecidos para el antiguo "asociado de transacción", los permisos seguirán apuntando al asociado antiguo después de la transferencia. Pero ahora, otro asociado se convierte en el "asociado de transacción".

Para las transferencias de suscripciones de Azure, es aconsejable que el nuevo asociado de destino agregue permisos, como RBAC de Azure, antes de la transferencia. Pueden hacerlo de forma segura sin afectar al PEC del antiguo socio hasta la transferencia.

Actualizaciones de PartnerID

El Centro de partners permite cambiar el PartnerID asociado a la inscripción de CSP. La actualización del PartnerID a otro identificador de ubicación del Programa de partners en la nube de Microsoft AI dentro de la misma organización global del Programa de partners en la nube de Microsoft AI (otro identificador de ubicación del Programa de partners en la nube de Microsoft AI en el mismo id. global del Programa de partners en la nube de Microsoft) no afecta al PEC.

Sin embargo, cuando el PartnerID se cambia a un identificador de ubicación en otra organización del Programa de partners en la nube de Microsoft AI, es posible que el PEC se vea afectado. En este caso, y cuando el PEC resulta que falta, se recomienda ponerse en contacto con el soporte técnico (mencione que recientemente ha reasignado la inscripción de CSP a otra organización del Programa microsoft AI Cloud Partner Program).

Comprobación de los permisos de AOBO

Cuando un asociado crea una suscripción de Plan de Azure para un cliente, AOBO se establece en forma de "entidad de seguridad externa". La entidad de seguridad externa hereda los permisos de propietario en la suscripción de Azure. Los permisos de AOBO significan que un determinado grupo del inquilino del Centro de partners de CSP (Administración Agentes) heredará esos permisos.

La entidad de seguridad externa, como se ve en Azure Portal, no incluye detalles sobre el grupo al que se asigna en el inquilino de asociado específico.

Cuando se ve la entidad de seguridad externa en Azure Portal, se muestra un nombre de asociado, como "Entidad de seguridad externa para "Contoso", pero "Contoso" es solo el nombre para mostrar del inquilino de Microsoft Entra del asociado y no es único.

Nombres para mostrar no únicos.

El uso de AZ PowerShell o la CLI de Azure es necesario para comprobar con la certeza del 100 % de que el AOBO está configurado correctamente, apuntando al grupo correcto en el inquilino de CSP correcto.

Paso 1: Identificación de los identificadores de objeto de los grupos de agentes del asociado de transacción

  • A través de Azure Portal: los partners pueden iniciar sesión en Azure Portal en su propio inquilino y buscar los grupos respectivos en Grupos de identificadores >de Microsoft Entra. ObjectID se muestra a la derecha del nombre del grupo.

Obtención del identificador de objeto de la interfaz de Azure Portal.

Antes de usar Azure Cloud Shell, deberá configurar una cuenta de almacenamiento. Esta cuenta incurrirá en un pequeño costo mensual en la suscripción de Azure disponible en el contexto del inquilino. Puede eliminar el recurso compartido después de los pasos que se indican a continuación.

Nota:

Los módulos de PowerShell de Azure AD y MSOnline están en desuso a partir del 30 de marzo de 2024. Para obtener más información, lea la actualización de desuso. Desde esta fecha, el soporte de estos módulos se limita a la asistencia de migración al SDK de PowerShell de Microsoft Graph y a las correcciones de seguridad. Los módulos en desuso seguirán funcionando hasta el 30 de marzo de 2025.

Se recomienda migrar a PowerShell de Microsoft Graph para interactuar con Microsoft Entra ID (anteriormente Azure AD). Para preguntas comunes sobre la migración, consulte las Preguntas más frecuentes sobre migración. Nota: versiones 1.0.x de MSOnline pueden experimentar interrupciones después del 30 de junio de 2024.

Asegúrese de que tiene instalados y actualizados los siguientes módulos a la versión más reciente:

Si es necesario, use lo siguiente cmdlets en las ventanas de PowerShell para instalar estos módulos:

Install-Module -Name AzureAD -Force

Install-Module -Name Az -AllowClobber -Force

En primer lugar, conéctese al inquilino del Centro de partners con su cuenta de usuario del Centro de partners y obtenga los identificadores de objeto del grupo Administración Agents y HelpdeskAgents:

Connect-AzureAD -TenantDomain CSPtenantname.onmicrosoft.com

Inicie sesión con sus credenciales del Centro de partners:

Ejemplo de shell de conexión del Centro de partners.

Consulte la información sobre los grupos de agentes:

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

Los ObjectID grupos se mostrarán junto con sus nombres:

Ejemplo de Shell de ObjectID de grupos.

Nota:

Si no obtiene un resultado, asegúrese de que se ha conectado a su cuenta del Centro de partners.

Nota:

Los revendedores indirectos no verán un grupo SalesAgents. Este paso solo debe realizarse una vez, ya que AOBO en cada inquilino del cliente usará los mismos identificadores.

Paso 2: Comparar objectID con los usados por la entidad de seguridad externa

Es importante usar tenantID como valor para el parámetro tenant (en lugar del nombre de dominio del inquilino) con una cuenta de usuario que: tiene acceso a varios directorios o inquilinos, como la cuenta de usuario del Centro de partners o , se ha agregado como invitados a varios inquilinos.

Por lo tanto, necesita tenantID para el cliente determinado.

  • A través de Azure Portal: puede obtener el TenantID fácilmente de la lista de clientes en el Centro de partners. El id. de inquilino está etiquetado como "Id. de Microsoft":

    Identificador de Microsoft como tenantId.

  • Mediante PowerShell: Conectar a la suscripción de Azure del cliente con credenciales válidas. Las credenciales deben tener permiso para leer la suscripción de Azure y AzureAD del inquilino del cliente:

    Connect-AzAccount -Tenant $CustomerTenantID
    • Lea las asignaciones de roles para la entidad de seguridad externa de las suscripciones de Azure del cliente:
    Get-AzRoleassignment | ? {$_.DisplayName -like "Foreign*"}

    Asignación de roles de ejemplo de Shell.

    • El ObjectID resultante debe coincidir con el ObjectID del grupo Administración Agent o HelpDeskAgent identificado en el paso 1.

Resumen

Cada aspecto debe coincidir para recibir PEC a través de AOBO:

  • La suscripción de Azure del cliente tiene una entidad de seguridad externa con una asignación de roles de RBAC de Azure válida.
  • El ObjectID del grupo utilizado por la entidad de seguridad externa hace referencia al ObjectID del grupo Administración Agent o HelpdeskAgent en el inquilino del asociado.
  • "Inquilino de partner" significa el inquilino de partner de factura directa. En el modelo indirecto, significa el proveedor indirecto o el inquilino de partner revendedor indirecto.

Muestras de scripts

Esta sección contiene scripts de ejemplo que pueden ayudar a recopilar la información en varias suscripciones y almacenarlos en . Archivo CSV. Estos scripts están diseñados como ejemplos y se proporcionan tal cual sin soporte técnico. Aunque los scripts no realizan modificaciones en la configuración, deben probarse exhaustivamente y es posible que la personalización sea necesaria para el escenario concreto de asociado o cliente.

  • Enumeración de los detalles de AOBO para un solo cliente: en este ejemplo se usa el identificador de Entra de Microsoft y los módulos de 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
}
}
  • Enumerar los detalles de AOBO para varios clientes: este código es solo con fines ilustrativos.
    • Obtenga una lista de todas las suscripciones de los clientes de CSP y todas las entidades de seguridad externas e identifique si hay un error de coincidencia. Este código también se puede usar para recopilar información de soporte técnico.
    • Compruebe qué suscripciones de Azure (derechos de plan de Azure) se han vendido y cuáles son accesibles con las credenciales actuales.
    • Para revendedores indirectos, este script también funciona. Pero todas las suscripciones tendrían la nota "no vendida" incluso si son el socio de registro para esta venta.
### 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
}
}
}

  • A continuación, se puede dar formato a la salida de este script:

    Ejemplo de formato de salida.

Comprobación de los permisos de Azure Lighthouse y pal de Azure

Al igual que AOBO, Azure Lighthouse permite que los grupos de usuarios del inquilino de administración (asociado) hereden permisos delegados en la suscripción de Azure del cliente. La diferencia es que permite una definición más granular de grupos y niveles de permisos que AOBO.

Para este modelo de permisos, es más fácil comprobar si se ha establecido correctamente mediante la interfaz de usuario de Azure Portal. Solo el asociado puede proporcionar una comprobación completa de que la configuración de Azure Lighthouse es correcta.

En los pasos siguientes se describe cómo identificar para qué clientes se han delegado permanentemente los permisos de rol de RBAC de Azure y a qué grupos. A continuación, puede comprobar si el usuario que tiene la asociación RBAC de Azure es miembro de esos grupos.

Paso 1: Comprobación de las delegaciones de Lighthouse en los clientes

Compruebe que las delegaciones aplicables usan roles de RBAC de Azure aptos para PEC.

  • Abra Azure Portal (con un usuario del inquilino de administración del asociado). A continuación, busque "Lighthouse" y seleccione Mis clientes.

    Ejemplo de Azure Services Lighthouse.

  • En la información general del cliente, elija Delegaciones en el lado izquierdo. Al hacerlo, se abre la lista de recursos (suscripciones o grupos de recursos) donde se ha proporcionado acceso delegado:

    Página Delegaciones.

  • Abra las delegaciones en la columna derecha en "Asignaciones de roles" para ver qué grupo de usuarios del inquilino de partner/administración hereda cada tipo de permisos (consulte la columna "Rol"). También puede ver si esos permisos son permanentes (consulte la columna "Tipo de acceso"):

    Página Asignaciones de roles

Paso 2: Comprobación de la pertenencia a grupos

Seleccione el nombre para mostrar del grupo. Para ello, se abrirán los detalles del grupo. Seleccione "Miembros" para controlar qué usuario tiene establecido Azure RBAC y es miembro del grupo correspondiente:

Pertenencia a grupos.

Paso 3: Comprobación de si el usuario ha configurado Azure PAL

Solo el usuario que ha establecido Azure PAL puede comprobar la asignación de Azure PAL; ningún otro usuario administrador puede hacerlo. Consulte Cómo explicar el vínculo de partner Administración (PAL) a mi cliente? en Vinculación de una cuenta de Azure a un PartnerID para obtener más información sobre cómo el usuario puede comprobar si se ha establecido Azure PAL, ya sea a través de la interfaz de usuario o PowerShell.

Nota:

Azure PAL debe usar un PartnerID que forme parte de la misma organización del Programa microsoft AI Cloud Partner Program que sea el asociado de transacción para esta suscripción de Azure. En el modelo indirecto, que puede ser partnerID del proveedor o el revendedor específico adjunto a esta venta.

Paso 4: Comprobación de las asignaciones de grupos enlazadas a tiempo

Dado que la pertenencia a grupos podría no ser permanente, compruebe si el grupo estaba habilitado para la administración de acceso con privilegios. Busque dónde se encuentra "Acceso con privilegios" en el lado izquierdo en "Actividad" en la configuración del grupo. Si es true, compruebe si el usuario tiene una asignación activa y el período de tiempo de esta asignación.

Nota:

Dado que la asignación "hora de finalización" es cuando un usuario se quita automáticamente del grupo, pec se perdería para los usuarios que tenían establecido Azure RBAC. Del mismo modo, solo se concedería PEC después de la asignación "hora de inicio".

Grupo de acceso con privilegios.

Comprobación de la asignación de usuarios individuales y la PAL de Azure

En algunos casos, puede ser más adecuado trabajar con cuentas de usuario individuales que tengan permisos en las suscripciones de Azure. Estas cuentas pueden ser cuentas de usuario invitado (desde cualquier inquilino) o cuentas de usuario creadas en el inquilino del cliente o en las entidades de servicio.

Cuando se usan cuentas de usuario individuales como vehículo para ganar PEC, la comprobación implica simplemente revisar los permisos asignados en la administración de suscripciones de Azure para el usuario y comprobar que el usuario ha establecido Azure RBAC correctamente. Cuando se usa una entidad de servicio, la comprobación de RBAC de Azure debe producirse a través de PowerShell.

Paso 1: Revisión de los permisos en la administración de suscripciones de Azure

  • Abra Azure Portal. Asegúrese de que ha iniciado sesión como usuario que tenga el rol RBAC de Azure con al menos acceso de lectura a la suscripción en cuestión.

  • Busque "Suscripciones" en la barra de búsqueda para abrir los detalles de la suscripción:

    Página de detalles de la suscripción.

  • Vaya a "Control de acceso (IAM)" en los detalles de la suscripción. A continuación, seleccione "Asignaciones de roles" para revisar los usuarios que tienen acceso en un nivel de suscripción y si la columna "Rol" muestra roles de Azure RBAC aptos para PEC. Si los permisos se han establecido en un nivel de grupo de recursos, la misma vista "Control de acceso (IAM)" también está disponible en un grupo de recursos.

Nota:

También se pueden conceder permisos a un grupo de usuarios en los que la pertenencia a grupos del usuario que tiene el conjunto de RBAC de Azure también tendría que comprobarse.

Control de acceso.

Paso 2: Asegurarse de que los permisos son permanentes y que no se aplican asignaciones de denegación

Aunque puede parecer que los usuarios tienen acceso, es posible que sus permisos sigan siendo temporales o bloqueados a través de asignaciones de denegación.

El uso de la asignación de roles de Azure RBAC de Privileged Identity Management (PIM) podría estar limitado al tiempo. Aunque es posible que vea a los usuarios con permiso, es posible que solo existan durante un breve tiempo. Para comprobar que la asignación de roles de RBAC de Azure es permanente, compruebe la administración de PIM en Azure Portal. En concreto, compruebe dónde se administran los recursos de Azure de la suscripción mediante directivas de PIM y si el usuario está sujeto a alguna directiva.

La suscripción de Azure no se administra a través de PIM.

Además, la lista de permisos podría mostrar que el usuario tiene permisos en la suscripción, pero podría haber asignaciones de denegación que todavía impidan que el usuario acceda a algo. En "Control de acceso (IAM)" seleccione la pestaña Denegar asignación para ver si se aplican asignaciones de denegación:

Denegar asignaciones.

Nota:

Por motivos de integridad, los asociados también deben comprobar que en los grupos de recursos no existen asignaciones de denegación dentro de la suscripción.

Paso 3: Comprobación de si el usuario ha configurado Azure PAL

Solo el usuario que ha configurado Azure PAL puede comprobar las asignaciones de PAL de Azure; ningún otro usuario administrador puede hacerlo. Para obtener más información sobre cómo el usuario puede comprobar que se ha establecido azure PAL, consulte Vinculación de una cuenta de Azure a un PartnerID.

Nota:

Azure PAL debe usar un PartnerID que forme parte de la misma organización del Programa microsoft AI Cloud Partner Program que sea el asociado de transacción para esta suscripción de Azure. En el modelo indirecto, esto puede ser partnerID del proveedor o partnerID del revendedor asociado a esta venta.

Pasos siguientes