Solución de problemas de Azure RBAC

En este artículo se describen algunas soluciones comunes para problemas relacionados con el control de acceso basado en rol de Azure (RBAC de Azure).

Asignaciones de roles de Azure

Síntoma: la opción Agregar asignación de roles está deshabilitada

No puede asignar un rol en Azure Portal en Control de acceso (IAM) porque la opción Agregar>Agregar asignación de roles está deshabilitada

Causa

Actualmente ha iniciado sesión con un usuario que no tiene permiso para asignar roles en el ámbito seleccionado.

Solución

Compruebe que ha iniciado sesión actualmente con un usuario que tiene asignado un rol que tiene el permiso Microsoft.Authorization/roleAssignments/write, como Administrador de control de acceso basado en roles en el ámbito que intenta asignar el rol.

Síntoma: los roles o las entidades de seguridad no aparecen en la lista

Al intentar asignar un rol en Azure Portal, algunos roles o entidades de seguridad no aparecen en la lista. Por ejemplo, en la pestaña Rol, verá un conjunto reducido de roles.

O bien, en el panel Seleccionar miembros, verá un conjunto reducido de entidades de seguridad.

Causa

Hay restricciones en las asignaciones de roles que puede agregar. Por ejemplo, está restringido en los roles a los que puede asignar o restringir en las entidades de seguridad a las que puede asignar roles.

Solución

Vea los roles que tiene asignados. Compruebe si hay una condición que restrinja las asignaciones de roles que puede agregar. Para obtener más información, consulte Delegar la administración de acceso de Azure a otros.

Síntoma: no se puede asignar un rol

No puede asignar un rol y recibe un error similar al siguiente:

Failed to add {securityPrincipal} as {role} for {scope} : The client '{clientName}' with object id '{objectId}' does not have authorization or an ABAC condition not fulfilled to perform action 'Microsoft.Authorization/roleAssignments/write' over scope '/subscriptions/{subscriptionId}/Microsoft.Authorization/roleAssignments/{roleAssignmentId}' or the scope is invalid. If access was recently granted, please refresh your credentials.

Causa 1

Actualmente ha iniciado sesión con un usuario que no tiene permiso para asignar roles en el ámbito seleccionado.

Solución 1

Compruebe que ha iniciado sesión actualmente con un usuario que tiene asignado un rol que tiene el permiso Microsoft.Authorization/roleAssignments/write, como Administrador de control de acceso basado en roles en el ámbito que intenta asignar el rol.

Causa 2

Hay restricciones en las asignaciones de roles que puede agregar. Por ejemplo, está restringido en los roles a los que puede asignar o restringir en las entidades de seguridad a las que puede asignar roles.

Solución 2

Vea los roles que tiene asignados. Compruebe si hay una condición que restrinja las asignaciones de roles que puede agregar. Para obtener más información, consulte Delegar la administración de acceso de Azure a otros.

Síntoma: no se puede asignar un rol mediante una entidad de servicio con la CLI de Azure

Está usando una entidad de servicio para asignar roles con la CLI de Azure y recibe el siguiente error:

Insufficient privileges to complete the operation

Por ejemplo, supongamos que tiene una entidad de servicio a la que se le ha asignado el rol de propietario e intenta crear la siguiente asignación de roles como entidad de servicio mediante la CLI de Azure:

az login --service-principal --username "SPNid" --password "password" --tenant "tenantid"
az role assignment create --assignee "userupn" --role "Contributor"  --scope "/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}"

Causa

Es probable que la CLI de Azure intente buscar la identidad del receptor en Microsoft Entra ID y la entidad de servicio no puede leer Microsoft Entra ID de forma predeterminada.

Solución

Hay dos maneras de resolver este error. La primera consiste en asignar el rol lectores de directorio a la entidad de servicio para que pueda leer los datos en el directorio.

La segunda manera de resolver este error es crear la asignación de roles mediante el parámetro --assignee-object-id en lugar de --assignee. Con --assignee-object-id, la CLI de Azure omitirá la búsqueda de Microsoft Entra. Deberá obtener el identificador de objeto del usuario, el grupo o la aplicación a los que desea asignar el rol. Para más información, vea Asignación de roles de Azure mediante la CLI de Azure.

az role assignment create --assignee-object-id 11111111-1111-1111-1111-111111111111  --role "Contributor" --scope "/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}"

Síntoma: a veces se produce un error al asignar un rol a una nueva entidad de seguridad

Cree un nuevo usuario, grupo o entidad de servicio e intente asignar inmediatamente un rol a esa entidad de seguridad y a veces se produce un error en la asignación de roles. Recibirá un mensaje similar al siguiente error:

PrincipalNotFound
Principal {principalId} does not exist in the directory {tenantId}. Check that you have the correct principal ID. If you are creating this principal and then immediately assigning a role, this error might be related to a replication delay. In this case, set the role assignment principalType property to a value, such as ServicePrincipal, User, or Group.  See https://aka.ms/docs-principaltype

Causa

Es probable que el motivo sea un retraso en la replicación. La entidad de seguridad se crea en una región; sin embargo, la asignación de roles puede tener lugar en una región distinta que todavía no haya replicado la entidad de servicio.

Solución 1

Si está creando un nuevo usuario o entidad de servicio mediante la API de REST o la plantilla ARM, establezca la propiedad principalType al crear la asignación de roles mediante Asignaciones de roles: Crear API.

Para obtener más información, consulte Asignación de roles de Azure a una nueva entidad de servicio mediante la API de REST o Asignación de roles de Azure a una nueva entidad de servicio mediante plantillas de Azure Resource Manager.

Solución 2

Si va a crear un nuevo usuario o entidad de servicio mediante Azure PowerShell, establezca el parámetro ObjectType en User o ServicePrincipal al crear la asignación de roles mediante New-AzRoleAssignment. Se siguen aplicando las mismas restricciones de versión de API subyacentes de la solución 1. Para más información, consulte Asignación de roles de Azure mediante Azure PowerShell.

Solución 3

Si va a crear un nuevo grupo, espere unos minutos antes de crear la asignación de roles.

Síntoma: la asignación de roles de la plantilla de ARM devuelve el estado BadRequest

Al intentar implementar un archivo Bicep o una plantilla de ARM que asigna un rol a una entidad de servicio, obtiene el error:

Tenant ID, application ID, principal ID, and scope are not allowed to be updated. (code: RoleAssignmentUpdateNotPermitted)

Por ejemplo, si crea una asignación de roles para una identidad administrada, elimine la identidad administrada y vuelva a crearla; la nueva identidad administrada tiene un id. de entidad de seguridad diferente. Si intenta volver a implementar la asignación de roles y usa el mismo nombre de asignación de roles, se produce un error en la implementación.

Causa

La asignación de roles name no es única y se ve como una actualización.

Las asignaciones de roles solo se identifican por su nombre, que es un identificador único global (GUID). No se pueden crear dos asignaciones de roles con el mismo nombre, incluso en distintas suscripciones de Azure. Tampoco puede cambiar las propiedades de una asignación de roles existente.

Solución

Proporcione un valor único idempotente para la asignación de roles name. Un procedimiento recomendado consiste en crear un GUID que use conjuntamente el ámbito, el id. principal y el id. de rol. Se aconseja usar la función guid() para ayudarle a crear un GUID determinista para los nombres de asignación de roles, como en este ejemplo:

resource roleAssignment 'Microsoft.Authorization/roleAssignments@2020-10-01-preview' = {
  name: guid(resourceGroup().id, principalId, roleDefinitionId)
  properties: {
    roleDefinitionId: roleDefinitionId
    principalId: principalId
    principalType: principalType
  }
}

{
  "type": "Microsoft.Authorization/roleAssignments",
  "apiVersion": "2020-10-01-preview",
  "name": "[guid(resourceGroup().id, variables('principalId'), variables('roleDefinitionId'))]",
  "properties": {
    "roleDefinitionId": "[variables('roleDefinitionId')]",
    "principalId": "[variables('principalId')]",
    "principalType": "[variables('principalType')]"
  }
}

Para obtener más información, consulte Creación de recursos de RBAC de Azure mediante Bicep.

Síntoma: asignaciones de roles con identidad no encontrada

En la lista de asignaciones de roles para Azure Portal, observa que la entidad de seguridad (usuario, grupo, entidad de servicio o identidad administrada) aparece como Identidad no encontrada con un tipo Desconocido.

Si enumera esta asignación de roles mediante Azure PowerShell, puede que vea un elemento DisplayName vacío y SignInName o un valor para ObjectType de Unknown. Por ejemplo, Get-AzRoleAssignment devuelve una asignación de roles que es similar a la salida siguiente:

RoleAssignmentId   : /subscriptions/11111111-1111-1111-1111-111111111111/providers/Microsoft.Authorization/roleAssignments/22222222-2222-2222-2222-222222222222
Scope              : /subscriptions/11111111-1111-1111-1111-111111111111
DisplayName        :
SignInName         :
RoleDefinitionName : Storage Blob Data Contributor
RoleDefinitionId   : ba92f5b4-2d11-453d-a403-e96b0029c9fe
ObjectId           : 33333333-3333-3333-3333-333333333333
ObjectType         : User
CanDelegate        : False

Del mismo modo, si enumera esta asignación de roles con la CLI de Azure, podría ver un elemento principalName vacío. Por ejemplo, az role assignment list devuelve una asignación de roles que es similar a la salida siguiente:

{
    "canDelegate": null,
    "id": "/subscriptions/11111111-1111-1111-1111-111111111111/providers/Microsoft.Authorization/roleAssignments/22222222-2222-2222-2222-222222222222",
    "name": "22222222-2222-2222-2222-222222222222",
    "principalId": "33333333-3333-3333-3333-333333333333",
    "principalName": "",
    "roleDefinitionId": "/subscriptions/11111111-1111-1111-1111-111111111111/providers/Microsoft.Authorization/roleDefinitions/ba92f5b4-2d11-453d-a403-e96b0029c9fe",
    "roleDefinitionName": "Storage Blob Data Contributor",
    "scope": "/subscriptions/11111111-1111-1111-1111-111111111111",
    "type": "Microsoft.Authorization/roleAssignments"
}

Causa 1

Ha invitado recientemente a un usuario al crear una asignación de roles y esta entidad de seguridad sigue en el proceso de replicación entre regiones.

Solución 1

Espere unos instantes y actualice la lista de asignaciones de roles.

Causa 2

Ha eliminado una entidad de seguridad que tenía una asignación de roles. Si asigna un rol a una entidad de seguridad y, posteriormente, elimina esa entidad de seguridad sin quitar antes la asignación de roles, la entidad de seguridad se mostrará como Identidad no encontrada y con un tipo Desconocido.

Solución 2

No es problema dejar estas asignaciones de roles donde se ha eliminado la entidad de seguridad. Si lo desea, puede quitar estas asignaciones de roles siguiendo los pasos similares a otras asignaciones de roles. Para obtener información sobre cómo eliminar asignaciones de roles, vea Eliminación de asignaciones de roles de Azure.

En PowerShell, si intenta quitar las asignaciones de roles mediante el identificador de objeto y el nombre de definición de roles, y más de una asignación de roles coincide con los parámetros, recibirá el mensaje de error: The provided information does not map to a role assignment. La salida siguiente muestra un ejemplo del mensaje de error:

PS C:\> Remove-AzRoleAssignment -ObjectId 33333333-3333-3333-3333-333333333333 -RoleDefinitionName "Storage Blob Data Contributor"

Remove-AzRoleAssignment : The provided information does not map to a role assignment.
At line:1 char:1
+ Remove-AzRoleAssignment -ObjectId 33333333-3333-3333-3333-333333333333 ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo          : CloseError: (:) [Remove-AzRoleAssignment], KeyNotFoundException
+ FullyQualifiedErrorId : Microsoft.Azure.Commands.Resources.RemoveAzureRoleAssignmentCommand

Si recibe este mensaje de error, asegúrese de especificar también los parámetros -Scope o -ResourceGroupName.

PS C:\> Remove-AzRoleAssignment -ObjectId 33333333-3333-3333-3333-333333333333 -RoleDefinitionName "Storage Blob Data Contributor" -Scope /subscriptions/11111111-1111-1111-1111-111111111111

Síntoma: no se puede eliminar la última asignación de roles de propietario

Intenta quitar la última asignación de roles de propietario para una suscripción y ve el siguiente error:

Cannot delete the last RBAC admin assignment

Causa

Para evitar que la suscripción quede huérfana, no se puede eliminar la última asignación del rol de propietario de una suscripción.

Solución

Si quiere cancelar su suscripción, consulte Cancelación de la suscripción a Azure.

Puede quitar la última asignación de roles de propietario (o administrador de acceso de usuario) en el ámbito de la suscripción, si es un administrador global para el inquilino o un administrador clásico (administrador de servicios o coadministrador) para la suscripción. En este caso, no hay ninguna restricción para la eliminación. Sin embargo, si la llamada procede de otra entidad de seguridad, no podrá quitar la última asignación del rol Propietario en el ámbito de la suscripción.

Síntoma: la asignación de roles no se mueve después de mover un recurso

Causa

Si mueve un recurso que tiene un rol de Azure asignado directamente al recurso (o a un recurso secundario), la asignación de roles no se mueve y queda huérfana.

Solución

Después de mover un recurso, debe volver a crear asignaciones de roles. Finalmente, la asignación de roles huérfana se eliminará automáticamente, pero se recomienda eliminar la asignación de roles antes de mover el recurso. Para obtener información sobre cómo trasladar recursos, vea Traslado de los recursos a un nuevo grupo de recursos o a una nueva suscripción.

Síntoma: no se detectan los cambios en la asignación de roles

Ha agregado o actualizado recientemente una asignación de roles, pero no se detectan los cambios. Es posible que vea el mensaje Status: 401 (Unauthorized).

Causa 1

Azure Resource Manager a veces almacena en caché las configuraciones y los datos para mejorar el rendimiento.

Solución 1

Al asignar roles o quitar asignaciones de roles, los cambios pueden tardar hasta 10 minutos en aplicarse. Si usa Azure Portal, Azure PowerShell o la CLI de Azure, puede exigir una actualización de los cambios de asignación de roles cerrando e iniciando sesión. Si va a realizar cambios de asignación de roles con llamadas API de REST, puede exigir una actualización renovando el token de acceso.

Causa 2

Ha agregado identidades administradas a un grupo y ha asignado un rol a ese grupo. Los servicios de back-end para identidades administradas mantienen una memoria caché por URI de recurso durante unas veinticuatro horas.

Solución 2

Los cambios en el grupo de una identidad administrada o en la pertenencia a un rol pueden tardar varias horas en surtir efecto. Para más información, vea Limitación del uso de identidades administradas para la autorización.

Síntoma: no se detectan cambios de asignación de roles en el ámbito del grupo de administración

Recientemente ha agregado o actualizado una asignación de roles en el ámbito del grupo de administración, pero no se detectan los cambios.

Causa

Azure Resource Manager a veces almacena en caché las configuraciones y los datos para mejorar el rendimiento.

Solución

Al asignar roles o quitar asignaciones de roles, los cambios pueden tardar hasta 10 minutos en aplicarse. Si agrega o quita una asignación de roles integrada en el ámbito del grupo de administración y el rol integrado tiene DataActions, es posible que el acceso en el plano de datos no se actualice durante varias horas. Esto solo se aplica al ámbito del grupo de administración y al plano de datos. No se pueden asignar roles personalizados con DataActions en el ámbito del grupo de administración.

Síntoma: no se detectan asignaciones de roles para los cambios del grupo de administración

Ha creado un nuevo grupo de administración secundario y no se detecta la asignación de roles en el grupo de administración primario para el grupo de administración secundario.

Causa

Azure Resource Manager a veces almacena en caché las configuraciones y los datos para mejorar el rendimiento.

Solución

La asignación de roles del grupo de administración secundario puede tardar hasta 10 minutos en surtir efecto. Si usa Azure Portal, Azure PowerShell o la CLI de Azure, puede exigir una actualización de los cambios de asignación de roles cerrando e iniciando sesión. Si va a realizar cambios de asignación de roles con llamadas API de REST, puede exigir una actualización renovando el token de acceso.

Síntoma: la eliminación de asignaciones de roles mediante PowerShell tarda varios minutos

Use el comando Remove-AzRoleAssignment para quitar una asignación de roles. A continuación, use el comando Get-AzRoleAssignment para comprobar que la asignación de roles se quitó para una entidad de seguridad. Por ejemplo:

Get-AzRoleAssignment -ObjectId $securityPrincipalObject.Id

El comando Get-AzRoleAssignment indica que no se quitó la asignación de roles. Sin embargo, si espera entre 5 y 10 minutos y ejecuta Get-AzRoleAssignment de nuevo, la salida indica que se quitó la asignación de roles.

Causa

Se ha quitado una asignación de roles. Sin embargo, para mejorar el rendimiento, PowerShell usa una caché al enumerar las asignaciones de roles. Puede haber un retraso de aproximadamente 10 minutos para que se actualice la caché.

Solución

En lugar de enumerar las asignaciones de roles de una entidad de seguridad, enumere todas las asignaciones de roles en el ámbito de la suscripción y filtre la salida. Por ejemplo, el siguiente comando:

$validateRemovedRoles = Get-AzRoleAssignment -ObjectId $securityPrincipalObject.Id 

En lugar de ello, se puede reemplazar por este comando:

$validateRemovedRoles = Get-AzRoleAssignment -Scope /subscriptions/$subId | Where-Object -Property ObjectId -EQ $securityPrincipalObject.Id

Roles personalizados

Síntoma: no se puede actualizar o eliminar un rol personalizado

No puede actualizar o eliminar un rol personalizado existente.

Causa 1

Actualmente ha iniciado sesión con un usuario que no tiene permiso para actualizar o eliminar roles personalizados.

Solución 1

Compruebe que ha iniciado sesión actualmente con un usuario que tenga asignado un rol que tenga el permiso Microsoft.Authorization/roleDefinitions/write, como Administrador de acceso de usuario.

Causa 2

El rol personalizado incluye una suscripción en ámbitos asignables y esa suscripción está en un estado deshabilitado.

Solución 2

Vuelva a activar la suscripción deshabilitada y actualice el rol personalizado según sea necesario. Para más información, consulte Reactivación de una suscripción de Azure deshabilitada.

Síntoma: no se puede crear o actualizar un rol personalizado

Cuando intenta crear o actualizar un rol personalizado, obtiene un error similar al siguiente:

The client '<clientName>' with object id '<objectId>' has permission to perform action 'Microsoft.Authorization/roleDefinitions/write' on scope '/subscriptions/<subscriptionId>'; however, it does not have permission to perform action 'Microsoft.Authorization/roleDefinitions/write' on the linked scope(s)'/subscriptions/<subscriptionId1>,/subscriptions/<subscriptionId2>,/subscriptions/<subscriptionId3>' or the linked scope(s)are invalid

Causa

Este error suele indicar que no tiene permisos para uno o varios de los ámbitos asignables en el rol personalizado.

Solución

Realice lo siguiente:

• Revise Quién puede crear, eliminar, actualizar o ver un rol personalizado y compruebe que tiene permisos para crear o actualizar el rol personalizado para todos los ámbitos asignables.
• Si no tiene permisos, pida al administrador que le asigne un rol que tenga la acción Microsoft.Authorization/roleDefinitions/write, como Administrador de acceso de usuario, en el ámbito del ámbito asignable.
• Compruebe que todos los ámbitos asignables del rol personalizado son válidos. Si no es así, quite los ámbitos asignables no válidos.

Para obtener más información, consulte los tutoriales de roles personalizados mediante Azure Portal, Azure PowerShell o la CLI de Azure.

Síntoma: no se puede eliminar un rol personalizado

No puede eliminar un rol personalizado y obtiene el siguiente mensaje de error:

There are existing role assignments referencing role (code: RoleDefinitionHasAssignments)

Causa

Hay asignaciones de roles que siguen utilizando el rol personalizado.

Solución

Quite las asignaciones de roles que usan el rol personalizado e intente eliminar el rol personalizado de nuevo. Para obtener más información, consulte Búsqueda de asignaciones de roles para eliminar un rol personalizado.

Síntoma: no se puede agregar más de un grupo de administración como ámbito asignable

Al intentar crear o actualizar un rol personalizado, no puede agregar más de un grupo de administración como ámbito asignable.

Causa

Solo se puede definir un grupo de administración en AssignableScopes de un rol personalizado.

Solución

Defina un grupo de administración en AssignableScopes del rol personalizado. Para obtener más información sobre los roles personalizados y los grupos de administración, consulte el artículo Organización de los recursos con grupos de administración de Azure.

Síntoma: no se pueden agregar acciones de datos al rol personalizado

Al intentar crear o actualizar un rol personalizado, no puede agregar acciones de datos o ve el siguiente mensaje:

You cannot add data action permissions when you have a management group as an assignable scope

Causa

Está intentando crear un rol personalizado con acciones de datos y un grupo de administración como ámbito asignable. No se pueden asignar roles personalizados con DataActions en el ámbito del grupo de administración.

Solución

Cree el rol personalizado con una o varias suscripciones como ámbito asignable. Para obtener más información sobre los roles personalizados y los grupos de administración, consulte el artículo Organización de los recursos con grupos de administración de Azure.

Errores de permiso o acceso denegado

Síntoma: error de autorización

Al intentar crear un recurso, aparecerá el siguiente mensaje de error:

The client with object id does not have authorization to perform action over scope (code: AuthorizationFailed)

Causa 1

Actualmente ha iniciado sesión con un usuario que no tiene permiso de escritura para el recurso en el ámbito seleccionado.

Solución 1

Compruebe que ha iniciado sesión con un usuario que tiene asignado un rol con permiso de escritura en el recurso y en el ámbito seleccionado. Por ejemplo, para administrar las máquinas virtuales de un grupo de recursos, debe tener el rol Colaborador de máquina virtual en el grupo de recursos (o el ámbito primario). Para ver una lista de los permisos para cada rol integrado, consulte Roles integrados de Azure.

Causa 2

El usuario que ha iniciado sesión tiene una asignación de roles con los siguientes criterios:

• El rol incluye una acción de datos de Microsoft.Storage
• La asignación de roles incluye una condición ABAC que utiliza operadores de comparación GUID

Solución 2

En este momento, no puede tener una asignación de roles con una acción de datos Microsoft.Storage y una condición de ABAC que use un operador de comparación GUID. Estas son algunas de las opciones para resolver este error:

• Si el rol es un rol personalizado, quite cualquier acción de datos de Microsoft.Storage
• Modificar la condición de asignación de roles para que no use operadores de comparación GUID

Síntoma: el usuario invitado recibe un error de autorización

Cuando un usuario invitado intenta acceder a un recurso, recibe un mensaje de error similar al siguiente:

The client '<client>' with object id '<objectId>' does not have authorization to perform action '<action>' over scope '<scope>' or the scope is invalid.

Causa

El usuario invitado no tiene permisos para el recurso en el ámbito seleccionado.

Solución

Compruebe que al usuario invitado se le asigna un rol con permisos con privilegios mínimos al recurso en el ámbito seleccionado. Para obtener más información, consulte Asignación de roles de Azure a usuarios externos mediante Azure Portal.

Síntoma: no se puede crear una solicitud de soporte técnico

Al intentar crear o actualizar una incidencia de soporte técnico, aparecerá el siguiente mensaje de error:

You don't have permission to create a support request

Causa

Actualmente ha iniciado sesión con un usuario que no tiene permiso para crear solicitudes de soporte técnico.

Solución

Compruebe que haya iniciado sesión con un usuario que tenga asignado un rol con el permiso Microsoft.Support/supportTickets/write, como Colaborador de solicitud de soporte técnico.

Las características de Azure están deshabilitadas

Síntoma: algunas características de la aplicación web están deshabilitadas

Un usuario tiene acceso de lectura a una aplicación web y algunas características están deshabilitadas.

Causa

Si concede a un usuario acceso de lectura a una aplicación web, se deshabilitan algunas características que no cabría esperar. Las siguientes funcionalidades de administración requieren acceso de escritura a una aplicación web, y no están disponibles en un escenario de solo lectura.

• Comandos (p. ej., iniciar, parar, etc.)
• Cambiar opciones, como la configuración general, opciones de escala, opciones de copia de seguridad y opciones de supervisión
• Acceder a las credenciales de publicación y otros secretos, como opciones de aplicaciones y cadenas de conexión
• Registros de streaming
• Configuración de registros de recursos
• Consola (símbolo del sistema)
• Implementaciones activas y recientes (para implementaciones git continuas locales)
• Gasto estimado
• Pruebas web
• Red virtual (solo visible para un lector si un usuario con acceso de escritura ha configurado previamente una red virtual)

Solución

Asigne el rol Colaborador u otro rol integrado de Azure con permisos de escritura para la aplicación web.

Síntoma: algunos recursos de la aplicación web están deshabilitados

Un usuario tiene acceso de escritura a una aplicación web y algunas características están deshabilitadas.

Causa

Las aplicaciones web pueden resultar complicadas si entran en juego distintos recursos. Este es un grupo de recursos típico con un par de sitios web:

Como consecuencia, si le concede a alguien acceso solo a la aplicación web, muchas de las funcionalidades de la hoja del sitio web de Azure Portal están deshabilitadas.

Estos elementos requieren acceso de escritura al plan de App Service que corresponde a su sitio web:

• Visualización del plan de tarifa de la aplicación web (gratis o estándar).
• Configuración de escala (número de instancias, tamaño de la máquina virtual y configuración de escala automática).
• Cuotas (almacenamiento, ancho de banda y CPU).

Estos elementos requieren acceso de escritura a todo el grupo de recursos que contiene su sitio web:

• Enlaces y certificados TLS/SSL (los certificados TLS/SSL se pueden compartir entre sitios en el mismo grupo de recursos y la misma ubicación geográfica)
• Las reglas de alertas
• Opciones de escala automática
• Componentes de Application Insights
• Pruebas web

Solución

Asigne un rol integrado de Azure con permisos de escritura para el plan de App Service o el grupo de recursos.

Síntoma: algunas características de máquina virtual están deshabilitadas

Un usuario tiene acceso a una máquina virtual y algunas características están deshabilitadas.

Causa

De manera similar a las aplicaciones web, algunas funciones de la hoja de máquina virtual requieren acceso de escritura a la máquina virtual o a otros recursos del grupo de recursos.

Las máquinas virtuales están relacionadas con los nombres de dominio, las redes virtuales, las cuentas de almacenamiento y las reglas de alerta.

Estos elementos requieren acceso de escritura a la máquina virtual:

• Puntos de conexión
• Direcciones IP
• Discos
• Extensiones

Estos requieren acceso de escritura a la máquina virtual y al grupo de recursos (junto con el nombre de dominio) donde se encuentran:

• Conjunto de disponibilidad
• El conjunto de carga equilibrada
• Las reglas de alertas

Si no puede acceder a ninguno de estos iconos, debe pedirle al administrador el acceso de colaborador al grupo de recursos.

Solución

Asigne un rol integrado de Azure con permisos de escritura para la máquina virtual o el grupo de recursos.

Síntoma: algunas características de la aplicación de funciones están deshabilitadas

Un usuario tiene acceso a una aplicación de funciones y algunas características están deshabilitadas. Por ejemplo, puede hacer clic en la pestaña Características de la plataforma y, a continuación, hacer clic en Toda las opciones de configuración para ver algunas opciones de configuración relacionadas con una aplicación de función (similar a una aplicación web), pero no puede modificar ninguna de estas opciones de configuración.

Causa

Algunas características de Azure Functions requieren acceso de escritura. Por ejemplo, si se asigna a un usuario el rol de Lector, este no podrá ver las funciones dentro de una aplicación de función. El portal muestra (sin acceso).

Solución

Asigne un rol integrado de Azure con permisos de escritura para la aplicación de funciones o el grupo de recursos.

Transferencia de una suscripción a un directorio diferente

Síntoma: todas las asignaciones de roles se eliminan después de transferir una suscripción

Causa

Cuando transfiere una suscripción de Azure a otro directorio de Microsoft Entra, todas las asignaciones de roles se eliminan permanentemente del directorio de Microsoft Entra de origen y no se migran al directorio de Microsoft Entra de destino.

Solución

Debe volver a crear las asignaciones de roles en el directorio de destino. También debe volver a crear manualmente las identidades administradas para los recursos de Azure. Para obtener más información, consulte Transferencia de una suscripción de Azure a otro directorio de Microsoft Entra y Preguntas frecuentes y problemas conocidos con identidades administradas.

Síntoma: no se puede acceder a la suscripción después de transferir una suscripción

Solución

Si es un administrador global de Azure AD y no tiene acceso a una suscripción después de transferirla de un directorio a otro, active la Administración del acceso para los recursos de Azure para elevar sus permisos de acceso temporalmente y obtener acceso a la suscripción.

Administradores de la suscripción clásica

Pasos siguientes

• Solución de problemas para usuarios externos
• Asignación de roles de Azure mediante Azure Portal
• Visualización de los registros de actividad de los cambios de RBAC de Azure