Použití instančních objektů a spravovaných identit

Služby Azure DevOps

Přidáním instančních objektů a spravovaných identit Microsoft Entra do organizací Azure DevOps udělte přístup k prostředkům vaší organizace. U mnoha týmů může být tato funkce proveditelnou a upřednostňovanou alternativou k tokenům PAT při ověřování aplikací, které ve vaší společnosti používají pracovní postupy automatizace výkonu.

O instančních objektech a spravovaných identitách

Instanční objekty jsou objekty zabezpečení v aplikaci Microsoft Entra, které definují, co může aplikace v daném tenantovi dělat. Nastaví se na webu Azure Portal během procesu registrace aplikace a nakonfiguruje se pro přístup k prostředkům Azure, jako je Azure DevOps. Přidáním instančních objektů do vaší organizace a nastavením oprávnění nad nimi můžeme zjistit, jestli má instanční objekt oprávnění pro přístup k prostředkům organizace a k jakým prostředkům organizace má oprávnění.

Spravované identity jsou další funkcí Microsoft Entra, která funguje podobně jako instanční objekty aplikace. Tyto objekty poskytují identity pro prostředky Azure a umožňují snadný způsob, jak služby podporující ověřování Microsoft Entra sdílet přihlašovací údaje. Jedná se o atraktivní možnost, protože id Microsoft Entra se stará o správu a obměnu přihlašovacích údajů. I když nastavení spravované identity může vypadat jinak na webu Azure Portal, Azure DevOps považuje oba objekty zabezpečení za stejné jako novou identitu v organizaci s definovanými oprávněními. Ve zbytku tohoto článku odkazujeme na spravované identity a instanční objekty zaměnitelně jako instanční objekt, pokud není uvedeno.

Pomocí následujících kroků ověřte tyto identity v Azure DevOps, abyste jim umožnili provádět akce jménem sebe sama.

Konfigurace spravovaných identit a instančních objektů

Vaše implementace se může lišit, ale na vysoké úrovni vám následující kroky pomůžou začít používat instanční objekty ve vašem pracovním postupu. Zvažte, jestli se chcete podívat na jednu z našich ukázkových aplikací , abyste mohli postupovat podle vlastního příkladu.

1. Vytvoření nové spravované identity nebo instančního objektu aplikace

Na webu Azure Portal vytvořte instanční objekt aplikace nebo spravovanou identitu .

Vytvoření instančního objektu aplikace

Při vytváření nové registrace aplikace se vytvoří objekt aplikace v Microsoft Entra ID. Instanční objekt aplikace představuje tento objekt aplikace pro daného tenanta. Když zaregistrujete aplikaci jako víceklientskou aplikaci, existuje jedinečný objekt instančního objektu, který představuje objekt aplikace pro každého tenanta, do kterého se aplikace přidá.

Další informace:

• Přehled objektů aplikace a instančního objektu v Microsoft Entra ID
• Zabezpečení instančních objektů
• Použití portálu k vytvoření aplikace Microsoft Entra a instančního objektu, který má přístup k prostředkům

Vytvoření spravované identity

Vytváření spravovaných identit na webu Azure Portal se výrazně liší od nastavení aplikací s instančními objekty. Než začnete s procesem vytváření, musíte nejprve zvážit, jaký typ spravované identity chcete vytvořit:

• Spravovaná identita přiřazená systémem: Některé služby Azure umožňují povolit spravovanou identitu přímo v instanci služby. Když povolíte spravovanou identitu přiřazenou systémem, vytvoří se identita v Microsoft Entra ID. Identita je svázaná s životním cyklem této instance služby. Když se prostředek odstraní, Azure automaticky odstraní identitu za vás. Z podstaty této identity vyplývá, že ji může k vyžadování tokenů z Microsoft Entra ID používat pouze daný prostředek Azure.
• Spravovanou identitu přiřazenou uživatelem můžete také vytvořit jako samostatný prostředek Azure tak, že vytvoříte spravovanou identitu přiřazenou uživatelem a přiřadíte ji k jedné nebo více instancím služby Azure. Pro spravované identity přiřazené uživatelem se identita spravuje odděleně od prostředků, které ji používají.

Další informace najdete v následujících článcích a videu:

• Co jsou spravované identity pro prostředky Azure?
• Správa spravovaných identit přiřazených uživatelem
• Konfigurace spravovaných identit pro prostředky Azure na virtuálním počítači pomocí webu Azure Portal

2. Přidání a správa instančních objektů v organizaci Azure DevOps

Jakmile nakonfigurujete instanční objekty v Centru pro správu Microsoft Entra, musíte to udělat v Azure DevOps přidáním instančních objektů do vaší organizace. Můžete je přidat prostřednictvím stránky Uživatelé nebo pomocí rozhraní API ServicePrincipalEntitlements. Vzhledem k tomu, že se nemůžou interaktivně přihlásit, musí je přidat uživatelský účet, který může přidávat uživatele do organizace, projektu nebo týmu. Tito uživatelé zahrnují Správa istrátory kolekce projektů (PCA) nebo Project Správa istrátory a týmové Správa istrátory, pokud je povolená zásada Povolit správcům týmu a projektů pozvat nové uživatele.

Tip

Pokud chcete do organizace přidat instanční objekt, zadejte zobrazovaný název aplikace nebo spravované identity. Pokud se rozhodnete instanční objekt přidat prostřednictvím kódu programu prostřednictvím ServicePrincipalEntitlements rozhraní API, nezapomeňte předat ID objektu instančního objektu, nikoli ID objektu aplikace.

Pokud jste PCA, můžete také udělit instančnímu objektu přístup ke konkrétním projektům a přiřadit licenci. Pokud nejste PCA, musíte se obrátit na PCA, abyste aktualizovali členství v projektu nebo úrovně přístupu k licencím.

Poznámka:

Spravovanou identitu nebo instanční objekt můžete přidat jenom pro tenanta, ke kterému je vaše organizace připojená. Pokud chcete získat přístup ke spravované identitě v jiném tenantovi, podívejte se na alternativní řešení v nejčastějších dotazech.

Po přidání instančních objektů do organizace s nimi můžete zacházet podobně jako se standardními uživatelskými účty. Oprávnění můžete přiřadit přímo u instančního objektu, přidat ho do skupin zabezpečení a týmů, přiřadit je k libovolné úrovni přístupu a odebrat je z organizace. Můžete také použít Service Principal Graph APIs k provádění operací CRUD s instančními objekty.

Správa instančních objektů se liší od uživatelských účtů následujícími klíčovými způsoby:

• Instanční objekty nemají e-maily a proto je nejde pozvat do organizace e-mailem.
• Pravidla skupin pro licencování se v současné době nevztahují na instanční objekty. Pokud chcete instančnímu objektu přiřadit úroveň přístupu, je nejlepší to udělat přímo.
• I když je možné instanční objekty přidat do skupin Microsoft Entra (na webu Azure Portal), máme aktuální technické omezení, které nám brání v jejich zobrazení v seznamu členů skupiny Microsoft Entra. Toto omezení neplatí pro skupiny Azure DevOps. To znamená, že instanční objekt stále dědí všechna oprávnění skupiny nastavená nad skupinou Microsoft Entra, do které patří.
• Ne všichni uživatelé ve skupině Microsoft Entra jsou okamžitě součástí organizace Azure DevOps, protože správce vytvoří skupinu a přidá do ní skupinu Microsoft Entra. Máme proces označovaný jako materializace, který se stane, když se uživatel ze skupiny Microsoft Entra poprvé přihlásí k organizaci. Uživatel, který se přihlašuje k organizaci, nám umožňuje určit, kteří uživatelé by měli mít udělenou licenci. Vzhledem k tomu, že přihlášení není možné pro instanční objekty, musí ho správce explicitně přidat do organizace, jak je popsáno výše.
• V Azure DevOps nemůžete změnit zobrazovaný název ani avatar instančního objektu.
• Instanční objekt se počítá jako licence pro každou organizaci, do které se přidá, i když je vybrána fakturace ve více organizacích.

3. Přístup k prostředkům Azure DevOps pomocí tokenu Microsoft Entra ID

Získání tokenu ID Microsoft Entra

Získání přístupového tokenu pro spravovanou identitu je možné provést pomocí dokumentace k Microsoft Entra ID. Další informace najdete v příkladech instančních objektů a spravovaných identit.

Vrácený přístupový token je JWT s definovanými rolemi, které lze použít pro přístup k prostředkům organizace pomocí tokenu jako bearer.

Použití tokenu ID Microsoft Entra k ověření prostředků Azure DevOps

V následujícím příkladu videa přecházíme z ověřování pomocí pat na použití tokenu z instančního objektu. Začneme používat tajný klíč klienta pro ověřování a pak přejdeme k použití klientského certifikátu.

• I když je možné instanční objekty přidat do skupin Microsoft Entra ID (na webu Azure Portal), máme aktuální technické omezení, které nám brání v jejich zobrazení v seznamu členů skupiny Microsoft Entra ID. Toto omezení neplatí pro skupiny Azure DevOps. To znamená, že instanční objekt stále dědí všechna oprávnění skupiny nastavená nad skupinou Microsoft Entra ID, do které patří.
• Ne všichni uživatelé ve skupině Microsoft Entra ID jsou okamžitě součástí organizace Azure DevOps, protože správce vytvoří skupinu a přidá do ní skupinu Microsoft Entra ID. Máme proces označovaný jako materializace, který se stane, když se uživatel ze skupiny Microsoft Entra ID poprvé přihlásí k organizaci. Uživatel, který se přihlašuje k organizaci, nám umožňuje určit, kteří uživatelé by měli mít udělenou licenci. Vzhledem k tomu, že přihlášení není možné pro instanční objekty, musí ho správce explicitně přidat do organizace, jak je popsáno výše.
• V Azure DevOps nemůžete změnit zobrazovaný název ani avatar instančního objektu.
• Instanční objekt se počítá jako licence pro každou organizaci, do které se přidá, i když je vybrána fakturace ve více organizacích.

Další příklad ukazuje, jak se připojit k Azure DevOps pomocí spravované identity přiřazené uživatelem v rámci funkce Azure Functions.

Postupujte podle těchto příkladů vyhledáním kódu aplikace v naší kolekci ukázkových aplikací.

Instanční objekty se dají použít k volání rozhraní REST API Azure DevOps a provádění většiny akcí, ale jsou omezené na následující operace:

• Instanční objekty nemůžou být vlastníky organizace ani vytvářet organizace.
• Instanční objekty nemůžou vytvářet tokeny, jako jsou osobní přístupové tokeny (PAT) nebo klíče SSH. Můžou vygenerovat vlastní tokeny ID Microsoft Entra a tyto tokeny je možné použít k volání rozhraní REST API Azure DevOps.
• Azure DevOps OAuth nepodporujeme pro instanční objekty.

Poznámka:

K vygenerování tokenů můžete použít pouze ID aplikace a ne identifikátory URI prostředků přidružené k Azure DevOps.

Nejčastější dotazy

OBECNÉ

Otázka: Proč mám místo PAT používat instanční objekt nebo spravovanou identitu?

A: Mnozí naši zákazníci hledají instanční objekt nebo spravovanou identitu, aby nahradili stávající token PAT (personal access token). Takové paty často patří k účtu služby (sdílený týmový účet), který je používá k ověření aplikace pomocí prostředků Azure DevOps. PAT se musí pracně otáčet každých tolikrát (minimálně 180 dní). Vzhledem k tomu, že PAT jsou jednoduše nosné tokeny, což znamená řetězce tokenů, které představují uživatelské jméno a heslo uživatele, jsou neuvěřitelně rizikové, protože mohou snadno spadnout do rukou nesprávné osoby. Platnost tokenů Microsoft Entra vyprší každou hodinu a musí se znovu vygenerovat pomocí obnovovacího tokenu, aby se získal nový přístupový token, který omezuje celkový rizikový faktor při úniku.

Instanční objekt nemůžete použít k vytvoření osobního přístupového tokenu.

Otázka: Jaké jsou limity četnosti instančních objektů a spravovaných identit?

A: V tuto chvíli mají instanční objekty a spravované identity stejné limity rychlosti jako uživatelé.

Otázka: Bude použití této funkce stát více?

A: Instanční objekty a spravované identity jsou cenově podobné jako uživatelé na základě úrovně přístupu. Jedna z hledných změn se týká toho, jak zacházíme s "fakturací více organizací" pro instanční objekty. Uživatelé se započítávají jenom jako jedna licence bez ohledu na to, kolik organizací se nachází. Instanční objekty se počítají jako jedna licence pro každou organizaci, ve které uživatel je. Tento scénář se podobá standardní fakturaci na základě přiřazení uživatele.

Otázka: Můžu v Azure CLI použít instanční objekt nebo spravovanou identitu?

Ano! Přístupové tokeny Microsoft Entra ID můžou přijímat také kdekoli, kde se v Azure CLI žádá o paty. Podívejte se na tyto příklady, jak můžete předat token Microsoft Entra pro ověření pomocí rozhraní příkazového řádku.

# 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

Teď získáme token Microsoft Entra (UUID prostředku Azure DevOps je 499b84ac-1321-427f-aa17-267ca6975798) a zkusme volat rozhraní AZURE DevOps API předáním hlaviček jako Bearer tokenu:

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

Teď můžete použít az cli příkazy podle obvyklého použití.

Otázka: Můžu do své organizace přidat spravovanou identitu z jiného tenanta?

A: Spravovanou identitu můžete přidat jenom ze stejného tenanta, ke kterému je vaše organizace připojená. Máme ale alternativní řešení, které umožňuje nastavit spravovanou identitu v tenantovi prostředků, kde jsou všechny vaše prostředky. Potom ho můžete povolit, aby ho používal instanční objekt v cílovém tenantovi, kde je vaše organizace připojená. Jako alternativní řešení postupujte následovně:

1. Vytvořte spravovanou identitu přiřazenou uživatelem na webu Azure Portal pro vašeho tenanta prostředků.
2. Připojení virtuálnímu počítači a přiřaďte jí tuto spravovanou identitu.
3. Vytvořte trezor klíčů a vygenerujte certifikát (nesmí být typu PEM). Když tento certifikát vygenerujete, vygeneruje se také tajný kód se stejným názvem, který použijeme později.
4. Udělte přístup ke spravované identitě, aby mohl číst privátní klíč z trezoru klíčů. Vytvořte zásadu přístupu v trezoru klíčů s oprávněními Get/List (v části Oprávnění tajných kódů a vyhledejte spravovanou identitu v části Vybrat objekt zabezpečení.
5. Stáhněte vytvořený certifikát ve formátu CER, který zajistí, že neobsahuje soukromou část vašeho certifikátu.
6. Vytvořte novou registraci aplikace v cílovém tenantovi.
7. Nahrajte stažený certifikát do této nové aplikace na kartě Certifikáty a tajné kódy.
8. Přidejte instanční objekt této aplikace do organizace Azure DevOps, ke které chceme získat přístup, a nezapomeňte nastavit instanční objekt s požadovanými oprávněními.
9. Informace o získání přístupového tokenu Microsoft Entra z tohoto instančního objektu, který využívá certifikát spravované identity, najdete v následující ukázce kódu:

Poznámka:

Certifikáty musíte pravidelně obměňovat, stejně jako vždy.

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

Artefakty

Otázka: Můžu použít instanční objekt pro připojení k informačním kanálům?

Ano, můžete se připojit k libovolnému informačnímu kanálu Azure Artifacts pomocí instančního objektu. V následujících příkladech si ukážeme, jak se připojit pomocí tokenu ID Microsoft Entra pro NuGet, npm a Maven, ale měly by fungovat i jiné typy informačních kanálů.

Nastavení projektu NuGet pomocí tokenu Microsoft Entra

1. Do projektu přidejte soubor nuget.config ve stejné složce jako soubor .csproj nebo .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. Získejte token ID Microsoft Entra pro váš instanční objekt.

3. Spuštěním následujícího příkazu se ověřte pomocí svých přihlašovacích údajů a pak pomocí příkazu setapikey přidejte token. Tento příkaz přidá zdroj informačního kanálu do souboru nuget.config:

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

nastavení projektu npm pomocí tokenů Microsoft Entra

Poznámka:

Nástroj vsts-npm-auth nepodporuje přístupové tokeny Microsoft Entra.

1. .npmrc Přidejte do projektu ve stejném adresáři jako váš package.json.

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

2. Získejte přístupový token pro instanční objekt nebo spravovanou identitu.

3. Přidejte tento kód do svého zástupného symbolu [AAD_SERVICE_PRINCIPAL_ACCESS_TOKEN] a nahraďte ${user.home}/.npmrc ho přístupovým tokenem z předchozího kroku.

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

Nastavení projektu Maven pomocí tokenů Microsoft Entra

1. Přidejte úložiště do oddílů pom.xml<repositories> i <distributionManagement> oddílů.

   <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. Získejte přístupový token pro instanční objekt nebo spravovanou identitu.

3. Přidejte nebo upravte settings.xml soubor ${user.home}/.m2 a nahraďte zástupný symbol [AAD_SERVICE_PRINCIPAL_ACCESS_TOKEN] přístupovým tokenem z předchozího kroku.

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

Marketplace

Otázka: Můžu použít instanční objekt k publikování rozšíření na Visual Studio Marketplace?

Odpověď: Ano. Proveďte následující kroky.

1. Přidejte instanční objekt jako člena do účtu vydavatele. ID instančního objektu můžete získat z jeho profilu pomocí profilů – Získat. Potom můžete instanční objekt přidat jako člena vydavatele pomocí ID z předchozího kroku.

2. Publikujte rozšíření prostřednictvím rozhraní příkazového řádku TFX pomocí sp. Spuštěním následujícího příkazu rozhraní příkazového řádku TFX použijte přístupový token SP:

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

Pipelines

Otázka: Můžu použít spravovanou identitu v rámci připojení služby? Jak můžu snadněji obměňovat tajné kódy instančního objektu v připojení ke službě? Můžu se vyhnout úplnému ukládání tajných kódů do připojení služby?

podpora Azure s federace identit úloh pomocí protokolu OpenID Připojení, který nám umožňuje vytvářet připojení služby bez tajných kódů v Azure Pipelines založené na instančních objektech nebo spravovaných identitách s federovanými přihlašovacími údaji v Microsoft Entra ID. V rámci svého spuštění může kanál vyměnit svůj vlastní interní token s tokenem Microsoft Entra, čímž získá přístup k prostředkům Azure. Po implementaci se tento mechanismus doporučuje v produktu přes jiné typy připojení služeb Azure, která existují dnes. Tento mechanismus lze použít také k nastavení nasazení bez tajných kódů s jakýmkoli jiným poskytovatelem služeb kompatibilním s OIDC. Tento mechanismus je ve verzi Preview.

Repos

Otázka: Můžu k operacím Gitu použít instanční objekt, jako je klonování úložiště?

A: Podívejte se na následující příklad toho, jak jsme předali token MICROSOFT Entra ID instančního objektu místo PAT pro git klonování úložiště ve skriptu PowerShellu.

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

Tip

Pokud chcete token zabezpečit lépe, používejte správce přihlašovacích údajů, abyste nemuseli zadávat přihlašovací údaje pokaždé. Doporučujeme Git Credential Manager, který může přijímat tokeny Microsoft Entra (tj. tokeny Microsoft Identity OAuth) místo PAT, pokud se změní proměnná prostředí.

Užitečný tip k získání přístupového tokenu z Azure CLI pro volání příkazu git fetch:

1. Otevřete konfiguraci Gitu úložiště:

git config -e

1. Přidejte následující řádky, kde je 499b84ac-1321-427f-aa17-267ca6975798UUID prostředku 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. Otestujte, že funguje pomocí:

GIT_TRACE=1 GCM_TRACE=1 GIT_CURL_VERBOSE=1 git fetch

Potenciální chyby

Vytvoření instančního objektu s ID objektu {provided objectId} se nezdařilo.

V tenantovi připojeném provided objectId k vaší organizaci není žádný instanční objekt. Jedním z běžných důvodů je, že předáváte ID objektu registrace aplikace místo ID objektu jeho instančního objektu. Nezapomeňte, že instanční objekt je objekt, který představuje aplikaci pro daného tenanta, nejedná se o samotnou aplikaci. Najdete ji service principal object ID na stránce Podnikové aplikace vašeho tenanta. Vyhledejte název aplikace a vyberte výsledek "Podniková aplikace", který se vrátí. Tento výsledek je stránka instančního objektu nebo podnikové aplikace a id objektu, které najdete na této stránce, můžete použít k vytvoření instančního objektu v Azure DevOps.

Přístup byl odepřen: {ID of the caller identity} k provedení této akce potřebuje následující oprávnění k prostředku Uživatelé: Přidat uživatele

Příčinou této chyby může být jeden z následujících důvodů:

• Nejste vlastníkem organizace, správce kolekce projektů ani projekt nebo správce týmu.
• Jste správcem projektu nebo týmu, ale zásada Povolit správcům týmů a projektů pozvat nové uživatele je zakázaná.
• Jste projekt nebo správce týmu, který může pozvat nové uživatele, ale pokoušíte se přiřadit licenci, když pozvete nového uživatele. Správci projektu nebo týmu nemají oprávnění přiřazovat licenci novým uživatelům. Každý nový pozvaný uživatel se přidá na výchozí úroveň přístupu pro nové uživatele. Pokud chcete změnit úroveň přístupu k licencím, obraťte se na PCA.

Rozhraní Azure DevOps Graph List API vrací prázdný seznam, i když víme, že v organizaci existují instanční objekty.

Rozhraní Azure DevOps Graph List API může vrátit prázdný seznam, i když se vrátí ještě více stránek uživatelů. continuationToken Pomocí iterace v seznamech a nakonec můžete najít stránku, kde se vrátí instanční objekty. Pokud se vrátí, continuationToken znamená to, že prostřednictvím rozhraní API je k dispozici více výsledků. I když máme plány na zlepšení této logiky, v tuto chvíli je možné, že první výsledky X vrátí prázdné.

TF401444: Přihlaste se alespoň jednou jako {tenantId'tenantId\servicePrincipalObjectId'} ve webovém prohlížeči, abyste povolili přístup ke službě.

Pokud instanční objekt nebyl pozván do organizace, můžete narazit na následující chybu. Ujistěte se, že je instanční objekt přidaný do příslušné organizace a má všechna oprávnění potřebná pro přístup k požadovaným prostředkům.

Související články

• Odkaz na ukázkové aplikace
• Referenční informace k rozhraní API pro nároky instančních objektů
• Referenční informace k rozhraní Graph API instančního objektu