Använda tjänstens huvudnamn och hanterade identiteter

  • Artikel

Azure DevOps Services

Lägg till Microsoft Entra-tjänstens huvudnamn och hanterade identiteter i dina Azure DevOps-organisationer för att ge åtkomst till organisationens resurser. För många team kan den här funktionen vara ett genomförbart och föredraget alternativ till personliga åtkomsttoken (PAT) när du autentiserar program som driver automationsarbetsflöden i ditt företag.

Om tjänstens huvudnamn och hanterade identiteter

Tjänstens huvudnamn är säkerhetsobjekt i ett Microsoft Entra-program som definierar vad ett program kan göra i en viss klientorganisation. De konfigureras i Azure-portalen under programregistreringsprocessen och konfigureras för åtkomst till Azure-resurser, till exempel Azure DevOps. Genom att lägga till tjänstens huvudnamn i din organisation och konfigurera behörigheter ovanpå dem kan vi avgöra om tjänstens huvudnamn har behörighet att komma åt organisationens resurser och vilka.

Hanterade identiteter är en annan Microsoft Entra-funktion som fungerar på samma sätt som ett programs tjänsthuvudnamn. Dessa objekt tillhandahåller identiteter för Azure-resurser och gör det enkelt för tjänster som stöder Microsoft Entra-autentisering att dela autentiseringsuppgifter. De är ett tilltalande alternativ eftersom Microsoft Entra ID tar hand om hantering och rotation av autentiseringsuppgifter. Även om konfigurationen för en hanterad identitet kan se annorlunda ut på Azure-portalen behandlar Azure DevOps båda säkerhetsobjekten på samma sätt som en ny identitet i en organisation med definierade behörigheter. I resten av den här artikeln refererar vi till hanterade identiteter och tjänstens huvudnamn om inte anges.

Använd följande steg för att autentisera dessa identiteter till Azure DevOps så att de kan utföra åtgärder för sig själva.

Konfigurera hanterade identiteter och tjänstens huvudnamn

Implementeringen kan variera, men på hög nivå hjälper följande steg dig att börja använda tjänstens huvudnamn i arbetsflödet. Överväg att titta på en av våra exempelappar för att följa med i ett exempel på egen hand.

1. Skapa en ny hanterad identitet eller programtjänstens huvudnamn

Skapa ett huvudnamn för programtjänsten eller en hanterad identitet i Azure-portalen.

Skapa ett huvudnamn för programtjänsten

När du skapar en ny programregistrering skapas ett programobjekt i Microsoft Entra-ID. Programtjänstens huvudnamn är en representation av det här programobjektet för en viss klientorganisation. När du registrerar ett program som ett program med flera klienter finns det ett unikt objekt för tjänstens huvudnamn som representerar programobjektet för varje klientorganisation som programmet läggs till i.

Ytterligare information:

Skapa en hanterad identitet

Att skapa hanterade identiteter i Azure-portalen skiljer sig avsevärt från att konfigurera program med tjänstens huvudnamn. Innan du börjar skapa processen måste du först överväga vilken typ av hanterad identitet du vill skapa:

  • Systemtilldelad hanterad identitet: Med vissa Azure-tjänster kan du aktivera en hanterad identitet direkt på en tjänstinstans. När du aktiverar en systemtilldelad hanterad identitet skapas en identitet i Microsoft Entra-ID. Identiteten är kopplad till livscykeln för den tjänstinstansen. När resursen tas bort tar Azure automatiskt bort identiteten åt dig. Det är bara den Azure-resursen som kan använda den här identiteten för att begära tokens från Microsoft Entra ID.
  • Användartilldelad hanterad identitet Du kan också skapa en hanterad identitet som en fristående Azure-resurs genom att skapa en användartilldelad hanterad identitet och tilldela den till en eller flera instanser av en Azure-tjänst. För användartilldelade hanterade identiteter hanteras identiteten separat från de resurser som använder den.

Mer information finns i följande artiklar och video:

2. Lägga till och hantera tjänstens huvudnamn i en Azure DevOps-organisation

När du har konfigurerat tjänstens huvudnamn i administrationscentret för Microsoft Entra måste du göra samma sak i Azure DevOps genom att lägga till tjänstens huvudnamn i din organisation. Du kan lägga till dem via sidan Användare eller med API:er för ServicePrincipalEntitlements. Eftersom de inte kan logga in interaktivt måste ett användarkonto som kan lägga till användare i en organisation, ett projekt eller ett team lägga till dem. Sådana användare inkluderar projektsamlingsadministratörer (PCA) eller projektadministratörer och teamadministratörer när principen "Tillåt team- och projektadministratörer att bjuda in nya användare" är aktiverad.

Dricks

Om du vill lägga till ett huvudnamn för tjänsten i organisationen anger du programmets eller den hanterade identitetens visningsnamn. Om du väljer att lägga till ett huvudnamn för tjänsten programmatiskt via API:etServicePrincipalEntitlementsska du skicka in tjänstens huvudnamns objekt-ID och inte programmets objekt-ID.

Om du är en PCA kan du också bevilja tjänstens huvudnamn åtkomst till specifika projekt och tilldela en licens. Om du inte är en PCA måste du kontakta PCA för att uppdatera eventuella projektmedlemskap eller licensåtkomstnivåer.

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

Kommentar

Du kan bara lägga till en hanterad identitet eller tjänstens huvudnamn för den klientorganisation som din organisation är ansluten till. Information om hur du kommer åt en hanterad identitet i en annan klientorganisation finns i lösningen i Vanliga frågor och svar.

När tjänstens huvudnamn har lagts till i organisationen kan du behandla dem på samma sätt som standardanvändarkonton. Du kan tilldela behörigheter direkt på ett huvudnamn för tjänsten, lägga till den i säkerhetsgrupper och team, tilldela den till valfri åtkomstnivå och ta bort den från organisationen. Du kan också använda Service Principal Graph APIs för att utföra CRUD-åtgärder på tjänstens huvudnamn.

Hanteringen av tjänstens huvudnamn skiljer sig från användarkonton på följande viktiga sätt:

  • Tjänstens huvudnamn har inga e-postmeddelanden och kan därför inte bjudas in till en organisation via e-post.
  • Gruppregler för licensiering gäller för närvarande inte för tjänstens huvudnamn. Om du vill tilldela en åtkomstnivå till ett huvudnamn för tjänsten är det bäst att göra det direkt.
  • Tjänstens huvudnamn kan läggas till i Microsoft Entra-grupper (i Azure-portalen), men vi har en aktuell teknisk begränsning som hindrar oss från att kunna visa dem i en lista över Microsoft Entra-gruppmedlemmar. Den här begränsningen gäller inte för Azure DevOps-grupper. Med detta sagt ärver ett tjänsthuvudnamn fortfarande alla gruppbehörigheter som har angetts ovanpå en Microsoft Entra-grupp som de tillhör.
  • Alla användare i en Microsoft Entra-grupp ingår inte omedelbart i en Azure DevOps-organisation bara för att en administratör skapar en grupp och lägger till en Microsoft Entra-grupp i den. Vi har en process som kallas "materialisering" som sker när en användare från en Microsoft Entra-grupp loggar in på organisationen för första gången. Med en användare som loggar in i en organisation kan vi avgöra vilka användare som ska beviljas en licens. Eftersom inloggning inte är möjligt för tjänstens huvudnamn måste en administratör uttryckligen lägga till den i en organisation enligt beskrivningen tidigare.
  • Du kan inte ändra ett huvudnamn för tjänstens huvudnamn eller avatar i Azure DevOps.
  • Tjänstens huvudnamn räknas som en licens för varje organisation som läggs till, även om fakturering för flera organisationer har valts.

3. Få åtkomst till Azure DevOps-resurser med en Microsoft Entra-ID-token

Hämta en Microsoft Entra-ID-token

Du kan hämta en åtkomsttoken för en hanterad identitet genom att följa dokumentationen om Microsoft Entra-ID. Mer information finns i exemplen för tjänstens huvudnamn och hanterade identiteter.

Den returnerade åtkomsttoken är en JWT med de definierade rollerna, som kan användas för att komma åt organisationsresurser med hjälp av token som bearer.

Använd Microsoft Entra ID-token för att autentisera till Azure DevOps-resurser

I följande videoexempel går vi från att autentisera med en PAT till att använda en token från ett huvudnamn för tjänsten. Vi börjar med att använda en klienthemlighet för autentisering och sedan övergår vi till att använda ett klientcertifikat.

  • Tjänstens huvudnamn kan läggas till i Microsoft Entra-ID-grupper (i Azure-portalen), men vi har en aktuell teknisk begränsning som hindrar oss från att kunna visa dem i en lista över Medlemmar i Microsoft Entra-ID-gruppen. Den här begränsningen gäller inte för Azure DevOps-grupper. Med detta sagt ärver ett huvudnamn för tjänsten fortfarande alla gruppbehörigheter som har angetts ovanpå en Microsoft Entra-ID-grupp som de tillhör.
  • Alla användare i en Microsoft Entra-ID-grupp ingår inte omedelbart i en Azure DevOps-organisation bara för att en administratör skapar en grupp och lägger till en Microsoft Entra-ID-grupp i den. Vi har en process som kallas "materialisering" som sker när en användare från en Microsoft Entra-ID-grupp loggar in i organisationen för första gången. Med en användare som loggar in i en organisation kan vi avgöra vilka användare som ska beviljas en licens. Eftersom inloggning inte är möjligt för tjänstens huvudnamn måste en administratör uttryckligen lägga till den i en organisation enligt beskrivningen tidigare.
  • Du kan inte ändra ett huvudnamn för tjänstens huvudnamn eller avatar i Azure DevOps.
  • Tjänstens huvudnamn räknas som en licens för varje organisation som läggs till, även om fakturering för flera organisationer har valts.

Ett annat exempel visar hur du ansluter till Azure DevOps med hjälp av en användartilldelad hanterad identitet i en Azure-funktion.

Följ med i de här exemplen genom att hitta appkoden i vår samling med exempelappar.

Tjänstens huvudnamn kan användas för att anropa Azure DevOps REST-API:er och utföra de flesta åtgärder, men det är begränsat från följande åtgärder:

  • Tjänstens huvudnamn kan inte vara organisationsägare eller skapa organisationer.
  • Tjänstens huvudnamn kan inte skapa token, till exempel personliga åtkomsttoken (PAT) eller SSH-nycklar. De kan generera sina egna Microsoft Entra-ID-token och dessa token kan användas för att anropa Azure DevOps REST-API:er.
  • Vi stöder inte Azure DevOps OAuth för tjänstens huvudnamn.

Kommentar

Du kan bara använda program-ID och inte resurs-URI:er som är associerade med Azure DevOps för att generera token.

Vanliga frågor och svar

Allmänt

F: Varför ska jag använda tjänstens huvudnamn eller en hanterad identitet i stället för en PAT?

S: Många av våra kunder söker efter tjänstens huvudnamn eller hanterade identitet för att ersätta en befintlig PAT (personlig åtkomsttoken). Sådana PAT:er tillhör ofta ett tjänstkonto (delat teamkonto) som använder dem för att autentisera ett program med Azure DevOps-resurser. PAT måste vara arbetskrävande roteras varje så ofta (minst 180 dagar). Eftersom PAT:er helt enkelt är ägartoken, vilket innebär tokensträngar som representerar en användares användarnamn och lösenord, är de otroligt riskfyllda att använda eftersom de enkelt kan hamna i fel persons händer. Microsoft Entra-token upphör att gälla varje timme och måste återskapas med en uppdateringstoken för att få en ny åtkomsttoken, vilket begränsar den övergripande riskfaktorn när den läcker ut.

Du kan inte använda tjänstens huvudnamn för att skapa en personlig åtkomsttoken.

F: Vilka är hastighetsbegränsningarna för tjänstens huvudnamn och hanterade identiteter?

S: För närvarande har tjänstens huvudnamn och hanterade identiteter samma hastighetsgränser som användare.

F: Kostar det mer att använda den här funktionen?

S: Tjänstens huvudnamn och hanterade identiteter prissätts på samma sätt som användare, baserat på åtkomstnivå. En viktig ändring gäller hur vi behandlar "fakturering för flera organisationer" för tjänstens huvudnamn. Användare räknas bara som en licens, oavsett hur många organisationer de är i. Tjänstens huvudnamn räknas som en licens per organisation som användaren är i. Det här scenariot liknar standard "användartilldelningsbaserad fakturering".

F: Kan jag använda tjänstens huvudnamn eller hanterade identitet med Azure CLI?

S: Ja! Var som helst som frågar efter PAT:er i Azure CLI kan också acceptera Åtkomsttoken för Microsoft Entra-ID. Se de här exemplen för hur du kan skicka in en Microsoft Entra-token för att autentisera med 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

Nu ska vi hämta en Microsoft Entra-token (Azure DevOps-resursens UUID är 499b84ac-1321-427f-aa17-267ca6975798) och försöka anropa ett Azure DevOps-API genom att skicka den i rubrikerna som en Bearer token:

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

Nu kan du använda az cli kommandon per vanligt.

F: Kan jag lägga till en hanterad identitet från en annan klientorganisation i min organisation?

S: Du kan bara lägga till en hanterad identitet från samma klientorganisation som din organisation är ansluten till. Vi har dock en lösning som gör att du kan konfigurera en hanterad identitet i "resursklientorganisationen", där alla dina resurser finns. Sedan kan du aktivera det så att det används av ett huvudnamn för tjänsten i "målklientorganisationen", där din organisation är ansluten. Gör följande som en lösning:

  1. Skapa en användartilldelad hanterad identitet i Azure-portalen för resursklientorganisationen.
  2. Anslut den till en virtuell dator och tilldela den hanterade identiteten till den.
  3. Skapa ett nyckelvalv och generera ett certifikat (kan inte vara av typen "PEM"). När du genererar det här certifikatet genereras också en hemlighet med samma namn, som vi använder senare.
  4. Bevilja åtkomst till den hanterade identiteten så att den kan läsa den privata nyckeln från nyckelvalvet. Skapa en åtkomstprincip i nyckelvalvet med behörigheterna "Hämta/lista" (under "Hemliga behörigheter" och sök efter den hanterade identiteten under "Välj huvudnamn".
  5. Ladda ned det skapade certifikatet i CER-format, vilket säkerställer att det inte innehåller den privata delen av certifikatet.
  6. Skapa en ny programregistrering i målklientorganisationen.
  7. Ladda upp det nedladdade certifikatet till det nya programmet på fliken "Certifikat och hemligheter".
  8. Lägg till det här programmets tjänsthuvudnamn i den Azure DevOps-organisation som vi vill att det ska komma åt och kom ihåg att konfigurera tjänstens huvudnamn med nödvändiga behörigheter.
  9. Information om hur du hämtar en Microsoft Entra-åtkomsttoken från tjänstens huvudnamn som använder det hanterade identitetscertifikatet finns i följande kodexempel:

Kommentar

Du måste regelbundet rotera certifikat, som alltid.

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;
}

Artefakter

F: Kan jag använda tjänstens huvudnamn för att ansluta till feeds?

S: Ja, du kan ansluta till valfri Azure Artifacts-feed med tjänstens huvudnamn. I följande exempel visar vi hur du ansluter med en Microsoft Entra ID-token för NuGet, npm och Maven, men andra flödestyper bör också fungera.

NuGet-projektkonfiguration med Microsoft Entra-token

  1. Lägg till en nuget.config-fil i projektet i samma mapp som .csproj - eller .sln-filen .

    <?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. Hämta en Microsoft Entra-ID-token för tjänstens huvudnamn.

  3. Kör följande kommando för att autentisera med dina autentiseringsuppgifter och lägg sedan till din token med kommandot setapikey. Det här kommandot lägger till feedkällan i nuget.config:

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

nuget setapikey <YOUR_ACCESS_TOKEN> -source <SOURCE_URL>

npm-projektkonfiguration med Microsoft Entra-token

Kommentar

Verktyget vsts-npm-auth stöder inte Microsoft Entra-åtkomsttoken.

  1. Lägg till en .npmrc i projektet i samma katalog som din package.json.

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

  2. Hämta en åtkomsttoken för tjänstens huvudnamn eller hanterade identitet.

  3. Lägg till den här koden i din ${user.home}/.npmrc och ersätt platshållaren [AAD_SERVICE_PRINCIPAL_ACCESS_TOKEN] med åtkomsttoken från föregående steg.

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

Maven-projektkonfiguration med Microsoft Entra-token

  1. Lägg till lagringsplatsen i både dina pom.xmloch <repositories><distributionManagement> avsnitten.

    <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. Hämta en åtkomsttoken för tjänstens huvudnamn eller hanterade identitet.

  3. Lägg till eller redigera settings.xml filen i ${user.home}/.m2 och ersätt platshållaren [AAD_SERVICE_PRINCIPAL_ACCESS_TOKEN] med åtkomsttoken från föregående steg.

    <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>

Marknadsplats

F: Kan jag använda tjänstens huvudnamn för att publicera tillägg till Visual Studio Marketplace?

S: Ja. Följ dessa steg.

  1. Lägg till ett tjänsthuvudnamn som medlem i ett utgivarkonto. Du kan hämta tjänstens huvudnamns ID från profilen med hjälp av Profiler – Hämta. Sedan kan du lägga till tjänstens huvudnamn som medlem i utgivaren med hjälp av ID:t från föregående steg.

  2. Publicera ett tillägg via TFX CLI med hjälp av ett SP. Kör följande TFX CLI-kommando för att använda en SP-åtkomsttoken:

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

Pipelines

F: Kan jag använda en hanterad identitet i en tjänstanslutning? Hur kan jag enklare rotera hemligheter för tjänstens huvudnamn i min tjänstanslutning? Kan jag undvika att lagra hemligheter i en tjänstanslutning helt och hållet?

Azure stöder arbetsbelastningsidentitetsfederation med hjälp av OpenID-Anslut-protokollet, som gör att vi kan skapa hemliga tjänstanslutningar i Azure Pipelines som backas upp av tjänstens huvudnamn eller hanterade identiteter med federerade autentiseringsuppgifter i Microsoft Entra-ID. Som en del av körningen kan en pipeline utbyta sin egen interna token med en Microsoft Entra-token och därmed få åtkomst till Azure-resurser. När den har implementerats rekommenderas den här mekanismen i produkten jämfört med andra typer av Azure-tjänstanslutningar som finns idag. Den här mekanismen kan också användas för att konfigurera hemliga distributioner med andra OIDC-kompatibla tjänstleverantörer. Den här mekanismen är i förhandsversion.

Repos

F: Kan jag använda tjänstens huvudnamn för att utföra git-åtgärder, till exempel klona en lagringsplats?

S: Se följande exempel på hur vi skickade en Microsoft Entra-ID-token för ett tjänsthuvudnamn i stället för en PAT för att git klona en lagringsplats i ett PowerShell-skript.

$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}

Dricks

Om du vill skydda din token använder du autentiseringsansvariga så att du inte behöver ange dina autentiseringsuppgifter varje gång. Vi rekommenderar Git Credential Manager, som kan acceptera Microsoft Entra-token (dvs. Microsoft Identity OAuth-token) i stället för PAT om en miljövariabel ändras.

Ett användbart tips om hur du hämtar åtkomsttoken från Azure CLI för att anropa git fetch:

  1. Öppna Git-konfigurationen för lagringsplatsen:
git config -e
  1. Lägg till följande rader, där Azure DevOps-resursens UUID är 499b84ac-1321-427f-aa17-267ca6975798:
[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. Testa att det fungerar med:
GIT_TRACE=1 GCM_TRACE=1 GIT_CURL_VERBOSE=1 git fetch

Potentiella fel

Det gick inte att skapa tjänstens huvudnamn med objekt-ID {provided objectId}

Det finns inget huvudnamn för tjänsten med provided objectId i klientorganisationen som är ansluten till din organisation. En vanlig orsak är att du skickar in objekt-ID:t för appregistreringen i stället för objekt-ID:t för tjänstens huvudnamn. Kom ihåg att ett huvudnamn för tjänsten är ett objekt som representerar programmet för en viss klientorganisation, det är inte själva programmet. Finns service principal object ID på klientorganisationens sida "Företagsprogram". Sök efter programmets namn och välj det "Företagsprogram"-resultat som returneras. Det här resultatet är sidan för tjänstens huvudnamn/företagsprogram och du kan använda objekt-ID:t som finns på den här sidan för att skapa ett huvudnamn för tjänsten i Azure DevOps.

Åtkomst nekad: {ID of the caller identity} behöver följande behörigheter för resursen Användare för att utföra den här åtgärden: Lägg till användare

Det här felet kan bero på någon av följande orsaker:

  • Du är inte ägare till organisationen, projektsamlingsadministratören eller projekt- eller teamadministratören.
  • Du är projekt- eller teamadministratör, men principen "Tillåt team- och projektadministratörer att bjuda in nya användare" är inaktiverad.
  • Du är ett projekt eller en gruppadministratör som kan bjuda in nya användare, men du försöker tilldela en licens när du bjuder in en ny användare. Projekt- eller teamadministratörer får inte tilldela en licens till nya användare. Alla nya inbjudna användare läggs till på standardåtkomstnivån för nya användare. Kontakta ett PCA för att ändra licensåtkomstnivån.

Azure DevOps Graph List API returnerar en tom lista, även om vi vet att det finns tjänstens huvudnamn i organisationen

Api:et för Azure DevOps Graph List kan returnera en tom lista, även om det fortfarande finns fler sidor med användare att returnera. continuationToken Använd för att iterera genom listorna och du kan så småningom hitta en sida där tjänstens huvudnamn returneras. Om en continuationToken returneras innebär det att det finns fler tillgängliga resultat via API:et. Vi har planer på att förbättra den här logiken, men just nu är det möjligt att de första X-resultaten returnerar tomma.

TF401444: Logga in minst en gång som {tenantId'tenantId\servicePrincipalObjectId'} i en webbläsare för att aktivera åtkomst till tjänsten.

Om tjänstens huvudnamn inte har bjudits in till organisationen kan du stöta på följande fel. Kontrollera att tjänstens huvudnamn har lagts till i rätt organisation och har alla behörigheter som krävs för att få åtkomst till nödvändiga resurser.