Partager via


Configurer des groupes à utiliser dans Azure DevOps en local

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

La gestion des utilisateurs dans Azure DevOps Server est beaucoup plus facile si vous créez des groupes Windows ou Active Directory pour eux, en particulier si votre déploiement inclut SQL Server Reporting Services.

Utilisateurs, groupes et autorisations dans les déploiements Azure DevOps Server

Azure DevOps Server et SQL Server Reporting Services conservent toutes leurs propres informations sur les groupes, les utilisateurs et les autorisations. Pour simplifier la gestion des utilisateurs et des autorisations dans ces programmes, vous pouvez créer des groupes d’utilisateurs avec des exigences d’accès similaires dans le déploiement, accorder à ces groupes un accès approprié dans les différents programmes logiciels, puis simplement ajouter ou supprimer des utilisateurs d’un groupe en fonction des besoins. Cela est beaucoup plus facile que de conserver des utilisateurs individuels ou des groupes d’utilisateurs séparément dans trois programmes distincts.

Si votre serveur se trouve dans un domaine Active Directory, une option consiste à créer des groupes Active Directory spécifiques pour gérer vos utilisateurs, comme un groupe de développeurs et de testeurs pour tous les projets de la collection de projets, ou un groupe d’utilisateurs qui peuvent créer et administrer des projets dans la collection. De même, vous pouvez créer un compte Active Directory pour les services qui ne peuvent pas être configurés pour utiliser le compte système de service réseau comme compte de service. Pour ce faire, créez un compte Active Directory pour le compte de source de données d’accès en lecture pour les rapports dans SQL Server Reporting Services.

Important

Si vous décidez d’utiliser des groupes Active Directory dans Azure DevOps Server, envisagez de créer des groupes spécifiques dont l’objectif est dédié à la gestion des utilisateurs dans Azure DevOps Server. L’utilisation de groupes existants précédemment créés à d’autres fins, en particulier s’ils sont gérés par d’autres personnes qui ne connaissent pas Azure DevOps Server, peut entraîner des conséquences inattendues sur les utilisateurs lorsque les modifications d’appartenance prennent en charge une autre fonction.

Le choix par défaut pendant l’installation consiste à utiliser le compte de système de service réseau comme compte de service pour Azure DevOps Server et SQL Server. Si vous souhaitez utiliser un compte spécifique comme compte de service pour des raisons de sécurité ou d'autres motifs, telles qu'un déploiement étendu, vous pouvez le faire. Vous pouvez également créer un compte Active Directory spécifique à utiliser comme compte de service pour le compte de lecteur de source de données pour SQL Server Reporting Services.

Si votre serveur se trouve dans un domaine Active Directory, mais que vous n’avez pas les autorisations nécessaires pour créer des groupes ou des comptes Active Directory, ou si vous installez votre serveur dans un groupe de travail au lieu d’un domaine, vous pouvez créer et utiliser des groupes locaux pour gérer les utilisateurs dans SQL Server et Azure DevOps Server. De même, vous pouvez créer un compte local à utiliser comme compte de service. Toutefois, gardez à l’esprit que les groupes et comptes locaux ne sont pas aussi robustes que les groupes de domaine et les comptes. Par exemple, en cas d’échec du serveur, vous devez recréer les groupes et comptes à partir de zéro sur le nouveau serveur. Si vous utilisez des groupes et comptes Active Directory, les groupes et comptes sont conservés même si le serveur hébergeant Azure DevOps Server échoue.

Par exemple, après avoir examiné les exigences métier pour le nouveau déploiement et les exigences de sécurité avec les responsables de projet, vous pouvez décider de créer trois groupes pour gérer la majorité des utilisateurs dans le déploiement :

  • Groupe général pour les développeurs et les testeurs qui participeront entièrement à tous les projets de la collection de projets par défaut. Ce groupe contiendra la majorité des utilisateurs. Vous pouvez nommer ce groupe TFS_ProjectContributors.

  • Un petit groupe d’administrateurs de projet disposant des autorisations nécessaires pour créer et gérer des projets dans la collection. Vous pouvez nommer ce groupe TFS_ProjectAdmins.

  • Un groupe spécial et restreint de sous-traitants qui n’auront accès qu’à l’un des projets. Vous pouvez nommer ce groupe TFS_RestrictedAccess.

Plus tard, au fur et à mesure que le déploiement se développe, vous pouvez décider de créer d’autres groupes.

Pour créer un groupe dans Active Directory

  • Créez un groupe de sécurité qui est un domaine local, un groupe global ou universel dans Active Directory, selon les besoins de votre entreprise. Par exemple, si le groupe doit contenir des utilisateurs de plusieurs domaines, le type de groupe universel convient le mieux à vos besoins. Pour plus d’informations, consultez Créer un groupe (Services de domaine Active Directory).

Pour créer un groupe local sur le serveur

  • Créez un groupe local et donnez-lui un nom qui identifiera rapidement son objectif. Par défaut, tout groupe que vous créez dispose des autorisations équivalentes du groupe Utilisateurs par défaut sur cet ordinateur. Pour plus d’informations, consultez Créer un groupe local.

Pour créer un compte à utiliser en tant que compte de service dans Active Directory

Pour créer un compte local à utiliser comme compte de service sur le serveur

  • Créez un compte local à utiliser comme compte de service, puis modifiez son appartenance au groupe et d’autres propriétés en fonction des exigences de sécurité de votre entreprise. Pour plus d’informations, consultez Créer un compte d’utilisateur local.

Essayez ensuite cela

Questions & réponses

Q : Puis-je utiliser des groupes pour restreindre l’accès aux projets ou fonctionnalités dans Azure DevOps Server ?

Un: Si, tu peux. Vous pouvez créer des groupes spécifiques pour accorder ou restreindre l’accès à certaines fonctionnalités, fonctions et projets, pour gérer les niveaux d’accès et d’autres fins.