Compartir a través de


Configuración de grupos para su uso en Azure DevOps local

Azure DevOps Server |Azure DevOps Server |Azure DevOps Server 2022 | Azure DevOps Server 2020

La administración de usuarios en Azure DevOps Server es mucho más fácil si crea grupos de Windows o Active Directory para ellos, especialmente si la implementación incluye SQL Server Reporting Services.

Usuarios, grupos y permisos en implementaciones de Azure DevOps Server

Azure DevOps Server y SQL Server Reporting Services mantienen su propia información sobre grupos, usuarios y permisos. Para simplificar la administración de usuarios y permisos en estos programas, puede crear grupos de usuarios con requisitos de acceso similares en la implementación, conceder a esos grupos acceso adecuado en los diferentes programas de software y, a continuación, simplemente agregar o quitar usuarios de un grupo según sea necesario. Esto es mucho más fácil que mantener usuarios individuales o grupos de usuarios por separado en tres programas independientes.

Si el servidor está en un dominio de Active Directory, una opción es crear grupos específicos de Active Directory para administrar los usuarios, como un grupo de desarrolladores y evaluadores para todos los proyectos de la colección de proyectos, o un grupo de usuarios que pueden crear y administrar proyectos en la colección. Del mismo modo, puede crear una cuenta de Active Directory para los servicios que no se pueden configurar para usar la cuenta del sistema de servicio de red como cuenta de servicio. Para ello, cree una cuenta de Active Directory para el origen de datos con acceso de lectura para los informes en SQL Server Reporting Services.

Importante

Si decide usar grupos de Active Directory en Azure DevOps Server, considere la posibilidad de crear uno específico cuyo propósito esté dedicado a la administración de usuarios en Azure DevOps Server. El uso de grupos existentes creados anteriormente para otro propósito, especialmente si son administrados por otros usuarios que no están familiarizados con Azure DevOps Server, pueden provocar consecuencias inesperadas del usuario cuando los cambios de pertenencia admiten alguna otra función.

La opción predeterminada durante la instalación es usar la cuenta del sistema de servicio de red como cuenta de servicio para Azure DevOps Server y SQL Server. Si desea usar una cuenta específica como cuenta de servicio con fines de seguridad u otros motivos, como una implementación escalada, puede hacerlo. También puede crear una cuenta de Active Directory específica para usarla como cuenta de servicio para la cuenta de lector de origen de datos para SQL Server Reporting Services.

Si el servidor está en un dominio de Active Directory, pero no tiene permisos para crear grupos o cuentas de Active Directory, o si va a instalar el servidor en un grupo de trabajo en lugar de un dominio, puede crear y usar grupos locales para administrar usuarios entre SQL Server y Azure DevOps Server. Del mismo modo, puede crear una cuenta local para usarla como cuenta de servicio. Sin embargo, tenga en cuenta que los grupos y cuentas locales no son tan sólidos como grupos de dominio y cuentas. Por ejemplo, en caso de error de servidor, tendría que volver a crear los grupos y las cuentas desde cero en el nuevo servidor. Si usa grupos y cuentas de Active Directory, los grupos y las cuentas se conservarán incluso si se produce un error en el servidor que hospeda Azure DevOps Server.

Por ejemplo, después de revisar los requisitos empresariales de la nueva implementación y los requisitos de seguridad con los administradores de proyectos, puede decidir crear tres grupos para administrar la mayoría de los usuarios de la implementación:

  • Un grupo general para desarrolladores y evaluadores que participarán plenamente en todos los proyectos de la colección de proyectos predeterminada. Este grupo contendrá la mayoría de los usuarios. Puede asignar un nombre a este grupo TFS_ProjectContributors.

  • Un pequeño grupo de administradores de proyectos que tendrán permisos para crear y administrar proyectos en la colección. Puede asignar un nombre a este grupo TFS_ProjectAdmins.

  • Un grupo especial restringido de contratistas que solo tendrán acceso a uno de los proyectos. Puede asignar un nombre a este grupo TFS_RestrictedAccess.

Más adelante, a medida que se expanda la implementación, puede decidir crear otros grupos.

Para crear un grupo en Active Directory

  • Cree un grupo de seguridad que sea un dominio local, un grupo global o universal en Active Directory, como mejor se adapte a sus necesidades empresariales. Por ejemplo, si el grupo necesita contener usuarios de más de un dominio, el tipo de grupo universal se adaptará mejor a sus necesidades. Para obtener más información, vea Crear un nuevo grupo (Active Directory Domain Services) .

Para crear un grupo local en el servidor

  • Cree un grupo local y asígnele un nombre que identifique rápidamente su propósito. De forma predeterminada, cualquier grupo que cree tendrá los permisos equivalentes del grupo predeterminado Usuarios en ese equipo. Para obtener más información, consulte Creación de un grupo local.

Para crear una cuenta que se va a usar como cuenta de servicio en Active Directory

Para crear una cuenta local que se va a usar como cuenta de servicio en el servidor

  • Cree una cuenta local para usarla como cuenta de servicio y, a continuación, modifique su pertenencia a grupos y otras propiedades según los requisitos de seguridad de su empresa. Para obtener más información, consulte Creación de una cuenta de usuario local.

Pruebe esto a continuación

Preguntas y respuestas

P: ¿Puedo usar grupos para restringir el acceso a proyectos o características en Azure DevOps Server?

Un: Sí, puedes. Puede crear grupos específicos para conceder o restringir el acceso a características, funciones y proyectos seleccionados para administrar los niveles de acceso y otros fines.