Utiliser des principaux de service et des identités managées

  • Article

Azure DevOps Services

Ajoutez des principaux de service Microsoft Entra et des identités managées à vos organisations Azure DevOps pour accorder l’accès aux ressources de votre organisation. Pour de nombreuses équipes, cette fonctionnalité peut être une alternative viable et préférée aux jetons d’accès personnels (PAT) lorsque vous authentifiez des applications qui alimentent les flux de travail d’automatisation dans votre entreprise.

À propos des principaux de service et des identités managées

Les principaux de service sont des objets de sécurité au sein d’une application Microsoft Entra qui définissent ce qu’une application peut faire dans un locataire donné. Ils sont configurés dans le Portail Azure pendant le processus d’inscription de l’application et configurés pour accéder aux ressources Azure, telles qu’Azure DevOps. En ajoutant des principaux de service à votre organization et en configurant des autorisations par-dessus eux, nous pouvons déterminer si un principal de service est autorisé à accéder aux ressources de votre organisation et lesquels.

Les identités managées sont une autre fonctionnalité Microsoft Entra qui agit de la même façon que les principaux de service d’une application. Ces objets fournissent des identités pour les ressources Azure et permettent aux services qui prennent en charge l’authentification Microsoft Entra de partager des informations d’identification. Il s’agit d’une option attrayante, car Microsoft Entra ID s’occupe de la gestion et de la rotation des informations d’identification. Bien que la configuration d’une identité managée semble différente sur le Portail Azure, Azure DevOps traite les deux objets de sécurité identiques à une nouvelle identité dans une organisation avec des autorisations définies. Dans le reste de cet article, nous faisons référence indifféremment aux identités managées et aux principaux de service en tant que principal de service, sauf indication contraire.

Utilisez les étapes suivantes pour authentifier ces identités auprès d’Azure DevOps afin de leur permettre d’effectuer des actions en leur nom.

Configurer des identités managées et des principaux de service

Votre implémentation peut varier, mais à un niveau élevé, les étapes suivantes vous aident à commencer à utiliser des principaux de service dans votre flux de travail. Envisagez d’examiner l’un de nos exemples d’applications à suivre avec un exemple par vous-même.

1. Créer une identité managée ou un principal de service d’application

Créez un principal de service d’application ou une identité managée dans le Portail Azure.

Créer un principal de service d’application

Lorsque vous créez une inscription d’application, un objet d’application est créé dans l’ID Microsoft Entra. Le principal du service d’application est une représentation de cet objet d’application pour un locataire donné. Lorsque vous inscrivez une application en tant qu’application mutualisée, il existe un objet de principal de service unique qui représente l’objet d’application pour chaque locataire auquel l’application est ajoutée.

Informations supplémentaires :

Créer une identité managée

La création d’identités managées dans le Portail Azure diffère considérablement de la configuration d’applications avec des principaux de service. Avant de commencer le processus de création, vous devez d’abord déterminer le type d’identité managée que vous souhaitez créer :

  • Identité managée affectée par le système : Certains services Azure vous permettent d’activer une identité managée directement sur un instance de service. Lorsque vous activez une identité managée affectée par le système, une identité est créée dans Microsoft Entra ID. L’identité est liée au cycle de vie de cette instance de service. Lorsque la ressource est supprimée, Azure supprime automatiquement l’identité. Par défaut, seule cette ressource Azure peut utiliser cette identité pour demander des jetons à Microsoft Entra ID.
  • Une identité managée affectée par l’utilisateur peut également créer une identité managée en tant que ressource Azure autonome en créant une identité managée affectée par l’utilisateur et en l’affectant à une ou plusieurs instances d’un service Azure. Une identité managée affectée par l’utilisateur est gérée séparément des ressources qui l’utilisent.

Pour plus d’informations, consultez les articles et la vidéo suivants :

2. Ajouter et gérer des principaux de service dans un organization Azure DevOps

Une fois que vous avez configuré les principaux de service dans le Centre d’administration Microsoft Entra, vous devez faire de même dans Azure DevOps en ajoutant les principaux de service à votre organisation. Vous pouvez les ajouter via la page Utilisateurs ou avec les API ServicePrincipalEntitlements. Comme ils ne peuvent pas se connecter de manière interactive, un compte d’utilisateur qui peut ajouter des utilisateurs à un organization, un projet ou une équipe doit les ajouter. Ces utilisateurs incluent les administrateurs de collection de projets (PCA) ou les administrateurs de projets et les administrateurs d’équipe lorsque la stratégie « Autoriser les administrateurs d’équipe et de projet à inviter de nouveaux utilisateurs » est activée.

Conseil

Pour ajouter un principal de service au organization, entrez le nom d’affichage de l’application ou de l’identité managée. Si vous choisissez d’ajouter un principal de service par programmation via l’APIServicePrincipalEntitlements, veillez à transmettre l’ID d’objet du principal de service et non l’ID d’objet de l’application.

Si vous êtes un PCA, vous pouvez également accorder à un principal de service l’accès à des projets spécifiques et attribuer une licence. Si vous n’êtes pas un CPA, vous devez contacter l’ACP pour mettre à jour les appartenances au projet ou les niveaux d’accès aux licences.

Screenshot of service principals and managed identities in the Users Hub.

Remarque

Vous ne pouvez ajouter qu’une identité managée ou un principal de service pour le locataire auquel votre organisation est connectée. Pour accéder à une identité managée dans un autre locataire, consultez la solution de contournement dans le FAQ.

Une fois vos principaux de service ajoutés au organization, vous pouvez les traiter de la même manière que les comptes d’utilisateur standard. Vous pouvez attribuer des autorisations directement sur un principal de service, l’ajouter à des groupes de sécurité et des équipes, l’affecter à n’importe quel niveau d’accès et le supprimer du organization. Vous pouvez également utiliser pour effectuer des Service Principal Graph APIs opérations CRUD sur les principaux de service.

La gestion des principaux de service diffère des comptes d’utilisateur des manières clés suivantes :

  • Les principaux de service n’ont pas d’e-mails et, par conséquent, ils ne peuvent pas être invités à un organization par e-mail.
  • Les règles de groupe pour les licences ne s’appliquent actuellement pas aux principaux de service. Si vous souhaitez affecter un niveau d’accès à un principal de service, il est préférable de le faire directement.
  • Bien que les principaux de service puissent être ajoutés aux groupes Microsoft Entra (dans le Portail Azure), nous avons une limitation technique actuelle qui nous empêche de pouvoir les afficher dans une liste de membres du groupe Microsoft Entra. Cette limitation n’est pas vraie pour les groupes Azure DevOps. Cela dit, un principal de service hérite toujours des autorisations de groupe définies sur un groupe Microsoft Entra auquel ils appartiennent.
  • Tous les utilisateurs d’un groupe Microsoft Entra ne font pas partie immédiatement d’une organisation Azure DevOps, car un administrateur crée un groupe et y ajoute un groupe Microsoft Entra. Nous avons un processus appelé « matérialisation » qui se produit une fois qu’un utilisateur d’un groupe Microsoft Entra se connecte à l’organisation pour la première fois. Un utilisateur qui se connecte à un organization nous permet de déterminer quels utilisateurs doivent recevoir une licence. Étant donné que la connexion n’est pas possible pour les principaux de service, un administrateur doit l’ajouter explicitement à un organization comme décrit précédemment.
  • Vous ne pouvez pas modifier le nom d’affichage ou l’avatar d’un principal de service sur Azure DevOps.
  • Un principal de service compte comme licence pour chaque organisation à laquelle il est ajouté, même si la facturation multi-organisation est sélectionnée.

3. Accéder aux ressources Azure DevOps avec un jeton d’ID Microsoft Entra

Obtenir un jeton d’ID Microsoft Entra

L’acquisition d’un jeton d’accès pour une identité managée peut être effectuée en suivant la documentation microsoft Entra ID. Pour plus d’informations, consultez les exemples de principaux de service et d’identités managées.

Le jeton d’accès retourné est un JWT avec les rôles définis, qui peut être utilisé pour accéder à organization ressources en utilisant le jeton en tant que porteur.

Utiliser le jeton d’ID Microsoft Entra pour s’authentifier auprès des ressources Azure DevOps

Dans l’exemple vidéo suivant, nous passons de l’authentification avec un PAT à l’utilisation d’un jeton d’un principal de service. Nous commençons par utiliser une clé secrète client pour l’authentification, puis nous passons à l’aide d’un certificat client.

  • Bien que les principaux de service puissent être ajoutés aux groupes d’ID Microsoft Entra (dans le Portail Azure), nous avons une limitation technique actuelle qui nous empêche d’être en mesure de les afficher dans une liste de membres du groupe Microsoft Entra ID. Cette limitation n’est pas vraie pour les groupes Azure DevOps. Cela dit, un principal de service hérite toujours des autorisations de groupe définies sur un groupe d’ID Microsoft Entra qu’ils appartiennent.
  • Tous les utilisateurs d’un groupe d’ID Microsoft Entra ne font pas partie immédiatement d’une organisation Azure DevOps, car un administrateur crée un groupe et y ajoute un groupe d’ID Microsoft Entra. Nous avons un processus appelé « matérialisation » qui se produit une fois qu’un utilisateur d’un groupe Microsoft Entra ID se connecte à l’organisation pour la première fois. Un utilisateur qui se connecte à un organization nous permet de déterminer quels utilisateurs doivent recevoir une licence. Étant donné que la connexion n’est pas possible pour les principaux de service, un administrateur doit l’ajouter explicitement à un organization comme décrit précédemment.
  • Vous ne pouvez pas modifier le nom d’affichage ou l’avatar d’un principal de service sur Azure DevOps.
  • Un principal de service compte comme licence pour chaque organisation à laquelle il est ajouté, même si la facturation multi-organisation est sélectionnée.

Un autre exemple montre comment se connecter à Azure DevOps à l’aide d’une identité managée affectée par l’utilisateur au sein d’une fonction Azure.

Suivez ces exemples en recherchant le code d’application dans notre collection d’exemples d’applications.

Les principaux de service peuvent être utilisés pour appeler les API REST Azure DevOps et effectuer la plupart des actions, mais ils sont limités par les opérations suivantes :

  • Les principaux de service ne peuvent pas être propriétaire d'organisation ou créer des organisations.
  • Les principaux de service ne peuvent pas créer de jetons, tels que des jetons d’accès personnels (PAT) ou desclés SSH. Ils peuvent générer leurs propres jetons d’ID Microsoft Entra et ces jetons peuvent être utilisés pour appeler des API REST Azure DevOps.
  • Nous ne prenons pas en charge OAuth Azure DevOps pour les principaux de service.

Remarque

Vous pouvez uniquement utiliser l’ID d’application et non les URI de ressource associés à Azure DevOps pour générer des jetons.

FAQ

Général

Q : Pourquoi utiliser un principal de service ou une identité managée au lieu d’un PAT ?

R : La plupart de nos clients recherchent un principal de service ou une identité managée pour remplacer un jeton d’accès personnel (PAT) existant. Ces PAT appartiennent souvent à un compte de service (compte d’équipe partagé) qui les utilise pour authentifier une application avec des ressources Azure DevOps. Les PAT doivent faire l’objet d’une rotation laborieuse de temps en temps (minimum 180 jours). Comme les PAT sont simplement des jetons de porteur, c’est-à-dire des chaînes de jeton qui représentent le nom d’utilisateur et le mot de passe d’un utilisateur, ils sont incroyablement risqués à utiliser, car ils peuvent facilement tomber entre les mains de la mauvaise personne. Les jetons Microsoft Entra expirent toutes les heures et doivent être régénérés avec un jeton d’actualisation pour obtenir un nouveau jeton d’accès, ce qui limite le facteur de risque global lors de la fuite.

Vous ne pouvez pas utiliser un principal de service pour créer un jeton d’accès personnel.

Q : Quelles sont les limites de débit sur les principaux de service et les identités managées ?

R : À l’heure actuelle, les principaux de service et les identités managées ont les mêmes limites de débit que les utilisateurs.

Q : L’utilisation de cette fonctionnalité coûtera-t-elle plus cher ?

R : Les principaux de service et les identités managées sont facturés de la même façon que les utilisateurs, en fonction du niveau d’accès. Un changement notable concerne la façon dont nous traitons la « facturation multi-organisation » pour les principaux de service. Les utilisateurs sont comptés comme une seule licence, quel que soit le nombre d’organisations dans lesquelles ils sont. Les principaux de service sont comptés comme une licence par organization l’utilisateur. Ce scénario est similaire à la « facturation basée sur l’affectation d’utilisateur » standard.

Q : Puis-je utiliser un principal de service ou une identité managée avec Azure CLI ?

A : Oui. Partout où les demandes de paT dans Azure CLI peuvent également accepter des jetons d’accès Microsoft Entra ID. Consultez ces exemples pour savoir comment transmettre un jeton Microsoft Entra pour vous authentifier auprès de l’interface CLI.

# To authenticate with a command: After typing this command, the az devops login will prompt you to enter a token. You can add an Entra ID token too! Not just a PAT.
az devops login

# To authenticate a service principal with a password or cert:
az login --service-principal -u <app-id> -p <password-or-cert> --tenant <tenant>

# To authenticate a managed identity:
az login --identity

À présent, nous allons obtenir un jeton Microsoft Entra (l’UUID de la ressource Azure DevOps) 499b84ac-1321-427f-aa17-267ca6975798et essayons d’appeler une API Azure DevOps en le transmettant dans les en-têtes en tant que Bearer jeton :

Write-Host "Obtain access token for Service Connection identity..."
$accessToken = az account get-access-token --resource 499b84ac-1321-427f-aa17-267ca6975798 --query "accessToken" --output tsv

Write-Host "Use access token with Azure DevOps REST API to list projects in the organization..."
$apiVersion = "7.1-preview.1"
$uri = "https://dev.azure.com/${yourOrgname}/_apis/projects?api-version=${apiVersion}"
$headers = @{
    Accept = "application/json"
    Authorization = "Bearer $accessToken"
}
Invoke-RestMethod -Uri $uri -Headers $headers -Method Get | Select-Object -ExpandProperty value ` | Select-Object id, name

Maintenant, vous pouvez utiliser az cli des commandes par habitude.

Q : Puis-je ajouter une identité managée à partir d’un autre locataire à mon organization ?

R : Vous pouvez uniquement ajouter une identité managée à partir du même locataire auquel votre organization est connecté. Toutefois, nous avons une solution de contournement qui vous permet de configurer une identité managée dans le « locataire de ressources », où sont toutes vos ressources. Ensuite, vous pouvez l’activer pour être utilisé par un principal de service dans le « locataire cible », où votre organisation est connectée. Effectuez les étapes suivantes comme solution de contournement :

  1. Créez une identité managée affectée par l’utilisateur dans Portail Azure pour votre locataire de ressource.
  2. Connectez-le à une machine virtuelle et attribuez-lui cette identité managée .
  3. Créez un coffre de clés et générez un certificat (ne peut pas être de type « PEM »). Lorsque vous générez ce certificat, un secret portant le même nom est également généré, que nous utiliserons ultérieurement.
  4. Accordez l’accès à l’identité managée afin qu’elle puisse lire la clé privée à partir du coffre de clés. Créez une stratégie d’accès dans le coffre de clés avec les autorisations « Obtenir/Répertorier » (sous « Autorisations secrètes » et recherchez l’identité managée sous « Sélectionner le principal ».
  5. Téléchargez le certificat créé au format « CER », ce qui garantit qu’il ne contient pas la partie privée de votre certificat.
  6. Créez une inscription d’application dans le locataire cible.
  7. Chargez le certificat téléchargé dans cette nouvelle application sous l’onglet « Certificats & secrets ».
  8. Ajoutez le principal de service de cette application au organization Azure DevOps auquel nous voulons qu’il accède, et n’oubliez pas de configurer le principal de service avec les autorisations requises.
  9. Pour obtenir un jeton d’accès Microsoft Entra à partir de ce principal de service qui utilise le certificat d’identité managée, consultez l’exemple de code suivant :

Remarque

Vous devez effectuer régulièrement une rotation des certificats, comme toujours.

public static async Task<string> GetSecret(string keyVaultName, string secretName)
{
	var keyVaultUri = new Uri("https://" + keyVaultName + ".vault.azure.net");
	var client = new SecretClient(keyVaultUri, new ManagedIdentityCredential());
	var keyVaultSecret = await client.GetSecretAsync(secretName);

	var secret = keyVaultSecret.Value;
	return secret.Value;
}

private static async Task<AuthenticationResult> GetAppRegistrationAADAccessToken(string applicationClientID, string appTenantId)
{
	IConfidentialClientApplication app;

	byte[] privateKeyBytes = Convert.FromBase64String(GetSecret(keyVaultName, secretName));
	X509Certificate2 certificateWithPrivateKey = new X509Certificate2(privateKeyBytes, (string)null, X509KeyStorageFlags.MachineKeySet);

	app = ConfidentialClientApplicationBuilder.Create(applicationClientID)
		.WithCertificate(certificateWithPrivateKey)
		.WithAuthority(new Uri(string.Format(CultureInfo.InvariantCulture, "https://login.microsoftonline.com/{0}", appTenantId)))
		.Build();
	app.AddInMemoryTokenCache();

	string AdoAppClientID = "499b84ac-1321-427f-aa17-267ca6975798/.default";
	string[] scopes = new string[] { AdoAppClientID };

	var result = await app.AcquireTokenForClient(scopes).ExecuteAsync();

	return result;
}

Artifacts

Q : Puis-je utiliser un principal de service pour me connecter aux flux ?

R : Oui, vous pouvez vous connecter à n’importe quel flux Azure Artifacts avec un principal de service. Dans les exemples suivants, nous montrons comment nous connecter avec un jeton d’ID Microsoft Entra pour NuGet, npm et Maven, mais d’autres types de flux doivent également fonctionner.

Configuration du projet NuGet avec le jeton Microsoft Entra

  1. Ajoutez un fichier nuget.config à votre projet, dans le même dossier que le fichier .csproj ou .sln .

    <?xml version="1.0" encoding="utf-8"?>
<configuration>
  <packageSources>
    <clear />
    <add key="FeedName" value="https://pkgs.dev.azure.com/<ORGANIZATION_NAME>/<PROJECT_NAME>/_packaging/<FEED_NAME>/nuget/v3/index.json" />
  </packageSources>
</configuration>

  2. Obtenez un jeton d’ID Microsoft Entra pour votre principal de service.

  3. Exécutez la commande suivante pour vous authentifier avec vos informations d’identification, puis ajoutez votre jeton à l’aide de la commande setapikey. Cette commande ajoute votre source de flux à votre fichier nuget.config :

    nuget sources add -name <FEED_NAME> -source <SOURCE_URL> -username <USERNAME> -password <PASSWORD>

nuget setapikey <YOUR_ACCESS_TOKEN> -source <SOURCE_URL>

Configuration du projet npm avec des jetons Microsoft Entra

Remarque

L’outil vsts-npm-auth ne prend pas en charge les jetons d’accès Microsoft Entra.

  1. Ajoutez un .npmrc à votre projet, dans le même répertoire que votre package.json.

    registry=https://pkgs.dev.azure.com/Fabrikam/_packaging/FabrikamFeed/npm/registry/ 
always-auth=true

  2. Obtenez un jeton d’accès pour votre principal de service ou votre identité managée.

  3. Ajoutez ce code à votre ${user.home}/.npmrc et remplacez l’espace réservé [AAD_SERVICE_PRINCIPAL_ACCESS_TOKEN] par le jeton d’accès de l’étape précédente.

    //pkgs.dev.azure.com/Fabrikam/_packaging/FabrikamFeed/npm/:_authToken=[AAD_SERVICE_PRINCIPAL_ACCESS_TOKEN]

Configuration du projet Maven avec des jetons Microsoft Entras

  1. Ajoutez le dépôt à vos pom.xml<repositories> sections et <distributionManagement> .

    <repository>
  <id>Fabrikam</id>
  <url>https://pkgs.dev.azure.com/Fabrikam/_packaging/FabrikamFeed/maven/v1</url>
  <releases>
    <enabled>true</enabled>
  </releases>
  <snapshots>
    <enabled>true</enabled>
  </snapshots>
</repository>

  2. Obtenez un jeton d’accès pour votre principal de service ou votre identité managée.

  3. Ajoutez ou modifiez le settings.xml fichier dans ${user.home}/.m2 et remplacez l’espace réservé [AAD_SERVICE_PRINCIPAL_ACCESS_TOKEN] par le jeton d’accès de l’étape précédente.

    <settings xmlns="http://maven.apache.org/SETTINGS/1.0.0"
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
                              https://maven.apache.org/xsd/settings-1.0.0.xsd">
  <servers>
    <server>
      <id>Fabrikam</id>
      <username>Fabrikam</username>
      <password>[AAD_SERVICE_PRINCIPAL_ACCESS_TOKEN]</password>
    </server>
  </servers>
</settings>

Place de marché

Q : Puis-je utiliser un principal de service pour publier des extensions sur visual Studio Marketplace ?

A : Oui. Procédez comme suit.

  1. Ajoutez un principal de service en tant que membre à un compte d’éditeur. Vous pouvez obtenir l’ID du principal de service à partir de son profil à l’aide de Profils - Obtenir. Ensuite, vous pouvez ajouter le principal de service en tant que membre au serveur de publication à l’aide de l’ID de l’étape précédente.

  2. Publiez une extension via l’interface CLI TFX à l’aide d’un fournisseur de services. Exécutez la commande CLI TFX suivante pour utiliser un jeton d’accès fournisseur de services :

tfx extension publish --publisher my-publisher --vsix my-publisher.my-extension-1.0.0.vsix --auth-type pat -t <AAD_ACCESS_TOKEN>

Pipelines

Q : Puis-je utiliser une identité managée au sein d’une connexion de service ? Comment faire pivoter plus facilement les secrets du principal de service dans ma connexion de service ? Puis-je éviter de stocker des secrets dans une connexion de service complètement ?

support Azure s fédération des identités de charge de travail à l’aide du protocole OpenID Connecter, ce qui nous permet de créer des connexions de service sans secret dans Azure Pipelines soutenues par des principaux de service ou des identités managées avec des informations d’identification fédérées dans Microsoft Entra ID. Dans le cadre de son exécution, un pipeline peut échanger son propre jeton interne avec un jeton Microsoft Entra, ce qui permet d’accéder aux ressources Azure. Une fois implémenté, ce mécanisme est recommandé dans le produit sur d’autres types de connexions de service Azure qui existent aujourd’hui. Ce mécanisme peut également être utilisé pour configurer des déploiements sans secret avec n’importe quel autre fournisseur de services conforme OIDC. Ce mécanisme est en préversion.

Référentiels

Q : Puis-je utiliser un principal de service pour effectuer des opérations Git, comme cloner un dépôt ?

R : Consultez l’exemple suivant de la façon dont nous avons passé un jeton d’ID Microsoft Entra d’un principal de service au lieu d’un PAT pour cloner un référentiel dans un script PowerShell.

$ServicePrincipalAadAccessToken = 'Entra ID access token of a service principal'
git -c http.extraheader="AUTHORIZATION: bearer $ServicePrincipalAadAccessToken" clone https://dev.azure.com/{yourOrgName}/{yourProjectName}/_git/{yourRepoName}

Conseil

Pour sécuriser votre jeton, utilisez des gestionnaires d’informations d’identification afin de ne pas avoir à entrer vos informations d’identification à chaque fois. Nous vous recommandons git Credential Manager, qui peut accepter des jetons Microsoft Entra (autrement dit, des jetons OAuth d’identité Microsoft) au lieu de paTs si une variable d’environnement est modifiée.

Un conseil utile sur la façon d’obtenir le jeton d’accès à partir d’Azure CLI pour appeler git fetch :

  1. Ouvrez la configuration Git de votre dépôt :
git config -e
  1. Ajoutez les lignes suivantes, où se trouve 499b84ac-1321-427f-aa17-267ca6975798l’UUID de la ressource Azure DevOps :
[credential]
    helper = "!f() { test \"$1\" = get && echo \"password=$(az account get-access-token --resource 499b84ac-1321-427f-aa17-267ca6975798 --query accessToken -o tsv)\"; }; f"
  1. Vérifiez qu’il fonctionne à l’aide de :
GIT_TRACE=1 GCM_TRACE=1 GIT_CURL_VERBOSE=1 git fetch

Erreurs potentielles

Échec de la création du principal de service avec l’ID d’objet « {provided objectId} »

Il n’existe aucun principal de service avec le provided objectId dans le locataire connecté à votre organization. Une raison courante est que vous transmettez l’ID d’objet de l’inscription de l’application, au lieu de l’ID d’objet de son principal de service. N’oubliez pas qu’un principal de service est un objet qui représente l’application pour un locataire donné, ce n’est pas l’application elle-même. Le service principal object ID se trouve dans la page « Applications d’entreprise » de votre locataire. Recherchez le nom de l’application et sélectionnez le résultat « Application d’entreprise » qui retourne. Ce résultat correspond à la page du principal de service/application d’entreprise et vous pouvez utiliser l’ID d’objet trouvé sur cette page pour créer un principal de service dans Azure DevOps.

Accès refusé : {ID of the caller identity} a besoin des autorisations suivantes sur la ressource Utilisateurs pour effectuer cette action : Ajouter des utilisateurs

Cette erreur peut être due à l’une des raisons suivantes :

L’API Liste Graph Azure DevOps retourne une liste vide, même si nous savons qu’il existe des principaux de service dans le organization

L’API Liste Graph Azure DevOps peut renvoyer une liste vide, même s’il existe encore plus de pages d’utilisateurs à retourner. Utilisez le continuationToken pour itérer dans les listes et vous pouvez éventuellement trouver une page dans laquelle les principaux de service sont retournés. Si un continuationToken est retourné, cela signifie qu’il y a plus de résultats disponibles via l’API. Bien que nous ayons des plans pour améliorer cette logique, à ce stade, il est possible que les premiers résultats X retournent vides.

TF401444 : connectez-vous au moins une fois en tant que {tenantId'tenantId\servicePrincipalObjectId'} dans un navigateur web pour activer l’accès au service.

Si le principal de service n’a pas été invité à l’organisation, vous pouvez rencontrer l’erreur suivante. Vérifiez que le principal de service est ajouté à l’organisation appropriée et dispose de toutes les autorisations nécessaires pour accéder aux ressources requises.