Prise en main des autorisations et de l’accès

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019 | TFS 2018

Dans cet article, découvrez comment gérer les niveaux d’accès et les autorisations via l’héritage, les groupes de sécurité, les rôles et bien plus encore dans Azure DevOps. Commencez par comprendre les concepts clés suivants.

  • À propos des autorisations :

    • Tous les utilisateurs ajoutés à Azure DevOps sont ajoutés à un ou plusieurs groupes de sécurité par défaut.
    • Les groupes de sécurité reçoivent des autorisations, qui autorisent ou refusent l’accès à une fonctionnalité ou à une tâche.
    • Les membres d’un groupe de sécurité héritent des autorisations attribuées au groupe.
    • Les autorisations sont définies à différents niveaux : organisation/collection, projet ou objet.
    • D’autres autorisations sont gérées via des attributions basées sur des rôles, telles que l’administrateur d’équipe, la gestion des extensions et divers rôles de ressources de pipeline.
    • Administration istrators peuvent définir des groupes de sécurité personnalisés pour gérer les autorisations pour différents domaines fonctionnels.
  • À propos des niveaux d’accès :

    • Tous les utilisateurs ajoutés à Azure DevOps sont affectés à un niveau d’accès, qui accorde ou restreint l’accès à certaines fonctionnalités du portail web.
    • Il existe trois niveaux d’accès principaux : Les parties prenantes, les plans de base et de base + test.
    • L’accès des parties prenantes offre un accès gratuit à un nombre illimité d’utilisateurs à un ensemble limité de fonctionnalités. Pour plus d’informations, consultez Référence rapide sur l’accès de partie prenante.
  • À propos des fonctionnalités en préversion :
    • À mesure que de nouvelles fonctionnalités sont introduites, les utilisateurs peuvent les activer ou les désactiver via les fonctionnalités d’évaluation pour y accéder.
    • Un petit sous-ensemble de nouvelles fonctionnalités est géré au niveau de l’organisation et activé ou désactivé par propriétaire d'organisation s.

Par exemple, la plupart des utilisateurs Azure DevOps sont ajoutés au groupe de sécurité Contributeurs et ont accordé un niveau d’accès de base . Le groupe Contributeurs fournit un accès en lecture et écriture aux référentiels , au suivi des travaux, aux pipelines, etc. L’accès de base permet d’accéder à toutes les fonctionnalités et tâches pour l’utilisation d’Azure Boards, d’Azure Repos, d’Azure Pipelines et d’Azure Artifacts. Les utilisateurs qui ont besoin d’accéder à la gestion des plans de test Azure doivent disposer d’un accès de base + Plan de test ou d’accès avancé .

Les administrateurs doivent être ajoutés au groupe Administrateurs de collection de projets ou Administrateurs de projet. Administration istrateurs gèrent les groupes de sécurité et les autorisations à partir du portail web, principalement à partir de Paramètres du projet. Les contributeurs gèrent également les autorisations pour les objets qu’ils créent à partir du portail web.

Pour une vue d'ensemble des autorisations par défaut, voir Informations de référence rapides sur les autorisations par défaut.

Groupes de sécurité et appartenance

Avec la création d’une organisation, d’une collection ou d’un projet, Azure DevOps crée un ensemble de groupes de sécurité par défaut, auxquels sont automatiquement attribuées des autorisations par défaut. D’autres groupes de sécurité sont définis avec les actions suivantes :

  • Lorsque vous créez des groupes de sécurité personnalisés aux niveaux suivants :
    • Niveau projet
    • Au niveau de l’organisation ou de la collection
    • Au niveau du serveur (local uniquement)
  • Lorsque vous ajoutez une équipe, un groupe de sécurité d’équipe est créé

Vous ne pouvez pas créer un groupe de sécurité au niveau de l’objet, mais vous pouvez affecter un groupe personnalisé à un niveau objet et attribuer des autorisations à ce niveau. Pour plus d’informations, consultez Définir des autorisations au niveau de l’objet.

Groupes de sécurité par défaut

Les groupes de sécurité suivants sont définis par défaut pour chaque projet et organisation. Vous ajoutez généralement des utilisateurs ou des groupes aux groupes Lecteurs, Contributeurs ou Project Administration istrateurs.

Project Organisation ou collection
- Générer des Administration istrateurs
-Contributeurs
- Project Administration istrators
- Projets utilisateurs valides
-Lecteurs
- Versions Administration istrateurs
- TeamName Team
- Collection de projets Administration istrateurs
- Build de collection de projets Administration istrators
- Comptes de service de génération de regroupement de projets
- Comptes de service proxy de regroupement de projets
- Comptes de service de collecte de projets
- Comptes de service de test de collecte de projets
- Regroupement de projets utilisateurs valides
- Utilisateurs dans l’étendue du projet
- Groupe de services de sécurité

Pour obtenir une description de chacun de ces groupes, consultez groupes de sécurité, comptes de service et autorisations. Pour connaître les attributions d’autorisations par défaut effectuées sur les groupes de sécurité par défaut les plus courants, consultez Autorisations et accès par défaut.

Les groupes de sécurité suivants sont définis par défaut pour chaque projet et collection de projets. Vous ajoutez généralement des utilisateurs ou des groupes aux groupes Lecteurs, Contributeurs ou Project Administration istrateurs.

La liste suivante indique les derniers groupes définis pour TFS 2017 et versions ultérieures. Pour les versions antérieures d’Azure DevOps, la liste peut différer. Ajoutez uniquement des comptes de service aux groupes de comptes de service Azure DevOps. Pour comprendre les groupes d’utilisateurs valides, consultez Groupes d’utilisateurs valides plus loin dans cet article.

Au niveau du projet Niveau de collecte
- Générer des Administration istrateurs
-Contributeurs
- Project Administration istrators
- Projets utilisateurs valides
-Lecteurs
- Versions Administration istrateurs
- TeamName Team
- Collection de projets Administration istrateurs
- Build de collection de projets Administration istrators
- Comptes de service de génération de regroupement de projets
- Comptes de service proxy de regroupement de projets
- Comptes de service de collecte de projets
- Comptes de service de test de collecte de projets
- Regroupement de projets utilisateurs valides
- Groupe de services de sécurité

Pour les utilisateurs chargés de gérer les fonctionnalités au niveau du projet( par exemple, les équipes, les chemins d’accès de zone et d’itération, les référentiels, les hooks de service et les points de terminaison de service), ajoutez-les au groupe Project Administration istrators. Pour les utilisateurs chargés de gérer les fonctionnalités au niveau de l’organisation ou de la collection, telles que les projets, les stratégies, les processus, les stratégies de rétention, les pools d’agents et de déploiement et les extensions, ajoutez-les au groupe collection de projets Administration istrateurs. Pour plus d’informations, consultez À propos des paramètres utilisateur, équipe, projet et organisation.

Pour obtenir une description de chaque groupe et de chaque autorisation, consultez référence Autorisations et groupes, Groupes.

Gestion des niveaux d’appartenance, d’autorisation et d’accès

Azure DevOps contrôle l’accès via ces trois zones fonctionnelles connectées :

  • La gestion des appartenances prend en charge l'ajout de comptes d'utilisateur individuels et de groupes aux groupes de sécurité par défaut. Chaque groupe par défaut est associé à un jeu d'autorisations par défaut. Tous les utilisateurs ajoutés à n’importe quel groupe de sécurité sont ajoutés au groupe Utilisateurs valides. Un utilisateur valide est une personne pouvant se connecter à un projet, une collection ou une organisation.

  • La gestion des autorisations contrôle l'accès aux tâches fonctionnelles spécifiques à différents niveaux du système. Les autorisations au niveau de l’objet définissent des autorisations sur un fichier, un dossier, un pipeline de build ou une requête partagée. Les paramètres d’autorisation correspondent à Autoriser, Refuser, Autoriser hérité, Refuser hérité, Autoriser le système, Refuser le système et Non défini. Pour plus d’informations, consultez Héritage des autorisations et groupes de sécurité plus loin dans cet article.

  • La gestion au niveau de l’accès contrôle l’accès aux fonctionnalités du portail web. En fonction de ce qui a été acheté pour un utilisateur, les administrateurs définissent le niveau d’accès de l’utilisateur sur Les parties prenantes, Basic, Basic+ Test ou Visual Studio Enterprise (précédemment Avancé).

Chaque zone fonctionnelle utilise des groupes de sécurité pour simplifier la gestion sur le déploiement. Vous ajoutez des utilisateurs et des groupes à travers le contexte d’administration web. Les autorisations sont automatiquement définies en fonction du groupe de sécurité auquel vous ajoutez des utilisateurs. Ou les autorisations s’appuient sur l’objet, le projet, la collection ou le niveau serveur auquel vous ajoutez des groupes.

L'appartenance à un groupe de sécurité peut être une combinaison d'utilisateurs, d'autres groupes et de groupes Microsoft Entra.

Les membres du groupe de sécurité peuvent être une combinaison d’utilisateurs, d’autres groupes et de groupes Active Directory ou d’un groupe de travail.

Vous pouvez créer des groupes locaux ou des groupes Active Directory (AD) pour gérer vos utilisateurs.

Groupes de sécurité Active Directory et Microsoft Entra

Vous pouvez remplir des groupes de sécurité en ajoutant des utilisateurs individuels. Toutefois, pour faciliter la gestion, il est plus facile de remplir ces groupes à l’aide de l’ID Microsoft Entra pour Azure DevOps Services et Active Directory (AD) ou des groupes d’utilisateurs Windows pour Azure DevOps Server. Cette méthode vous permet de gérer plus efficacement l’appartenance au groupe et les autorisations sur plusieurs ordinateurs.

Si vous n’avez qu’à gérer un petit ensemble d’utilisateurs, vous pouvez ignorer cette étape. Toutefois, si vous prévoyez que votre organisation peut croître, vous pouvez configurer Active Directory ou Microsoft Entra ID. En outre, si vous envisagez de payer des services supplémentaires, vous devez configurer l’ID Microsoft Entra pour une utilisation avec Azure DevOps pour prendre en charge la facturation.

Remarque

Sans ID Microsoft Entra, tous les utilisateurs Azure DevOps doivent se connecter à l’aide de comptes Microsoft, et vous devez gérer l’accès au compte par des comptes d’utilisateur individuels. Même si vous gérez l’accès au compte à l’aide de comptes Microsoft, vous devez configurer un abonnement Azure pour gérer la facturation.

Pour configurer l’ID Microsoft Entra à utiliser avec Azure DevOps Services, consultez Connecter votre organisation à l’ID Microsoft Entra.

Lorsque votre organisation est connectée à l’ID Microsoft Entra, il existe de nombreuses stratégies d’organisation que vous pouvez activer ou désactiver pour sécuriser votre organisation. Pour plus d’informations, consultez À propos de la sécurité, de l’authentification et de l’autorisation, des stratégies de sécurité.

Pour gérer l’accès organisationnel avec l’ID Microsoft Entra, reportez-vous aux articles suivants :

Azure DevOps inscrit les modifications apportées à un groupe Microsoft Entra dans un délai d’une heure après cette modification dans l’ID Microsoft Entra. Toutes les autorisations héritées via l’appartenance au groupe sont actualisées. Si vous souhaitez actualiser votre appartenance Microsoft Entra et les autorisations héritées dans Azure DevOps, déconnectez-vous, puis reconnectez-vous ou déclenchez une actualisation pour réévaluer votre autorisation.

Pour configurer Active Directory à utiliser avec Azure DevOps Server, consultez les articles suivants :

Installez Active Directory avant d’installer Azure DevOps Server.

Groupes d’utilisateurs valides

Lorsque vous ajoutez des comptes d’utilisateurs directement à un groupe de sécurité, ils sont automatiquement ajoutés à l’un des groupes d’utilisateurs valides.

  • Utilisateurs valides de la collection de projets : tous les membres ajoutés à un groupe au niveau de l’organisation.
  • Utilisateurs valides du projet : tous les membres ajoutés à un groupe au niveau du projet.
  • Serveur\Utilisateurs valides Azure DevOps : tous les membres ajoutés aux groupes au niveau du serveur.
  • ProjectCollectionName\Project Collection Valid Users : tous les membres ajoutés aux groupes au niveau de la collection.
  • ProjectName\Project Valid Users : tous les membres ajoutés aux groupes au niveau du projet.
  • Utilisateurs valides de Server\Team Foundation : tous les membres ajoutés aux groupes au niveau du serveur.
  • ProjectCollectionName\Project Collection Valid Users : tous les membres ajoutés aux groupes au niveau de la collection.
  • ProjectName\Project Valid Users : tous les membres ajoutés aux groupes au niveau du projet.

Les autorisations par défaut attribuées à ces groupes sont principalement limitées à l’accès en lecture, comme Afficher les ressources de génération, Afficher les informations au niveau du projet et Afficher les informations au niveau du regroupement.

Tous les utilisateurs que vous ajoutez à un projet peuvent afficher les objets d’autres projets au sein d’une collection. Si vous avez besoin de restreindre l’accès en vue, vous pouvez définir des restrictions via le nœud de chemin d’accès de zone.

Si vous supprimez ou refusez l’autorisation Afficher les informations au niveau de l’instance pour l’un des groupes Utilisateurs valides, aucun membre du groupe ne peut accéder au projet, à la collection ou au déploiement, en fonction du groupe que vous avez défini.

Project-Scoped groupe Utilisateurs

Par défaut, les utilisateurs ajoutés à un organization peuvent afficher toutes les informations et paramètres de organization et de projet. Ces paramètres incluent la liste des utilisateurs, la liste des projets, les détails de facturation, les données d’utilisation, etc. qui sont accessibles via les paramètres de l’organisation.

Important

  • Les fonctionnalités de visibilité limitée décrites dans cette section s’appliquent uniquement aux interactions via le portail web. Avec les API REST ou azure devops les commandes CLI, les membres du projet peuvent accéder aux données restreintes.
  • Les utilisateurs invités qui sont membres du groupe limité avec un accès par défaut dans l’ID Microsoft Entra ne peuvent pas rechercher d’utilisateurs avec le sélecteur de personnes. Lorsque la fonctionnalité d’aperçu est désactivée pour l’organisation ou lorsque les utilisateurs invités ne sont pas membres du groupe limité, les utilisateurs invités peuvent rechercher tous les utilisateurs De Microsoft Entra, comme prévu.

Pour restreindre les utilisateurs sélectionnés, tels que les parties prenantes, les utilisateurs invités Microsoft Entra ou les membres d’un groupe de sécurité particulier, vous pouvez activer la visibilité et la collaboration des utilisateurs sur des projets spécifiques en préversion pour l’organisation. Une fois cette option activée, tous les utilisateurs ou groupes ajoutés au groupe Utilisateurs délimités par le projet sont limités à l’accès aux pages des paramètres de l’organisation, à l’exception de La vue d’ensemble et des projets ; et sont limités à l’accès uniquement aux projets auxquels ils ont été ajoutés.

Avertissement

Lorsque la fonctionnalité Limiter la visibilité et la collaboration des utilisateurs à des projets spécifiques sont activées pour l’organisation, les utilisateurs délimités par le projet ne peuvent pas rechercher les utilisateurs qui ont été ajoutés à l’organisation par le biais de l’appartenance au groupe Microsoft Entra, plutôt que par le biais d’une invitation explicite à l’utilisateur. Il s’agit d’un comportement inattendu et une résolution est en cours de résolution. Pour résoudre automatiquement ce problème, désactivez la fonctionnalité limiter la visibilité et la collaboration des utilisateurs à des projets spécifiques en préversion pour l’organisation.

Pour plus d’informations, consultez Gérer les fonctionnalités en préversion.

Remarque

Les groupes de sécurité appartiennent au niveau de l’organisation, même s’ils accèdent uniquement à un projet spécifique. Certains groupes peuvent être masqués dans le portail web en fonction des autorisations de l’utilisateur. Vous trouverez tous les noms de groupe dans une organisation avec l’outil AZURE devops CLI ou nos API REST. Pour plus d’informations, consultez Ajouter et gérer des groupes de sécurité.

Remarque

Les groupes de sécurité appartiennent au niveau de la collection, même s’ils accèdent uniquement à un projet spécifique. Certains groupes peuvent être masqués dans le portail web en fonction des autorisations de l’utilisateur. Vous trouverez tous les noms de groupe dans une organisation avec l’outil AZURE devops CLI ou nos API REST. Pour plus d’informations, consultez Ajouter et gérer des groupes de sécurité.

Remarque

Les groupes de sécurité appartiennent au niveau de la collection, même s’ils accèdent uniquement à un projet spécifique. Certains groupes peuvent être masqués dans le portail web en fonction des autorisations de l’utilisateur. Toutefois, vous pouvez découvrir les noms de tous les groupes d’une organisation à l’aide des API REST. Pour plus d’informations, consultez Ajouter et gérer des groupes de sécurité.

Niveaux d’accès

Les niveaux d’accès contrôlent les fonctionnalités visibles par les utilisateurs dans le portail web. L’accès dépend des licences utilisateur.

Si vous souhaitez donner à un utilisateur l’accès aux fonctionnalités de gestion de portefeuille Agile ou de gestion des cas de test, modifiez les niveaux d’accès, et non les autorisations.

La définition du niveau d’accès pour les utilisateurs ou les groupes ne leur permet pas d’accéder à un projet ou au portail web. Seuls les utilisateurs ou groupes ajoutés à une équipe ou à un groupe de sécurité peuvent se connecter à un projet et au portail web. Assurez-vous que vos utilisateurs disposent des autorisations et du niveau d’accès dont ils ont besoin. Pour ce faire, assurez-vous qu’ils sont ajoutés au projet ou à une équipe.

Autorisations

Comme illustré dans l’image suivante, les groupes de sécurité définis au niveau du projet et de la collection peuvent être affectés aux autorisations affectées au niveau de l’objet, du projet et de l’organisation.

Conceptual image mapping default security groups to permission levels, cloud

Comme illustré dans l’image suivante, les groupes de sécurité définis au niveau du projet et de la collection peuvent être affectés aux autorisations affectées au niveau de l’objet, du projet et de la collection. Vous ne pouvez définir que des groupes de sécurité au niveau du serveur aux autorisations au niveau du serveur.

Conceptual image mapping default security groups to permission levels, on-premises

Conceptual image of security groups and permission levels, TFS-2018 and earlier versions

Pour obtenir une description de chaque groupe de sécurité par défaut, consultez Groupes de sécurité, comptes de service et autorisations.

États d’autorisation

Une autorisation peut avoir les affectations suivantes. Ils accordent ou limitent l’accès, comme indiqué.

L’utilisateur ou le groupe dispose des autorisations nécessaires pour effectuer une tâche :

  • Autoriser
  • Autoriser (hérité)
  • Autoriser (système)

L’utilisateur ou le groupe n’a pas l’autorisation d’effectuer une tâche :

  • Deny
  • Refuser (hérité)
  • Refuser (système)
  • Non défini
État de l’autorisation Description
Autoriser Accorde explicitement aux utilisateurs d’effectuer des tâches spécifiques et n’est pas hérité de l’appartenance au groupe.
Autoriser (hérité) Accorde aux membres du groupe d’effectuer des tâches spécifiques.
Autoriser (système) Accorde l’autorisation qui est prioritaire avant les autorisations utilisateur. Non modifiable et stocké dans une base de données de configuration, invisible pour les utilisateurs.
Deny Empêche explicitement les utilisateurs d’effectuer des tâches spécifiques et n’est pas hérité de l’appartenance au groupe. Pour la plupart des groupes et presque toutes les autorisations, Refuser l’emporte sur Autoriser. Si un utilisateur appartient à deux groupes et qu’un d’entre eux a un jeu d’autorisations spécifique sur Refuser, cet utilisateur ne peut pas effectuer de tâches nécessitant cette autorisation même si elle appartient à un groupe dont l’autorisation est définie sur Autoriser.
Refuser (hérité) Empêche les membres du groupe d’effectuer des tâches spécifiques. Remplace une autorisation explicite.
Refuser (système) Limite l’autorisation qui est prioritaire avant les autorisations utilisateur. Non modifiable et stocké dans une base de données de configuration, invisible pour les utilisateurs.
Non défini Refuse implicitement aux utilisateurs la possibilité d’effectuer des tâches qui nécessitent cette autorisation, mais autorise l’appartenance à un groupe disposant de cette autorisation à précédence, également appelée Autoriser (hérité) ou Refuser (hérité) .

Dans certains cas, les membres de la collection de projets Administration istrators ou des groupes Team Foundation Administration istrators peuvent toujours obtenir l’autorisation même s’ils sont refusés à cette autorisation dans un autre groupe. Dans d’autres cas, tels que la suppression d’éléments de travail ou les pipelines, être membre du groupe Collection de projets Administration istrators ne contourne pas le jeu d’autorisations Refuser un jeu d’autorisations ailleurs.

Avertissement

Lorsque vous modifiez une autorisation pour un groupe, elle modifie cette autorisation pour tous les utilisateurs membres de ce groupe. Selon la taille du groupe, vous pouvez affecter la capacité de centaines d’utilisateurs à effectuer leurs travaux en modifiant une seule autorisation. Veillez donc à comprendre les effets potentiels avant d’apporter une modification.

Héritage d’autorisations et groupes de sécurité

Certaines autorisations sont gérées via une hiérarchie. Dans cette hiérarchie, les autorisations peuvent être héritées du parent ou remplacées. Les groupes de sécurité attribuent un ensemble d’autorisations à ces membres du groupe. Par exemple, les membres du groupe Contributeurs ou du groupe Project Administration istrators reçoivent les autorisations définies comme autorisées pour ces groupes.

Si une autorisation n’est pas directement autorisée ou refusée pour un utilisateur, elle peut être héritée de la manière suivante.

  • Les utilisateurs héritent des autorisations des groupes auxquels ils appartiennent. Lorsqu’un utilisateur dispose d’une autorisation Autoriser l’appartenance directe ou de groupe, l’autorisation Refuser l’appartenance à un groupe ou directe l’remplace.

    Les membres de la collection de projets Administration istrators ou Team Foundation Administration istrators conservent la plupart des autorisations autorisées, même s’ils appartiennent à d’autres groupes qui refusent ces autorisations. Les autorisations d’opération d’élément de travail sont l’exception à cette règle.

  • Les autorisations au niveau de l’objet affectées aux nœuds d’une hiérarchie ( zones, itérations, dossiers de contrôle de version, dossiers de requête d’élément de travail) sont héritées de la hiérarchie. Autrement dit, les autorisations d’un utilisateur définies lors area-1 de l’obtention héritée area-1/sub-area-1, si la même autorisation n’est pas explicitement autorisée ou refusée pour area-1/sub-area-1. Si une autorisation est définie explicitement pour un objet, par area-1/sub-area-1exemple, le nœud parent n’est pas hérité, qu’il soit refusé ou autorisé. S’il n’est pas défini, les autorisations pour ce nœud sont héritées de l’ancêtre le plus proche qui dispose de l’autorisation explicitement définie. Enfin, dans la hiérarchie d’objets, la spécificité trompe l’héritage. Par exemple, un utilisateur dont les autorisations sont explicitement définies sur Refuser sur « area-1 », mais également explicitement définie sur Autoriser pour « area-1/sub-area-1 » reçoit une autorisation sur « area-1/sub-area-1 ».

Pour comprendre pourquoi une autorisation est héritée, vous pouvez suspendre sur un paramètre d’autorisation, puis choisir Pourquoi ? Pour ouvrir une page Sécurité , consultez Afficher les autorisations.

Remarque

Pour activer la page d’aperçu des paramètres des autorisations de projet, consultez Activer les fonctionnalités d’aperçu.

Permissions dialog, preview page, Why link annotated.

Une nouvelle boîte de dialogue s’ouvre qui affiche les informations d’héritage de cette autorisation.

L’interface utilisateur en préversion de la page des paramètres Des autorisations de projet n’est pas disponible pour Azure DevOps Server 2020 et les versions antérieures.

Bonnes pratiques pour les autorisations

À faire :

  • Utilisez les groupes de sécurité Microsoft Entra ID, Active Directory ou Windows lorsque vous gérez un grand nombre d’utilisateurs.
  • Lorsque vous ajoutez une équipe, tenez compte des autorisations que vous souhaitez attribuer aux prospects d’équipe, aux maîtres de l’équipe et à d’autres membres de l’équipe. Considérez qui crée et modifie les chemins d’accès de zone, les chemins d’itération et les requêtes.
  • Lorsque vous ajoutez de nombreuses équipes, envisagez de créer un groupe personnalisé d’Administration istrateurs d’équipe dans lequel vous pouvez allouer un sous-ensemble des autorisations disponibles pour Project Administration istrators.
  • Envisagez d’accorder aux dossiers de requête d’élément de travail l’autorisation Contribuer aux utilisateurs ou aux groupes qui nécessitent la possibilité de créer et de partager des requêtes d’élément de travail pour le projet.

À ne pas faire :

  • N’ajoutez pas d’utilisateurs à plusieurs groupes de sécurité, qui contiennent différents niveaux d’autorisation. Dans certains cas, un niveau d’autorisation Refuser peut remplacer un niveau d’autorisation Autoriser.
  • Ne modifiez pas les affectations par défaut apportées aux groupes Utilisateurs valides. Si vous supprimez ou affectez à l’autorisation Afficher les informations au niveau de l’instance la valeur Refuser pour l’un des groupes d’utilisateurs valides, aucun utilisateur du groupe ne pourra accéder au projet, à la collection ou au déploiement, selon le groupe défini.
  • N’affectez pas des autorisations notées comme « Affecter uniquement aux comptes de service » à des comptes d’utilisateur.

Autorisations basées sur les rôles

Avec les autorisations en fonction du rôle, vous attribuez des comptes d’utilisateur ou des groupes de sécurité à un rôle, chaque rôle ayant attribué une ou plusieurs autorisations. Voici les rôles principaux et les liens vers plus d’informations.

  • Rôles de sécurité d’artefact ou de flux de package : les rôles prennent en charge différents niveaux d’autorisation pour modifier et gérer les flux de package.
  • Rôle Gestionnaire d’extensions de la Place de marché : les membres du rôle Manager peuvent installer des extensions et répondre aux demandes d’installation des extensions.
  • Rôles de sécurité de pipeline : plusieurs rôles sont utilisés pour gérer les ressources de bibliothèque, les ressources de pipeline au niveau du projet et les ressources de pipeline au niveau du regroupement.
  • Les administrateurs d’équipe peuvent gérer tous les outils d’équipe.

Les membres des groupes Project Administration istrators ou Project Collection Administration istrators peuvent gérer tous les outils d’équipe pour toutes les équipes.

Fonctionnalités en version préliminaire

Les indicateurs de fonctionnalité contrôlent l’accès à la sélection, aux nouvelles fonctionnalités. Régulièrement, Azure DevOps introduit de nouvelles fonctionnalités en les plaçant derrière un indicateur de fonctionnalité. Les membres du projet et les propriétaire d'organisation peuvent activer ou désactiver les fonctionnalités en préversion. Pour plus d’informations, consultez Gérer ou activer des fonctionnalités.

Étapes suivantes