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

  • Artículo

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

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 mantener 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 el acceso adecuado en los distintos programas de software y después simplemente agregar o quitar usuarios en cada 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 de Active Directory específicos 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. De forma similar, puede crear una cuenta de Active Directory para los servicios que no se pueden configurar para usar la cuenta del sistema Network Service como cuenta de servicio. Para ello, cree una cuenta de Active Directory para la cuenta de origen de datos de acceso de lectura para los informes de SQL Server Reporting Services.

Importante

Si decide usar grupos de Active Directory en Azure DevOps Server, considere la posibilidad de crear determinados cuyo propósito esté dedicado a la administración de usuarios en Azure DevOps Server. El uso de grupos existentes creados previamente para otro propósito, especialmente si los administran otros usuarios que no están familiarizados con Azure DevOps Server, pueden dar lugar a 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 concreta como cuenta de servicio por motivos de seguridad u otras razones, como una implementación escalada, puede hacerlo. También puede crear una cuenta específica de Active Directory 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 cuentas o grupos 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. De igual forma, puede crear una cuenta local para usarla como cuenta de servicio. Sin embargo, tenga presente que los grupos y cuentas locales no son tan sólidos como los grupos y cuentas de dominio. Por ejemplo, en caso de error del servidor, deberá volver a crear los grupos y cuentas desde cero en el nuevo servidor. Si usa cuentas y grupos de Active Directory, los grupos y 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 comerciales 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á a la mayoría de los usuarios. Puede denominar a este grupo TFS_ProjectContributors.

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

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

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

Para crear un grupo en Active Directory

  • Cree un grupo de seguridad que sea de tipo global, universal o de dominio local en Active Directory, la opción que mejor se adapte a sus necesidades empresariales. Por ejemplo, si el grupo debe contener usuarios de varios dominios, el tipo de grupo universal será el que más le convenga. Para obtener más información, vea Crear un nuevo grupo (Servicios de dominio de Active Directory).

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 al grupo Usuarios predeterminado de ese equipo. Para obtener más información, consulte Creación de un grupo local.

Para crear una cuenta con el fin de usarla como cuenta de servicio en Active Directory

Para crear una cuenta local con el fin de usarla 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 grupo y otras propiedades en función de los requisitos de seguridad de su negocio. Para obtener más información, consulte Creación de una cuenta de usuario local.

Pruebe esto a continuación

Adición de usuarios a proyectos

Preguntas y respuestas

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

R: Sí, puede hacerlo. 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.