Solución de problemas de acceso y permisos

Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2019

Debido a la amplia estructura de seguridad y permisos de Azure DevOps, es posible que tenga que investigar por qué un usuario carece de acceso a un proyecto, servicio o característica que esperan. Busque instrucciones paso a paso para comprender y solucionar los problemas que puede encontrar un usuario al conectarse a un proyecto o acceder a un servicio o característica de Azure DevOps.

Antes de usar esta guía, se recomienda familiarizarse con el siguiente contenido:

• Introducción a los permisos, el acceso y los grupos de seguridad
• Permisos predeterminados y referencia rápida de acceso.

Sugerencia

Al crear un grupo de seguridad de Azure DevOps, etiquete claramente para indicar si está pensado para limitar el acceso.

Puede establecer permisos en los siguientes niveles:

• Nivel de objeto
• En el nivel de proyecto
• Nivel de organización o colección de proyectos
• Rol de seguridad
• Rol de administrador de equipo

Problemas comunes de acceso y permisos

Consulte los motivos más comunes por los que un miembro del proyecto no puede acceder a un proyecto, servicio o característica:

Problema	Acción de solución de problemas
Su nivel de acceso no admite el acceso al servicio ni a la característica.	Para determinar si es la causa, determine el nivel de acceso del usuario y el estado de la suscripción.
Su pertenencia dentro de un grupo de seguridad no admite el acceso a una característica o se les denegó explícitamente el permiso a una característica.	Para determinar si es la causa, realice un seguimiento de un permiso.
El usuario ha concedido recientemente permiso, pero su cliente necesita una actualización para reconocer los cambios.	Haga que el usuario actualice o vuelva a evaluar sus permisos.
El usuario intenta ejercer una característica concedida solo a un administrador de equipo para un equipo específico, pero no se le concede ese rol.	Para agregarlos al rol, consulte Agregar, quitar el administrador del equipo.
El usuario no habilitó una característica en versión preliminar.	Haga que el usuario abra las características de versión preliminar y determine el estado de encendido y apagado de la característica específica. Para obtener más información, consulte Administración de características en versión preliminar.
El miembro del proyecto se agregó a un grupo de seguridad de ámbito limitado, como el grupo Usuarios con ámbito de proyecto.	Para determinar si es la causa, busque las pertenencias a grupos de seguridad del usuario.

Problemas de acceso y permisos menos comunes

Las razones menos comunes para el acceso limitado son cuando se produjo uno de los siguientes eventos:

Problema	Acción de solución de problemas
Un administrador de proyectos deshabilitó un servicio. En este caso, nadie tiene acceso al servicio deshabilitado.	Para determinar si un servicio está deshabilitado, consulte Activación o desactivación de un servicio de Azure DevOps.
Un administrador de colecciones de proyectos deshabilitó una característica en versión preliminar, que la deshabilita para todos los miembros del proyecto de la organización.	Consulte Administración de características en versión preliminar.
Las reglas de grupo que rigen el nivel de acceso del usuario o la pertenencia al proyecto restringen el acceso.	Consulte Determinar el nivel de acceso y el estado de la suscripción de un usuario.
Las reglas personalizadas se definieron en el flujo de trabajo de un tipo de elemento de trabajo.	consulte Reglas aplicadas a un tipo de elemento de trabajo que restrinja la operación de selección.

Determinar el nivel de acceso y el estado de la suscripción de un usuario

Puede asignar usuarios o grupos de usuarios a uno de los siguientes niveles de acceso:

• Parte interesada
• Básico
• Básico + Test Plans
• Suscripción de Visual Studio

Para más información sobre cómo restringir los niveles de acceso en Azure DevOps, consulte Niveles de acceso admitidos.

Para usar las características de Azure DevOps, los usuarios deben agregarse a un grupo de seguridad con los permisos adecuados y tener acceso al portal web. Las limitaciones de características se basan en el nivel de acceso y el grupo de seguridad del usuario.

Los usuarios pueden perder el acceso por los siguientes motivos:

Motivo de pérdida de acceso	Acción de solución de problemas
La suscripción de Visual Studio del usuario ha expirado.	Mientras tanto, este usuario puede trabajar como parte interesada, o puede conceder al usuario acceso Básico hasta que el usuario renueve su suscripción. Una vez que el usuario inicia sesión, Azure DevOps restaura automáticamente el acceso.
La suscripción de Azure usada para la facturación ya no está activa.	Todas las compras realizadas con esta suscripción se ven afectadas, incluidas las suscripciones de Visual Studio. Para corregir este problema, visite el Portal de cuentas de Azure.
La suscripción de Azure usada para la facturación se quitó de la organización.	Más información sobre la vinculación de la organización

De lo contrario, en el primer día del mes natural, los usuarios que no iniciaron sesión en su organización durante más tiempo pierden primero el acceso. Si su organización ya no necesita acceso, quítelos de la organización.

Para obtener más información sobre los permisos, consulte Permisos y grupos y la guía de búsqueda de permisos.

Seguimiento de un permiso

Use el seguimiento de permisos para determinar por qué los permisos de un usuario no les permiten acceder a una función o característica específica. Obtenga información sobre cómo un usuario o un administrador pueden investigar la herencia de permisos. Para realizar un seguimiento de un permiso desde el portal web, abra la página de permisos o seguridad para el nivel correspondiente. Para obtener más información, consulte Solicitar un aumento en los niveles de permisos.

Si un usuario tiene problemas de permisos y usa grupos de seguridad predeterminados o grupos personalizados para permisos, use el seguimiento para investigar de dónde proceden esos permisos. Los problemas de permisos pueden deberse a cambios retrasados. Los cambios de permisos o pertenencias a grupos de Microsoft Entra pueden tardar hasta 1 hora en propagarse a través de Azure DevOps. Si un usuario tiene problemas que no se resuelven inmediatamente, espere un día para ver si se resuelve. Para más información sobre la administración de usuarios y acceso, consulte Administración de usuarios y acceso en Azure DevOps.

Los usuarios pueden recibir sus permisos efectivos directamente o a través de grupos.

Complete los pasos siguientes para que los administradores puedan comprender de dónde proceden exactamente esos permisos y ajustarlos, según sea necesario.

1. Seleccione Configuración del proyecto>Permisos>Usuarios y, a continuación, seleccione el usuario.

   

   Ahora debería tener una vista específica del usuario que muestre qué permisos tienen.

2. Para realizar un seguimiento de por qué un usuario hace o no tiene ninguno de los permisos enumerados, seleccione el icono de información situado junto al permiso en cuestión.

El seguimiento resultante le permite saber cómo heredan el permiso enumerado. Después, puede ajustar los permisos del usuario ajustando los permisos que se proporcionan a los grupos en los que se encuentran.

Para obtener más información, consulte Administrar el acceso a funciones y características específicas o Solicitar un aumento en los niveles de permisos.

Actualizar o volver a evaluar los permisos

Consulte el siguiente escenario en el que es posible que sea necesario actualizar o volver a evaluar los permisos.

Problema

Los usuarios se agregan a un grupo de Azure DevOps o Microsoft Entra. Esta acción concede acceso heredado a una organización o proyecto. Pero no obtienen acceso inmediatamente. Los usuarios deben esperar o cerrar sesión, cerrar su explorador y volver a iniciar sesión para actualizar sus permisos.

Solución

Vaya a Configuración de>usuario Permisos>Volver a evaluar los permisos. Esta función vuelve a evaluar los permisos y pertenencias a grupos y, a continuación, los cambios recientes surten efecto inmediatamente.

Reglas aplicadas a un tipo de elemento de trabajo que restringen las operaciones de selección

Antes de personalizar un proceso, se recomienda revisar Configurar y personalizar Azure Boards, que proporciona instrucciones sobre cómo personalizar Azure Boards para satisfacer sus necesidades empresariales.

Para obtener más información sobre las reglas de tipo de elemento de trabajo que se aplican a las operaciones de restricción, consulte:

• Aplicar reglas a estados de flujo de trabajo (proceso de herencia)
• Escenarios de reglas de ejemplo
• Definición de rutas de acceso de área y asignación a un equipo

Ocultar la configuración de la organización de los usuarios

Si un usuario está limitado a ver solo sus proyectos o no puede acceder a la configuración de la organización, la siguiente información puede explicar por qué. Para restringir a los usuarios el acceso a la configuración de la organización, habilite la característica Limitar la visibilidad del usuario y la colaboración a proyectos específicos en versión preliminar. Para obtener más información, incluidas las llamadas importantes relacionadas con la seguridad, consulte Administrar su organización, Limitar la visibilidad del usuario para proyectos y mucho más.

Algunos ejemplos de usuarios restringidos incluyen partes interesadas, usuarios invitados de Microsoft Entra o miembros de un grupo de seguridad. Una vez habilitado, cualquier usuario o grupo agregado al grupo Usuarios con ámbito de proyecto está restringido de acceder a las páginas de configuración de la organización, excepto información general y proyectos. Solo pueden acceder a los proyectos a los que se agregan.

Para obtener más información, vea Administrar su organización, Limitar la visibilidad del usuario para proyectos y mucho más.

Visualización, adición y administración de permisos con la CLI

Puede ver, agregar y administrar permisos en un nivel granular con los az devops security permission comandos . Para obtener más información, consulte Administración de permisos con la herramienta de línea de comandos.

Reglas de grupo con permisos menores

Los tipos de reglas de grupo se clasifican en el orden siguiente: Suscriptor > Básico + Planes > de prueba Partes interesadas básicas > . Los usuarios siempre reciben el nivel de acceso más alto disponible en todas las reglas de grupo, incluidas las suscripciones de Visual Studio (VS).

Nota:

• Los cambios realizados en los lectores del proyecto a través de reglas de grupo no se conservan. Para ajustar los lectores de proyectos, considere los métodos alternativos, como la asignación directa o los grupos de seguridad personalizados.
• Revise periódicamente las reglas enumeradas en la pestaña "Reglas de grupo" de la página "Usuarios". Los cambios en la pertenencia a grupos de id. de Microsoft Entra aparecerán en la siguiente nueva evaluación de las reglas de grupo, que se pueden realizar a petición, cuando se modifica una regla de grupo o automáticamente cada 24 horas. Azure DevOps actualiza la pertenencia a grupos de Microsoft Entra cada hora, pero puede tardar hasta 24 horas en actualizar la pertenencia dinámica a grupos.

Consulte los ejemplos siguientes, en los que se muestra cómo los factores de detección de suscriptores en las reglas de grupo.

Ejemplo 1: Regla de grupo me da más acceso

Si tengo una suscripción de VS Pro y estoy en una regla de grupo que me da Básico + Test Plans, ¿qué ocurre?

Esperado: obtengo Basic + Test Plans porque lo que la regla de grupo me da es mayor que mi suscripción. La asignación de reglas de grupo siempre proporciona el mayor acceso, en lugar de limitar el acceso.

Ejemplo 2: Regla de grupo me da el mismo acceso

Tengo una suscripción de Visual Studio Test Pro y estoy en una regla de grupo que me proporciona Basic + Test Plans: ¿qué sucede?

Esperado: se detecta como suscriptor de Visual Studio Test Pro, porque el acceso es el mismo que la regla de grupo. Ya estoy pagando por Visual Studio Test Pro, así que no quiero pagar de nuevo.

Uso de GitHub

Consulte la siguiente información de solución de problemas para implementar código en Azure DevOps con GitHub.

Problema

No puede llevar el resto de su equipo a la organización y al proyecto, a pesar de agregarlos como miembros. Reciben correos electrónicos, pero al iniciar sesión, reciben un error 401.

Solución

Es posible que haya iniciado sesión en Azure DevOps con una identidad incorrecta. Siga estos pasos:

1. Cierre todos los exploradores, incluidos los exploradores que no ejecutan Azure DevOps.

2. Abra una sesión de exploración privada o de incógnito.

3. Vaya a la dirección URL siguiente: https://aka.ms/vssignout.

   Aparece un mensaje que indica "Cerrar sesión en curso". Después de cerrar la sesión, se le redirigirá a dev.azure.microsoft.com.

4. Vuelva a iniciar sesión en Azure DevOps y elija otra identidad.

Otras áreas en las que se pueden aplicar permisos

• Permisos de ruta de acceso de área
• Etiquetas de elemento de trabajo
• Elementos de trabajo movidos fuera de un proyecto
• Elementos de trabajo eliminados
• Guía rápida de los permisos predeterminados y el acceso para Azure Boards
• Reglas personalizadas
• Escenarios de reglas personalizadas de ejemplo
• Trabajos pendientes y paneles personalizados
• Controles personalizados

Artículos relacionados

• Administración de permisos con la herramienta de línea de comandos
• Cambiar permisos individuales o de grupo
• Recomendaciones de seguridad
• Agregar usuarios a un rol de administrador