Résoudre les problèmes d’accès et d’autorisation

Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2019

En raison de la structure étendue de sécurité et d’autorisation d’Azure DevOps, vous pouvez déterminer pourquoi un utilisateur n’a pas accès à un projet, à un service ou à une fonctionnalité qu’il attend. Trouvez des instructions pas à pas pour comprendre et résoudre les problèmes qu’un membre du projet peut rencontrer lors de la connexion à un projet ou de l’accès à un service ou à une fonctionnalité Azure DevOps.

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 d’une manière facile à déterminer s’il a été créé pour limiter l’accès.

Les autorisations sont définies à l’un des niveaux suivants :

• au niveau de l’objet
• au niveau du projet
• au niveau de l’organisation ou de la collection de projets
• rôle de sécurité
• rôle administrateur d’équipe

Problèmes courants d’accès et d’autorisation

Consultez les raisons les plus courantes pour lesquelles un membre du 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 leur autorisation a été explicitement refusée.	Pour déterminer s’il s’agit de la cause, tracez une autorisation.
L’autorisation a récemment été accordée à l’utilisateur, mais une actualisation est nécessaire pour que son client reconnaisse les modifications.	Faites en ce 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 ce rôle ne lui a pas été attribué.	Pour les ajouter au rôle, consultez Ajouter, supprimer un administrateur d’équipe.
L’utilisateur n’a pas activé de fonctionnalité d’aperçu.	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, consultez 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 Project-Scoped.	Pour déterminer si c’est la cause, recherchez les appartenances au groupe de sécurité de l’utilisateur.

Problèmes d’accès et d’autorisation moins courants

Les raisons moins courantes de l’accès limité sont 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é d’aperçu, 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.
Des règles personnalisées ont été définies pour le workflow 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
• De base + Test Plans
• Abonnement Visual Studio

Pour plus d’informations sur la restriction du niveau 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é avec les autorisations appropriées. Les utilisateurs doivent également accéder au portail web. Les limitations de sélection des fonctionnalités sont basées sur le niveau d’accès et le groupe de sécurité auquel un utilisateur est affecté.

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é.	Pendant ce temps, cet utilisateur peut travailler en tant que partie prenante, ou vous pouvez lui accorder l’accès de base jusqu’à ce que l’utilisateur renouvelle son abonnement. Une fois l’utilisateur connecté, Azure DevOps restaure automatiquement l’accès.
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 la liaison de votre organisation

Sinon, le premier jour du mois calendaire, les utilisateurs qui ne se sont pas connectés à votre organisation depuis le plus longtemps 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 autorisations.

Suivre une autorisation

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é 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 à des modifications retardées. Il 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.

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.

1. Sélectionnez Paramètres> du projetAutorisations>Utilisateurs, puis sélectionnez l’utilisateur.

   

   Vous devez maintenant disposer d’une vue spécifique à l’utilisateur qui indique les autorisations dont il dispose.

2. Pour suivre la raison pour laquelle un utilisateur ne dispose d’aucune des autorisations répertoriées, sélectionnez l’icône d’informations en regard de l’autorisation en question.

La trace obtenue vous permet de savoir comment ils héritent de l’autorisation répertorié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 Accorder ou restreindre l’accès à certaines fonctionnalités et fonctions ou Demander une augmentation des niveaux d’autorisation.

Actualiser ou réévaluer les autorisations

Consultez le scénario suivant où l’actualisation ou la réévaluation des autorisations peuvent être nécessaires.

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 actualiser leurs autorisations.

Solution

Dans Paramètres utilisateur, dans la page Autorisations , vous pouvez sélectionner Réévaluer les autorisations. Cette fonction réévalue vos appartenances et autorisations de groupe, puis toutes les modifications récentes prennent effet immédiatement.

Règles appliquées à un type d’élément de travail qui limitent les opérations 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 se limite à voir uniquement ses projets ou à voir les paramètres de l’organisation, les informations suivantes peuvent expliquer pourquoi. Pour empêcher les utilisateurs d’accéder aux paramètres de l’organisation, vous pouvez activer la fonctionnalité d’aperçu Limiter la visibilité et la collaboration des utilisateurs à des projets spécifiques . Pour plus d’informations, notamment sur les appels importants liés à la sécurité, consultez Gérer votre organisation, Limiter la visibilité des utilisateurs pour les 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 l’option activée, tout utilisateur ou groupe ajouté au groupe Project-Scoped Utilisateurs ne peut pas accéder aux pages Paramètres de l’organisation, à l’exception de La vue d’ensemble et des projets. Ils sont limités à l’accès uniquement aux projets auxquels ils ont été ajoutés.

Les parties prenantes ou les membres d’un groupe de sécurité sont des exemples d’utilisateurs restreints. Une fois l’option activée, tout utilisateur ou groupe ajouté au groupe Project-Scoped Utilisateurs ne peut pas accéder aux pages Paramètres de l’organisation, à l’exception de La vue d’ensemble et des projets. Ils sont limités à l’accès uniquement aux projets auxquels ils ont été ajoutés.

Pour plus d’informations sur la façon de masquer les paramètres de l’organisation aux utilisateurs, 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 plus 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é > De base + Test Plans > Partie prenante de base>. Les utilisateurs obtiennent toujours le meilleur niveau d’accès entre toutes les règles de groupe, y compris l’abonnement Visual Studio (VS).

Remarque

• Les modifications apportées aux lecteurs de projet par le biais de règles de groupe ne sont pas conservées. Si vous devez ajuster les lecteurs de projet, envisagez d’autres méthodes, telles que l’affectation directe ou les groupes de sécurité personnalisés.
• Nous vous recommandons de consulter régulièrement les règles répertoriées sous l’onglet « Règles de groupe » de la page « Utilisateurs ». Si des modifications sont apportées à l’appartenance au groupe d’ID Microsoft Entra, ces modifications s’affichent dans la prochaine nouvelle évaluation des règles de groupe, qui peuvent être effectuées à la demande, lorsqu’une règle de groupe est modifiée ou automatiquement toutes les 24 heures. Azure DevOps met à jour l’appartenance au groupe Microsoft Entra toutes les heures, mais cela peut prendre jusqu’à 24 heures pour que l’ID Microsoft Entra met à jour l’appartenance à un groupe dynamique.

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

Si j’ai un abonnement VS Pro et que je suis dans une règle de groupe qui me donne Basic + Test Plans, que se passe-t-il ?

Attendu : Je reçois Basic + Test Plans, car 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é en tant qu’abonné Visual Studio Test Pro, car l’accès est identique à la règle de groupe. Je paie déjà pour Visual Studio Test Pro, donc je ne veux pas payer à nouveau.

Utiliser GitHub

Consultez les informations de résolution des problèmes suivantes lorsque vous essayez de déployer du code dans Azure DevOps avec GitHub.

Problème

Vous ne pouvez pas intégrer le reste de votre équipe dans l’organisation et le projet, même si vous les avez ajoutés en tant que membres de l’organisation et du projet. Ils reçoivent des e-mails, mais quand ils se connectent, ils reçoivent une erreur 401.

Solution

Vous êtes probablement connecté à Azure DevOps avec une identité incorrecte. Effectuez ensuite les tâches suivantes.

1. Fermez tous les navigateurs, y compris les navigateurs qui n’exécutent pas Azure DevOps.

2. Ouvrez une session de navigation privée ou incognito.

3. Accédez à l'URL suivante : https://aka.ms/vssignout.

   Un message s’affiche et indique « Se déconnecter en cours ». Une fois que vous vous êtes déconnecté, vous êtes redirigé vers dev.azure.microsoft.com.

4. Reconnectez-vous à Azure DevOps . Sélectionnez votre autre identité.

Autres zones où les autorisations peuvent être appliquées

• Autorisations de chemin d’accès à la zone
• Étiquettes d’élément de travail
• Déplacement d’éléments de travail 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ègle personnalisée
• Backlogs et tableaux personnalisés
• Contrôles personnalisés

Articles connexes

• Gérer les autorisations avec l’outil en ligne de commande
• Modifier les autorisations individuelles ou de groupe
• Bonnes pratiques de sécurité
• Outils de gestion de la sécurité et des autorisations
• Ajouter des utilisateurs à un rôle d’administrateur