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

  • Article

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

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.

Avant d’utiliser ce guide, nous vous recommandons de vous familiariser avec le contenu suivant :

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 :

  • Niveau de l’objet
  • Au niveau du projet
  • Niveau de collecte de projets ou d’organisation
  • 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 autorisation.
L’utilisateur a récemment reçu l’autorisation, mais son client a besoin d’une actualisation pour reconnaître 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 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é 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 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 d’accès et d’autorisation moins courants

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é 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.
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
  • De base + Test Plans
  • Abonnement Visual Studio

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é. 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 calendrier, les utilisateurs qui ne se sont pas connectés à 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 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é 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. 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.

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.

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

    Capture d’écran de la zone de filtre, entrez le nom d’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.

Capture d’écran de la sélection de 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.

  1. Sélectionnez Paramètres> du projetSécurité, puis entrez le nom d’utilisateur dans la zone de filtre.

    Capture d’écran de l’entrée du nom d’utilisateur dans la zone de filtre, Azure DevOps Server 2019.

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

  2. Suivez la raison pour laquelle un utilisateur ne dispose d’aucune des autorisations répertoriées. Pointez sur l’autorisation, puis choisissez Pourquoi.

    Capture d’écran de l’affichage Choisir dans la liste des autorisations pour les informations au niveau du projet, Azure DevOps Server 2019.

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.

Capture d’écran de Trace montrant les autorisations héritées, Azure DevOps Server 2019.

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.

Actualiser ou réévaluer les autorisations

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

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

Solution

Accédez aux autorisations des>paramètres>utilisateur pour réévaluer les autorisations. Cette fonction réévalue vos appartenances et autorisations de groupe, puis toutes les modifications récentes prennent effet immédiatement.

Capture d’écran du contrôle Réévaluer les autorisations.

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 :

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 empêcher les utilisateurs d’accéder aux paramètres de l’organisation, activez la visibilité et la collaboration des utilisateurs sur des projets spécifiques en préversion. 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é, tout utilisateur ou groupe ajouté au groupe Utilisateurs délimités par le projet est limité à l’accès aux pages des paramètres de l’organisation, à l’exception de La vue d’ensemble et des 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 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 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é > De base + Plans de > test De base > . 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).

Remarque

  • Les modifications apportées aux lecteurs de projet par le biais de règles de groupe ne sont pas conservées. Pour ajuster les lecteurs de projet, envisagez d’autres méthodes telles que l’affectation directe ou les groupes de sécurité personnalisés.
  • 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 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 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, malgré les ajouter 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. Procédez comme suit :

  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 : « Se déconnecter en cours ». Une fois que vous vous êtes déconnecté, vous êtes redirigé vers dev.azure.microsoft.com.

  4. Connectez-vous à Nouveau à Azure DevOps et choisissez une autre identité.

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