Partekatu honen bidez:


Asignar niveles de acceso con reglas de grupo

Azure DevOps Services

Azure DevOps proporciona niveles de acceso basados en grupos para grupos de Microsoft Entra y grupos de Azure DevOps, lo que le permite administrar los permisos de forma eficaz mediante la asignación de niveles de acceso a todos los grupos de usuarios. Este artículo explica cómo añadir una regla de grupo para asignar un nivel de acceso a un grupo de usuarios.

Asigne una regla de grupo para administrar tanto los niveles de acceso como la pertenencia a proyectos. Cuando un usuario pertenece a varias reglas o grupos de Microsoft Entra con distintos niveles de acceso, recibe el nivel más alto.

Example: Si un usuario pertenece a dos grupos de Microsoft Entra,uno que asigna partes interesadas y otro básico, el usuario recibe acceso básico.

Cuando un usuario deja un grupo de Microsoft Entra, Azure DevOps ajusta su nivel de acceso según las reglas definidas del grupo. Si el grupo era el único origen de acceso del usuario, Azure DevOps los quita automáticamente de la organización. Si el usuario pertenece a otros grupos, se reevalúan su nivel de acceso y sus permisos.

Nota:

  • Azure DevOps aplica los recursos concedidos por reglas de grupo a todos los miembros del grupo configurado. Sin embargo, el acceso y los permisos surten efecto solo después de que el usuario inicie sesión en la organización por primera vez.
  • Revise periódicamente las reglas enumeradas en la pestaña Reglas de grupo de la página Usuarios . Los cambios en la membresía de grupos de Microsoft Entra ID aparecen durante la siguiente reevaluación de la regla de grupo, que se produce:
    • A petición al desencadenarlo manualmente
    • Automáticamente al modificar una regla de grupo
    • Automáticamente cada 24 horas. Azure DevOps actualiza la pertenencia de los grupos de Microsoft Entra cada hora, pero el ID de Microsoft Entra puede tardar hasta 24 horas en actualizar pertenencia a grupos dinámicos.
  • Actualmente, las reglas de grupo para las licencias no se aplican a las entidades de servicio ni a las identidades administradas. Para asignar un nivel de acceso a una entidad de servicio o una identidad administrada, asígnelo directamente en lugar de a través de la pertenencia a grupos. Para obtener más información, consulte Usar entidades de servicio y identidades administradas en Azure DevOps.

Sugerencia

Puede usar la inteligencia artificial para ayudar con esta tarea más adelante en este artículo, o consulte Enable AI assistance with Azure DevOps MCP Server para empezar.

Requisitos previos

Categoría Requisitos
Permisos Miembro del grupo de Administradores de Colección de Proyectos . Los propietarios de la organización son automáticamente miembros de este grupo.
Microsoft Entra Miembro del Microsoft Entra ID que respalda la organización. Para obtener más información, consulte Preguntas frecuentes sobre el acceso a través de Microsoft Entra. Los invitados de Microsoft Entra no pueden buscar el ID de Microsoft Entra de la manera requerida por Azure DevOps

Agregar una regla de grupo

  1. Inicie sesión en su organización (https://dev.azure.com/{Your_Organization}).

  2. Seleccione icono de engranajeConfiguración de la organización.

  3. Seleccione Reglasde grupo>de usuarios>Agregar una regla de grupo. Esta vista muestra todas las reglas de grupo creadas.

    Captura de pantalla que muestra el botón Agregar una regla de grupo seleccionado.

    Las reglas de grupo solo aparecen si es miembro del grupo Administradores de la colección de proyectos.

  4. Complete el cuadro de diálogo del grupo para el que desea crear una regla. Incluya un nivel de acceso para el grupo y cualquier acceso de proyecto opcional para el grupo. Selecciona Agregar.

    Captura de pantalla que muestra el cuadro de diálogo Añadir una regla de grupo.

    Se muestra una notificación que muestra el estado y el resultado de la regla. Si se produce un error en la asignación, seleccione Ver estado para ver los detalles.

    Captura de pantalla que muestra Regla de grupo completada.

Importante

  • Los usuarios no aparecen en Todos los usuarios hasta que intentan iniciar sesión por primera vez.

Cambios en el nivel de acceso

  • Cuando un usuario inicia sesión, las reglas de grupo ajustan automáticamente su nivel de acceso si la regla asigna un nivel superior al actual. Por ejemplo: un usuario con acceso de Stakeholder se actualiza a Básico si una regla de grupo asigna Básico.
  • Si un usuario ya tiene un nivel de acceso superior al que proporciona la regla de grupo, su acceso permanece igual. Por ejemplo: Un usuario asignado manualmente con acceso Básico no se degrada cuando una regla de grupo asigna Stakeholder.

Administración de miembros del grupo

Los grupos de reglas de Microsoft Entra ID gestionan la membresía en el portal de Azure. Las reglas de grupo para grupos de Azure DevOps administran la pertenencia a la pantalla Group rules.

  1. Seleccione Reglas de grupo>>Administrar miembros. La captura de pantalla muestra la regla de grupo resaltada para administrar miembros.

  2. Agregue miembros y, a continuación, seleccione Agregar.

    Captura de pantalla de Adición de un miembro de grupo.

Comprobación de la regla de grupo

Compruebe que los recursos se aplican a cada grupo y usuario individual:

  1. Seleccione Todos los usuarios.

  2. Resalte un usuario.

  3. Seleccione Resumen.

    Captura de pantalla que muestra la verificación del resumen de usuarios para la regla de grupo.

Quitar asignaciones directas

Cuando un usuario tiene una asignación directa y una regla de grupo concede un nivel de acceso superior, Azure DevOps actualiza automáticamente al usuario al nivel superior. Para administrar los niveles de acceso exclusivamente a través de reglas de grupo, quite todas las asignaciones directas.

  1. Inicie sesión en su organización (https://dev.azure.com/{Your_Organization}).

  2. Seleccione icono de engranajeConfiguración de la organización.

    Captura de pantalla que muestra el botón Configuración de la organización resaltado.

  3. Seleccione Usuarios.

    Captura de pantalla que muestra la pestaña Usuarios seleccionada.

  4. Seleccione todos los usuarios con recursos solo para la administración por grupos.

    Captura de pantalla que muestra las reglas de grupo seleccionadas para la migración.

  5. Para confirmar que desea quitar las asignaciones directas, seleccione Quitar.

    Captura de pantalla de confirmación de la eliminación.

    Si un usuario no es miembro de ningún grupo, el usuario no se ve afectado.

Preguntas más frecuentes

P: ¿Cómo funcionan las suscripciones de Visual Studio con las reglas de grupo?

R: los suscriptores de Visual Studio siempre se asignan directamente a través del portal de administración de Visual Studio y tienen prioridad en Azure DevOps sobre los niveles de acceso asignados directamente o a través de reglas de grupo. Cuando ve estos usuarios desde el Hub de Usuarios, la Fuente de Licencia siempre se muestra como Directa. La única excepción son los suscriptores de Visual Studio Professional que están asignados a Basic + Test Plans. Dado que Los planes básicos y de prueba proporcionan más acceso en Azure DevOps, tiene prioridad sobre una suscripción de Visual Studio Professional. No puede configurar una regla de grupo para asignar acceso a su suscripción de Visual Studio porque Visual Studio asigna esa licencia directamente a través de su portal.

P: ¿Cómo funcionan las licencias de GitHub Enterprise con reglas de grupo?

A.

  • Azure DevOps comprueba si un usuario tiene una licencia de GitHub Enterprise al iniciar sesión. El nivel de acceso puede tardar hasta 24 horas en actualizarse a GitHub Enterprise. Los usuarios con GitHub Enterprise reciben automáticamente el nivel de acceso de GitHub Enterprise, que es igual al acceso básico.
  • Si un usuario de GitHub Enterprise necesita acceso a los planes de prueba, asigne la licencia Basic + Test Plans directamente o a través de una regla de grupo.
  • No puede configurar una regla de grupo para asignar acceso a GitHub Enterprise porque GitHub asigna esa licencia directamente a través de su portal.
  • Cuando un usuario ya no tiene una licencia GitHub Enterprise válida:
    • Si su organización configura reglas de grupo: el usuario recibe el acceso especificado por su pertenencia a grupos.
    • Si su organización no configura reglas de grupo: el usuario recibe el nivel de acceso predeterminado de la organización.

Usa IA para administrar reglas de grupo y niveles de acceso

Si tiene configurado el Azure DevOps MCP Server, puede usar asistentes de inteligencia artificial para administrar reglas de grupo y asignaciones de nivel de acceso mediante indicaciones de lenguaje natural. El servidor MCP proporciona al asistente de inteligencia artificial acceso seguro a los datos de Azure DevOps, lo que le permite revisar las pertenencias a grupos, comprobar los niveles de acceso y auditar los permisos de usuario sin navegar por la interfaz web.

Mensajes de ejemplo para la administración de reglas de grupo

tarea Mensaje de ejemplo
Optimización de los costos de licencia Find users in <organization-name> with Basic access who haven't signed in within the last 90 days and could be downgraded to Stakeholder
Configuración de licencias basadas en grupos Show me which Microsoft Entra groups are configured as group rules in <organization-name> and what access level each grants
Búsqueda de reglas de grupo en conflicto List users in <organization-name> who belong to multiple group rules with different access levels and show which rule wins
Planear el acceso de un nuevo equipo Create a group rule in <organization-name> that assigns Basic + Test Plans access to members of the <Entra-group-name> group
Cobertura de las reglas del grupo de auditoría Show me users in <organization-name> whose access level was set by a group rule versus manually assigned
Comparación de pertenencias a grupos For <user-email>, show all group rules that apply in <organization-name> and explain their effective access level

Sugerencia

Si usa Visual Studio Code, el modo agent resulta especialmente útil para auditar los niveles de acceso basados en grupos y comprobar los permisos de usuario entre proyectos.

  • Para evitar el uso de datos obsoletos o almacenados en caché de consultas anteriores, añada Do not use previously fetched data a su indicación.