Configurer des groupes pour une utilisation locale dans Azure DevOps

  • Article

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

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 faciliter la gestion des utilisateurs et des autorisations entre ces programmes, vous pouvez créer des groupes d'utilisateurs avec des spécifications d'accès semblables dans le déploiement, attribuer à ces groupes des droits d'accès appropriés aux différents logiciels, puis simplement ajouter des utilisateurs à un groupe ou les en supprimer en fonction des besoins. C'est beaucoup plus facile que de mettre à jour les utilisateurs ou les 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 sont pas familiarisées avec Azure DevOps Server, peut entraîner des conséquences inattendues pour l’utilisateur lorsque l’appartenance change pour prendre en charge une autre fonction.

Le choix par défaut lors de l’installation consiste à utiliser le compte système 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 à des fins de sécurité ou pour d'autres raisons, par exemple pour un déploiement avec montée en puissance parallèle, vous le pouvez. 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 plutôt qu’un domaine, vous pouvez créer et utiliser des groupes locaux pour gérer les utilisateurs sur 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 fiables que les groupes et les comptes de domaine. Par exemple, en cas de défaillance du serveur, vous devrez recréer les groupes et les comptes à partir de zéro sur le nouveau serveur. Si vous utilisez des groupes et des comptes Active Directory, les groupes et les comptes sont conservés même si le serveur hébergeant Azure DevOps Server échoue.

Par exemple, après avoir discuté des besoins de l'entreprise concernant le nouveau déploiement et des conditions de sécurité avec les chefs de projet, vous pouvez décider de créer trois groupes pour gérer la plupart des utilisateurs dans le déploiement :

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

  • Un petit groupe d'administrateurs de projet qui auront les autorisations pour créer et gérer des projets de la collection. Vous pourriez nommer ce groupe TFS_ProjectAdmins.

  • Un groupe restreint spécial d'entrepreneurs qui auront uniquement accès à l'un des projets. Vous pourriez nommer ce groupe TFS_RestrictedAccess.

Par la suite, 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 groupe de domaine local, un groupe global ou un groupe universel dans Active Directory, suivant les besoins de votre organisation. Par exemple, si le groupe doit contenir des utilisateurs de plusieurs domaines, le type de groupe « universel » est celui qui correspondra 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 attribuez-lui un nom qui identifie rapidement son objectif. Par défaut, un groupe que vous créez a les autorisations équivalentes du groupe d'utilisateurs par défaut présent sur cet ordinateur. Pour plus d’informations, consultez Créer un groupe local.

Pour créer un compte à utiliser comme 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 ce qui suit

Ajouter des utilisateurs à des projets

Questions et réponses

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

R : Oui, vous pouvez. Vous pouvez créer des groupes spécifiques pour accorder ou restreindre l’accès à certaines fonctionnalités, fonctions et projets, pourgérer les niveaux d’accès et d’autres fins.