Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022
En raison de la vaste structure de sécurité et d’autorisation d’Azure DevOps, vous devrez peut-être examiner pourquoi un utilisateur n’a pas accès à un projet, un service ou une fonctionnalité qu’il attend. Recherchez des instructions pas à pas pour comprendre et résoudre les problèmes rencontrés par un utilisateur lors de la connexion à un projet ou de l’accès à un service ou une fonctionnalité Azure DevOps.
Prérequis
| Category | Spécifications |
|---|---|
| Permissions | Pour gérer les autorisations ou les groupes au niveau de l’organisation ou de la collection : membre du groupe de sécurité Administrateurs de la collection de projets. Si vous avez créé l’organisation ou la collection, vous êtes automatiquement membre de ce groupe. |
| Recommandation | Avant d’utiliser ce guide, nous vous recommandons de vous familiariser avec le contenu suivant : - Bien démarrer avec les autorisations, l’accès et les groupes de sécurité - Autorisations par défaut et Référence rapide d’accès. |
Conseil
Lorsque vous créez un groupe de sécurité Azure DevOps, étiquetez-le clairement pour indiquer s’il est destiné à limiter l’accès.
Vous pouvez définir des autorisations aux niveaux suivants :
- Au niveau de l'objet
- Au niveau du projet
- Au niveau de l’organisation ou de la collection du projet
- Rôle de sécurité
- Rôle d’administrateur d’équipe
Problèmes courants d’accès et d’autorisation
Consultez les raisons les plus courantes pour lesquelles un membre de projet ne peut pas accéder à un projet, un service ou une fonctionnalité :
| Problème | Action de résolution des problèmes |
|---|---|
| Leur niveau d’accès ne prend pas en charge l’accès au service ou à la fonctionnalité. | Pour déterminer si c’est la cause, déterminez le niveau d’accès et l’état de l’abonnement de l’utilisateur. |
| Leur appartenance à un groupe de sécurité ne prend pas en charge l’accès à une fonctionnalité ou elle a été explicitement refusée à une fonctionnalité. | Pour déterminer s'il s'agit de la cause, tracez une permission. |
| L’utilisateur a récemment reçu l’autorisation, mais son client a besoin d’une actualisation pour reconnaître les modifications. | Faites en sorte que l’utilisateur actualise ou réévalue ses autorisations. |
| L’utilisateur tente d’exercer une fonctionnalité accordée uniquement à un administrateur d’équipe pour une équipe spécifique, mais elle n’est pas accordée à ce rôle. | Pour les ajouter au rôle, consultez Ajouter, supprimer un administrateur d’équipe. |
| L’utilisateur n’a pas activé de fonctionnalité en préversion. | Demander à l’utilisateur d’ouvrir les fonctionnalités en préversion et de déterminer l’état activé/désactivé de la fonctionnalité spécifique. Pour plus d’informations, voir Gérer les fonctionnalités en préversion. |
| Le membre du projet a été ajouté à un groupe de sécurité d’étendue limitée, tel que le groupe Utilisateurs délimités par le projet. | Pour déterminer si c’est la cause, recherchez les appartenances au groupe de sécurité de l’utilisateur. |
Problèmes moins courants d’accès et d’autorisation
Les raisons moins courantes de l’accès limité se produisent lorsque l’un des événements suivants s’est produit :
| Problème | Action de résolution des problèmes |
|---|---|
| Un administrateur de projet a désactivé un service. Dans ce cas, personne n’a accès au service désactivé. | Pour déterminer si un service est désactivé, consultez Activer ou désactiver un service Azure DevOps. |
| Un administrateur de collection de projets a désactivé une fonctionnalité en préversion, ce qui la désactive pour tous les membres du projet de l’organisation. | Consultez Gérer les fonctionnalités en préversion. |
| Les règles de groupe qui régissent le niveau d’accès de l’utilisateur ou l’appartenance au projet limitent l’accès. | Consultez Déterminer le niveau d’accès et l’état de l’abonnement d’un utilisateur. |
| Les règles personnalisées ont été définies sur le flux de travail d’un type d’élément de travail. | consultez Règles appliquées à un type d’élément de travail qui limitent l’opération de sélection. |
Déterminer le niveau d’accès et l’état de l’abonnement d’un utilisateur.
Vous pouvez affecter des utilisateurs ou des groupes d’utilisateurs à l’un des niveaux d’accès suivants :
- Partie prenante
- De base
- Offres De base + Test
- Abonnement Visual Studio
- GitHub Enterprise
Pour plus d’informations sur la restriction des niveaux d’accès dans Azure DevOps, consultez Niveaux d’accès pris en charge.
Pour utiliser les fonctionnalités Azure DevOps, les utilisateurs doivent être ajoutés à un groupe de sécurité disposant des autorisations appropriées et avoir accès au portail web. Les limitations des fonctionnalités sont basées sur le niveau d’accès et le groupe de sécurité de l’utilisateur.
Les utilisateurs peuvent perdre l’accès pour les raisons suivantes :
| Raison de la perte d’accès | Action de résolution des problèmes |
|---|---|
| L’abonnement Visual Studio de l’utilisateur a expiré. | Cet utilisateur peut travailler en tant que partie prenante, ou vous pouvez accorder à l’utilisateur un accès de base jusqu’à ce que l’utilisateur renouvelle son abonnement. Une fois l’utilisateur connecté, Azure DevOps restaure automatiquement l’accès. |
| La licence GitHub Enterprise a expiré ou a été supprimée. | Consultez la section Faq/GitHub Enterprise. |
| L’abonnement Azure utilisé pour la facturation n’est plus actif. | Tous les achats effectués avec cet abonnement sont affectés, y compris les abonnements Visual Studio. Pour résoudre ce problème, consultez le portail des comptes Azure. |
| L’abonnement Azure utilisé pour la facturation a été supprimé de votre organisation. | En savoir plus sur liaison de votre organisation |
Sinon, les utilisateurs qui ne se connectaient pas à votre organisation pendant la durée la plus longue perdent d’abord l’accès. Si votre organisation a des utilisateurs qui n’ont plus besoin d’y accéder, supprimez-les de votre organisation.
Pour plus d’informations sur les autorisations, consultez Autorisations et groupes et le Guide de recherche des autorisations.
Retracer une permission
Utilisez le suivi des autorisations pour déterminer pourquoi les autorisations d’un utilisateur ne lui permettent pas d’accéder à une fonctionnalité ou à une fonction spécifique. Découvrez comment un utilisateur ou un administrateur peut examiner l’héritage des autorisations. Pour suivre une autorisation à partir du portail web, ouvrez la page d’autorisation ou de sécurité du niveau correspondant. Pour plus d’informations, consultez Demander une augmentation des niveaux d’autorisation.
Si un utilisateur rencontre des problèmes d’autorisations et que vous utilisez des groupes de sécurité ou des groupes personnalisés par défaut pour les autorisations, utilisez le suivi pour examiner l’emplacement de ces autorisations. Les problèmes d’autorisations peuvent être dus à des modifications retardées. Cela peut prendre jusqu’à 1 heure pour que les appartenances aux groupes Microsoft Entra ou les modifications d’autorisations se propagent dans Azure DevOps. Si un utilisateur rencontre des problèmes qui ne sont pas résolus immédiatement, attendez un jour pour voir s’ils sont résolus. Pour plus d’informations sur la gestion des utilisateurs et des accès, consultez Gérer les utilisateurs et l’accès dans Azure DevOps.
Si un utilisateur rencontre des problèmes d’autorisations et que vous utilisez des groupes de sécurité par défaut ou des groupes personnalisés pour les autorisations, vous pouvez examiner d’où viennent ces autorisations à l’aide de notre suivi des autorisations. Les problèmes d’autorisations peuvent être dus au fait que l’utilisateur n’a pas le niveau d’accès nécessaire.
Les utilisateurs peuvent recevoir leurs autorisations effectives directement ou via des groupes.
Effectuez les étapes suivantes pour que les administrateurs puissent comprendre d’où proviennent exactement ces autorisations et les ajuster, en fonction des besoins.
Sélectionnez Paramètres du projet>Autorisations>Utilisateurs, puis sélectionnez l’utilisateur.
Vous devez maintenant disposer d’une vue spécifique à l’utilisateur qui indique les autorisations dont il dispose.
Pour suivre la raison pour laquelle un utilisateur ne dispose d’aucune des autorisations répertoriées, sélectionnez l’icône d’informations à côté de l’autorisation en question.
La trace qui en résulte vous permet de savoir comment ils héritent de la permission mentionnée. Vous pouvez ensuite ajuster les autorisations de l’utilisateur en ajustant les autorisations fournies aux groupes dans lesquels il se trouve.
Sélectionnez Paramètres du projet>Sécurité, puis entrez le nom d’utilisateur dans la zone de filtre.
Vous devez maintenant disposer d’une vue spécifique à l’utilisateur qui indique les autorisations dont il dispose.
Suivez la raison pour laquelle un utilisateur ne dispose d’aucune des autorisations répertoriées. Pointez sur l’autorisation, puis choisissez Pourquoi.
La trace qui en résulte vous permet de savoir comment ils héritent de la permission mentionnée. Vous pouvez ensuite ajuster les autorisations de l’utilisateur en ajustant les autorisations fournies aux groupes dans lesquels il se trouve.
Pour plus d’informations, consultez Gérer l’accès à des fonctionnalités et fonctions spécifiques ou Demander une augmentation des niveaux d’autorisation.
Actualisez ou réévaluez les permissions
Consultez le scénario suivant dans lequel l’actualisation ou la réévaluation des autorisations peut être nécessaire.
Problème
Les utilisateurs sont ajoutés à un groupe Azure DevOps ou Microsoft Entra. Cette action accorde l’accès hérité à une organisation ou à un projet. Mais ils n’ont pas accès immédiatement. Les utilisateurs doivent attendre ou se déconnecter, fermer leur navigateur, puis se reconnecter pour que leurs autorisations soient actualisées.
Les utilisateurs sont ajoutés à un groupe Azure DevOps. Cette action accorde l’accès hérité à une organisation ou à un projet. Mais ils n’ont pas accès immédiatement. Les utilisateurs doivent attendre ou se déconnecter, fermer leur navigateur, puis se reconnecter pour que leurs autorisations soient actualisées.
Solution
Accédez aux 
Paramètres utilisateur>Autorisations>Réévaluer les autorisations. Cette fonction réévalue vos appartenances aux groupes et les autorisations, après quoi toutes les modifications récentes prennent immédiatement effet.
Règles appliquées à un type d’élément de travail qui limitent l’opération de sélection.
Avant de personnaliser un processus, nous vous recommandons de consulter Configurer et personnaliser Azure Boards, qui fournit des conseils sur la façon de personnaliser Azure Boards pour répondre aux besoins de votre entreprise.
Pour plus d’informations sur les règles de type d’élément de travail qui s’appliquent aux opérations de restriction, consultez :
- Appliquer des règles aux états de workflow (processus d’héritage)
- Exemples de scénarios de règle
- Définir les chemins de zone et les assigner à une équipe
Masquer les paramètres de l’organisation aux utilisateurs
Si un utilisateur ne voit que ses projets ou ne peut pas accéder aux paramètres de l’organisation, les informations suivantes peuvent expliquer pourquoi. Pour limiter l'accès d’utilisateurs aux paramètres de l'organisation, activez la fonctionnalité en préversion Limiter la visibilité et la collaboration des utilisateurs à des projets spécifiques. Si vous souhaitez obtenir plus d’informations, notamment sur les appels importants liés à la sécurité, consultez Gérer votre organisation, limiter la visibilité des utilisateurs pour des projets, etc.
Par exemple, les utilisateurs restreints incluent les parties prenantes, les utilisateurs invités Microsoft Entra ou les membres d’un groupe de sécurité. Une fois activé, tous les utilisateurs ou groupes ajoutés au groupe des utilisateurs affectés à un projet ne peuvent plus accéder aux pages Paramètres de l'organisation, à l’exception des pages Vue d'ensemble et Projets. Ils peuvent uniquement accéder aux projets auxquels ils sont ajoutés.
Les parties prenantes ou les membres d’un groupe de sécurité sont des exemples d’utilisateurs restreints. Une fois activé, tous les utilisateurs ou groupes ajoutés au groupe des utilisateurs affectés à un projet ne peuvent plus accéder aux pages Paramètres de l'organisation, à l’exception des pages Vue d'ensemble et Projets. Ils peuvent uniquement accéder aux projets auxquels ils sont ajoutés.
Pour plus d’informations, consultez Gérer votre organisation, limiter la visibilité des utilisateurs pour les projets, etc.
Afficher, ajouter et gérer des autorisations avec l’interface CLI
Vous pouvez afficher, ajouter et gérer des autorisations à un niveau granulaire avec les az devops security permission commandes. Pour plus d’informations, consultez Gérer les autorisations avec l’outil en ligne de commande.
Règles de groupe avec moins d’autorisations
Les types de règles de groupe sont classés dans l'ordre suivant : Abonné > Basique + Plans de test > Basique > Partie prenante. Les utilisateurs reçoivent toujours le niveau d’accès le plus élevé disponible pour eux dans toutes les règles de groupe, y compris tous les abonnements Visual Studio (VS).
Note
- Azure DevOps applique les ressources accordées par les règles de groupe à tous les membres du groupe configuré. Toutefois, l’accès et les autorisations prennent effet uniquement après que l’utilisateur se connecte à l’organisation pour la première fois.
- Passez régulièrement en revue les règles répertoriées sous l’onglet Règles de groupe de la page Utilisateurs . Les modifications apportées à l’appartenance au groupe Microsoft Entra ID apparaissent lors de la nouvelle évaluation de la règle de groupe suivante, qui se produit :
- À la demande lorsque vous le déclenchez manuellement
- Automatiquement lorsque vous modifiez une règle de groupe
- Automatiquement toutes les 24 heures. Azure DevOps met à jour l’appartenance au groupe Microsoft Entra toutes les heures, mais l’ID Microsoft Entra peut prendre jusqu’à 24 heures pour mettre à jour l’appartenance dynamique au groupe.
- Les règles de groupe pour les licences ne s’appliquent actuellement pas aux principaux de service et aux identités managées. Pour affecter un niveau d’accès à un principal de service ou une identité managée, affectez-le directement plutôt qu’via l’appartenance au groupe. Pour plus d’informations, veuillez consulter la section Utiliser des principaux de service & identités managées dans Azure DevOps.
Consultez les exemples suivants, montrant comment la détection des abonnés prend en compte les règles de groupe.
Exemple 1 : La règle de groupe me donne plus d’accès
Que se passe-t-il si j’ai un abonnement VS Pro et que je suis dans une règle de groupe qui me donne Basic + Test Plans ?
Attendu : Je reçois les plans de base + les plans de test parce que ce que la règle de groupe me donne est supérieur à mon abonnement. L’attribution de règle de groupe fournit toujours un accès plus important, au lieu de limiter l’accès.
Exemple 2 : la règle de groupe me donne le même accès
J’ai un abonnement Visual Studio Test Pro et je suis dans une règle de groupe qui me donne Basic + Test Plans . Que se passe-t-il ?
Attendu : Je suis détecté comme un abonné Visual Studio Test Pro, car l'accès est le même que la règle de groupe. Je paie déjà pour Visual Studio Test Pro, je ne veux donc pas payer à nouveau.
Utiliser GitHub
Consultez les informations de résolution des problèmes suivantes pour déployer du code dans Azure DevOps avec GitHub.
Problème
Vous ne pouvez pas amener le reste de votre équipe dans l’organisation et le projet, même si vous les avez ajoutés en tant que membres. Ils reçoivent des e-mails, mais lors de la connexion, ils obtiennent une erreur 401.
Solution
Vous êtes peut-être connecté à Azure DevOps avec une identité incorrecte. Effectuez les étapes suivantes :
Fermez tous les navigateurs, y compris les navigateurs qui n’exécutent pas Azure DevOps.
Ouvrez une session de navigation privée ou incognito.
Accédez à l'URL suivante : https://aka.ms/vssignout.
Un message s’affiche : « Déconnexion en cours ». Une fois que vous êtes déconnecté, vous êtes redirigé vers
dev.azure.microsoft.com.Connectez-vous à nouveau à Azure DevOps et choisissez une autre identité.
Utiliser l’IA pour résoudre les problèmes d’accès et d’autorisations
L’exemple d’invite suivant pour Copilot Chat vous aide à résoudre les problèmes liés aux autorisations Azure DevOps, aux niveaux d’accès et aux problèmes de groupe de sécurité. Copiez et collez cette invite dans Copilot Chat, en remplaçant les espaces réservés par vos informations spécifiques.
Pour obtenir la meilleure assistance ia, incluez des détails spécifiques, comme le niveau d’accès de l’utilisateur, les groupes de sécurité auxquels ils appartiennent, les fonctionnalités spécifiques auxquelles ils ne peuvent pas accéder et les messages d’erreur qu’ils reçoivent.
I'm having this Azure DevOps permissions/access issue: [PASTE YOUR ERROR MESSAGE OR DESCRIBE THE PROBLEM]
User and permission details:
- User's access level: [Stakeholder/Basic/Basic + Test Plans/Visual Studio subscription]
- Security groups: [LIST GROUPS like Project Contributors, Project Readers, etc.]
- Feature they can't access: [SPECIFIC FEATURE like work items, repos, pipelines, etc.]
- Project name: [PROJECT NAME if applicable]
- Organization name: [ORGANIZATION NAME if applicable]
- Error message: [EXACT ERROR MESSAGE if any]
Can you help me troubleshoot this issue? Please provide step-by-step instructions to:
1. Identify the root cause of the permissions problem
2. Fix the access level, security group membership, or permission settings
3. Verify the user can successfully access the feature
Context: This is for troubleshooting user access and permissions in Azure DevOps. The issue might be related to access levels, security group memberships, project-level permissions, organization settings, or feature-specific restrictions.
Copilot est alimenté par l’IA, donc les surprises et les erreurs sont possibles. Pour plus d’informations, consultez les FAQ sur l’utilisation générale de Copilot.
Autres zones où les autorisations peuvent être appliquées
- Autorisations de chemin d'accès aux zones
- Étiquettes d’élément de travail
- Éléments de travail déplacés hors d'un projet
- Éléments de travail supprimés
- Guide rapide des autorisations et de l’accès par défaut pour Azure Boards
- Règles personnalisées
- Exemples de scénarios de règles personnalisées
- Backlogs et tableaux personnalisés
- Contrôles personnalisés