Usare entità servizio e identità gestite

  • Articolo

Servizi di Azure DevOps

Aggiungere entità servizio e identità gestite di Microsoft Entra alle organizzazioni di Azure DevOps per concedere l'accesso alle risorse dell'organizzazione. Per molti team, questa funzionalità può essere un'alternativa valida e preferita ai token di accesso personali (PAT) quando si autenticano le applicazioni che alimentano i flussi di lavoro di automazione nell'azienda.

Informazioni sulle entità servizio e sulle identità gestite

Le entità servizio sono oggetti di sicurezza all'interno di un'applicazione Microsoft Entra che definiscono le operazioni che un'applicazione può eseguire in un determinato tenant. Vengono configurati nel portale di Azure durante il processo di registrazione dell'applicazione e configurati per accedere alle risorse di Azure, ad esempio Azure DevOps. Aggiungendo le entità servizio all'organizzazione e configurando le autorizzazioni, è possibile determinare se un'entità servizio è autorizzata ad accedere alle risorse dell'organizzazione e a quali.

Le identità gestite sono un'altra funzionalità di Microsoft Entra che agisce in modo analogo alle entità servizio di un'applicazione. Questi oggetti forniscono identità per le risorse di Azure e consentono un modo semplice per i servizi che supportano l'autenticazione di Microsoft Entra per condividere le credenziali. Si tratta di un'opzione interessante perché Microsoft Entra ID si occupa della gestione e della rotazione delle credenziali. Anche se la configurazione per un'identità gestita potrebbe avere un aspetto diverso nella portale di Azure, Azure DevOps considera entrambi gli oggetti di sicurezza uguali a una nuova identità in un'organizzazione con autorizzazioni definite. Nel resto di questo articolo si fa riferimento alle identità gestite e alle entità servizio in modo intercambiabile come entità servizio, a meno che non sia specificato.

Usare la procedura seguente per autenticare queste identità in Azure DevOps per consentire loro di eseguire azioni per conto proprio.

Configurare le identità gestite e le entità servizio

L'implementazione può variare, ma a livello generale, i passaggi seguenti consentono di iniziare a usare le entità servizio nel flusso di lavoro. È consigliabile esaminare una delle nostre app di esempio per seguire un esempio personalizzato.

1. Creare una nuova identità gestita o un'entità servizio dell'applicazione

Creare un'entità servizio applicazione o un'identità gestita nella portale di Azure.

Creare un'entità servizio dell'applicazione

Quando si crea una nuova registrazione dell'applicazione, viene creato un oggetto applicazione in Microsoft Entra ID. L'entità servizio dell'applicazione è una rappresentazione di questo oggetto applicazione per un determinato tenant. Quando si registra un'applicazione come applicazione multi-tenant, è presente un oggetto entità servizio univoco che rappresenta l'oggetto applicazione per ogni tenant a cui viene aggiunta l'applicazione.

Altre informazioni:

Creare un'identità gestita

La creazione di identità gestite nel portale di Azure differisce in modo significativo rispetto alla configurazione di applicazioni con entità servizio. Prima di iniziare il processo di creazione, è necessario considerare il tipo di identità gestita da creare:

  • Identità gestita assegnata dal sistema: alcuni servizi di Azure consentono di abilitare un'identità gestita direttamente in un'istanza del servizio. Quando si abilita un'identità gestita assegnata dal sistema, viene creata un'identità in Microsoft Entra ID. L'identità viene associata al ciclo di vita di quell'istanza del servizio. Quando la risorsa viene eliminata, Azure elimina automaticamente anche l'identità. Per impostazione predefinita, solo questa specifica risorsa di Azure può usare questa identità per richiedere token ad Microsoft Entra ID.
  • Identità gestita assegnata dall'utente È anche possibile creare un'identità gestita come risorsa di Azure autonoma creando un'identità gestita assegnata dall'utente e assegnandola a una o più istanze di un servizio di Azure. Le identità gestite assegnate dall'utente vengono gestite separatamente rispetto alle risorse che le usano.

Per altre informazioni, vedere gli articoli e i video seguenti:

2. Aggiungere e gestire entità servizio in un'organizzazione di Azure DevOps

Dopo aver configurato le entità servizio nell'interfaccia di amministrazione di Microsoft Entra, è necessario eseguire le stesse operazioni in Azure DevOps aggiungendo le entità servizio all'organizzazione. È possibile aggiungerli tramite la pagina Utenti o con le API ServicePrincipalEntitlements. Poiché non possono accedere in modo interattivo, un account utente che può aggiungere utenti a un'organizzazione, a un progetto o a un team deve aggiungerli. Tali utenti includono Project Collection Amministrazione istrators (PCA) o Project Amministrazione istrators e Team Amministrazione istrators quando è abilitato il criterio "Consenti agli amministratori di team e progetti di invitare nuovi utenti".

Suggerimento

Per aggiungere un'entità servizio all'organizzazione, immettere il nome visualizzato dell'applicazione o dell'identità gestita. Se si sceglie di aggiungere un'entità servizio a livello di codice tramite l'APIServicePrincipalEntitlements, assicurarsi di passare l'ID oggetto dell'entità servizio e non l'ID oggetto dell'applicazione.

Se si è un PCA, è anche possibile concedere a un'entità servizio l'accesso a progetti specifici e assegnare una licenza. Se non sei un PCA, devi contattare il PCA per aggiornare eventuali appartenenze al progetto o livelli di accesso alle licenze.

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

Nota

È possibile aggiungere solo un'identità gestita o un'entità servizio per il tenant a cui è connessa l'organizzazione. Per accedere a un'identità gestita in un tenant diverso, vedere la soluzione alternativa nelle domande frequenti.

Dopo aver aggiunto le entità servizio all'organizzazione, è possibile gestirle in modo analogo agli account utente standard. È possibile assegnare le autorizzazioni direttamente in un'entità servizio, aggiungerla a gruppi di sicurezza e team, assegnarla a qualsiasi livello di accesso e rimuoverla dall'organizzazione. È anche possibile usare Service Principal Graph APIs per eseguire operazioni CRUD sulle entità servizio.

La gestione delle entità servizio è diversa dagli account utente nei modi principali seguenti:

  • Le entità servizio non hanno messaggi di posta elettronica e, di conseguenza, non possono essere invitati a un'organizzazione tramite posta elettronica.
  • Le regole di gruppo per le licenze attualmente non si applicano alle entità servizio. Se si vuole assegnare un livello di accesso a un'entità servizio, è consigliabile farlo direttamente.
  • Sebbene le entità servizio possano essere aggiunte ai gruppi di Microsoft Entra (nella portale di Azure), è presente una limitazione tecnica corrente che impedisce di visualizzarli in un elenco dei membri del gruppo Microsoft Entra. Questa limitazione non è vera per i gruppi di Azure DevOps. Detto questo, un'entità servizio eredita comunque tutte le autorizzazioni di gruppo impostate su un gruppo Microsoft Entra a cui appartengono.
  • Non tutti gli utenti di un gruppo Microsoft Entra fanno immediatamente parte di un'organizzazione di Azure DevOps solo perché un amministratore crea un gruppo e aggiunge un gruppo Microsoft Entra. È disponibile un processo denominato "materializzazione" che avviene una volta che un utente di un gruppo di Microsoft Entra accede all'organizzazione per la prima volta. Un utente che accede a un'organizzazione consente di determinare gli utenti a cui concedere una licenza. Poiché l'accesso non è possibile per le entità servizio, un amministratore deve aggiungerlo in modo esplicito a un'organizzazione come descritto in precedenza.
  • Non è possibile modificare il nome visualizzato o l'avatar di un'entità servizio in Azure DevOps.
  • Un'entità servizio viene conteggiato come licenza per ogni organizzazione a cui viene aggiunto, anche se è selezionata la fatturazione a più organizzazioni.

3. Accedere alle risorse di Azure DevOps con un token ID Microsoft Entra

Ottenere un token ID Microsoft Entra

L'acquisizione di un token di accesso per un'identità gestita può essere eseguita seguendo la documentazione di Microsoft Entra ID. Per altre informazioni, vedere gli esempi per le entità servizio e le identità gestite.

Il token di accesso restituito è un token JWT con i ruoli definiti, che può essere usato per accedere alle risorse dell'organizzazione usando il token come Bearer.

Usare il token ID Microsoft Entra per eseguire l'autenticazione alle risorse di Azure DevOps

Nell'esempio di video seguente si passa dall'autenticazione con un pat all'uso di un token da un'entità servizio. Per iniziare si usa un segreto client per l'autenticazione, quindi si passa all'uso di un certificato client.

  • Anche se le entità servizio possono essere aggiunte ai gruppi microsoft Entra ID (nella portale di Azure), è presente una limitazione tecnica corrente che impedisce di visualizzarli in un elenco dei membri del gruppo Microsoft Entra ID. Questa limitazione non è vera per i gruppi di Azure DevOps. Detto questo, un'entità servizio eredita comunque tutte le autorizzazioni di gruppo impostate su un gruppo di ID Microsoft Entra a cui appartengono.
  • Non tutti gli utenti di un gruppo Microsoft Entra ID fanno immediatamente parte di un'organizzazione di Azure DevOps solo perché un amministratore crea un gruppo e aggiunge un gruppo microsoft Entra ID. È disponibile un processo denominato "materializzazione" che avviene una volta che un utente di un gruppo microsoft Entra ID accede all'organizzazione per la prima volta. Un utente che accede a un'organizzazione consente di determinare gli utenti a cui concedere una licenza. Poiché l'accesso non è possibile per le entità servizio, un amministratore deve aggiungerlo in modo esplicito a un'organizzazione come descritto in precedenza.
  • Non è possibile modificare il nome visualizzato o l'avatar di un'entità servizio in Azure DevOps.
  • Un'entità servizio viene conteggiato come licenza per ogni organizzazione a cui viene aggiunto, anche se è selezionata la fatturazione a più organizzazioni.

Un altro esempio illustra come connettersi ad Azure DevOps usando un'identità gestita assegnata dall'utente all'interno di una funzione di Azure.

Seguire questi esempi trovando il codice dell'app nella raccolta di app di esempio.

Le entità servizio possono essere usate per chiamare le API REST di Azure DevOps ed eseguire la maggior parte delle azioni, ma è limitata dalle operazioni seguenti:

  • Le entità servizio non possono essere proprietari dell'organizzazione o creare organizzazioni.
  • Le entità servizio non possono creare token, ad esempio token di accesso personale (PAT) o chiavi SSH. Possono generare token ID Microsoft Entra e questi token possono essere usati per chiamare le API REST di Azure DevOps.
  • Azure DevOps OAuth non è supportato per le entità servizio.

Nota

È possibile usare solo l'ID applicazione e non gli URI delle risorse associati ad Azure DevOps per la generazione di token.

Domande frequenti

Generali

D: Perché è consigliabile usare un'entità servizio o un'identità gestita anziché un token di accesso personale?

R: Molti clienti cercano un'entità servizio o un'identità gestita per sostituire un token di accesso personale esistente. Tali TOKEN appartengono spesso a un account del servizio (account del team condiviso) che li usa per autenticare un'applicazione con le risorse di Azure DevOps. Le PTE devono essere ruotate laboriosamente ogni tanto (almeno 180 giorni). Poiché i token PAT sono semplicemente token di connessione, ovvero stringhe di token che rappresentano il nome utente e la password di un utente, sono incredibilmente rischiosi da usare perché possono facilmente cadere nelle mani della persona sbagliata. I token di Microsoft Entra scadono ogni ora e devono essere rigenerati con un token di aggiornamento per ottenere un nuovo token di accesso, che limita il fattore di rischio complessivo in caso di perdita.

Non è possibile usare un'entità servizio per creare un token di accesso personale.

D: Quali sono i limiti di frequenza per le entità servizio e le identità gestite?

R: Al momento, le entità servizio e le identità gestite hanno gli stessi limiti di frequenza degli utenti.

D: L'uso di questa funzionalità costa più?

R: Le entità servizio e le identità gestite hanno un prezzo simile a quello degli utenti, in base al livello di accesso. Una modifica rilevante riguarda il modo in cui viene gestita la fatturazione a più organizzazioni per le entità servizio. Gli utenti vengono conteggiati come una sola licenza, indipendentemente dal numero di organizzazioni in cui si trovano. Le entità servizio vengono conteggiate come una licenza per ogni organizzazione in cui si trova l'utente. Questo scenario è simile a quello standard "fatturazione basata sull'assegnazione degli utenti".

D: È possibile usare un'entità servizio o un'identità gestita con l'interfaccia della riga di comando di Azure?

R: Sì. Ovunque si richiedano token di accesso CONT nell'interfaccia della riga di comando di Azure, è anche possibile accettare i token di accesso di Microsoft Entra ID. Vedere questi esempi per informazioni su come passare un token Microsoft Entra in per eseguire l'autenticazione con l'interfaccia della riga di comando.

# 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

A questo punto, si otterrà un token Microsoft Entra (l'UUID della risorsa Azure DevOps è 499b84ac-1321-427f-aa17-267ca6975798) e si proverà a chiamare un'API di Azure DevOps passandola nelle intestazioni come 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

È ora possibile usare az cli i comandi per ogni consueto.

D: È possibile aggiungere un'identità gestita da un tenant diverso all'organizzazione?

R: È possibile aggiungere un'identità gestita solo dallo stesso tenant a cui è connessa l'organizzazione. Tuttavia, è disponibile una soluzione alternativa che consente di configurare un'identità gestita nel "tenant delle risorse", dove sono presenti tutte le risorse. È quindi possibile abilitarlo per l'uso da parte di un'entità servizio nel "tenant di destinazione", in cui l'organizzazione è connessa. Seguire questa procedura come soluzione alternativa:

  1. Creare un'identità gestita assegnata dall'utente in portale di Azure per il tenant delle risorse.
  2. Connessione a una macchina virtuale e assegnarvi questa identità gestita.
  3. Creare un insieme di credenziali delle chiavi e generare un certificato (non può essere di tipo "PEM"). Quando si genera questo certificato, viene generato anche un segreto con lo stesso nome, che verrà usato in un secondo momento.
  4. Concedere l'accesso all'identità gestita in modo che possa leggere la chiave privata dall'insieme di credenziali delle chiavi. Creare un criterio di accesso nell'insieme di credenziali delle chiavi con le autorizzazioni "Get/List" (in "Autorizzazioni segrete" e cercare l'identità gestita in "Seleziona entità".
  5. Scaricare il certificato creato in formato "CER", che garantisce che non contenga la parte privata del certificato.
  6. Creare una nuova registrazione dell'applicazione nel tenant di destinazione.
  7. Caricare il certificato scaricato in questa nuova applicazione nella scheda "Certificati e segreti".
  8. Aggiungere l'entità servizio dell'applicazione all'organizzazione Azure DevOps a cui si vuole accedere e ricordare di configurare l'entità servizio con le autorizzazioni necessarie.
  9. Per ottenere un token di accesso Microsoft Entra da questa entità servizio che usa il certificato di identità gestita, vedere l'esempio di codice seguente:

Nota

È necessario ruotare regolarmente i certificati, come sempre.

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

D: È possibile usare un'entità servizio per connettersi ai feed?

R: Sì, è possibile connettersi a qualsiasi feed di Azure Artifacts con un'entità servizio. Negli esempi seguenti viene illustrato come connettersi con un token ID Entra Microsoft per NuGet, npm e Maven, ma anche altri tipi di feed dovrebbero funzionare.

Configurazione del progetto NuGet con il token Microsoft Entra

  1. Aggiungere un file nuget.config al progetto, nella stessa cartella del file con estensione csproj o .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. Ottenere un token ID Microsoft Entra per l'entità servizio.

  3. Eseguire il comando seguente per eseguire l'autenticazione con le credenziali e quindi aggiungere il token usando il comando setapikey. Questo comando aggiunge l'origine del feed al file nuget.config:

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

nuget setapikey <YOUR_ACCESS_TOKEN> -source <SOURCE_URL>

Configurazione del progetto npm con token di Microsoft Entra

Nota

Lo strumento vsts-npm-auth non supporta i token di accesso di Microsoft Entra.

  1. Aggiungere un oggetto .npmrc al progetto nella stessa directory di package.json.

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

  2. Ottenere un token di accesso per l'entità servizio o l'identità gestita.

  3. Aggiungere questo codice al ${user.home}/.npmrc segnaposto e sostituire il segnaposto [AAD_SERVICE_PRINCIPAL_ACCESS_TOKEN] con il token di accesso del passaggio precedente.

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

Configurazione del progetto Maven con i token di Microsoft Entra

  1. Aggiungere il repository a entrambe le pom.xml<repositories> sezioni e <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. Ottenere un token di accesso per l'entità servizio o l'identità gestita.

  3. Aggiungere o modificare il settings.xml file in ${user.home}/.m2 e sostituire il segnaposto [AAD_SERVICE_PRINCIPAL_ACCESS_TOKEN] con il token di accesso del passaggio precedente.

    <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

D: È possibile usare un'entità servizio per pubblicare le estensioni in Visual Studio Marketplace?

R: Sì. Seguire questa procedura.

  1. Aggiungere un'entità servizio come membro a un account di pubblicazione. È possibile ottenere l'ID dell'entità servizio dal profilo usando Profiles - Get. È quindi possibile aggiungere l'entità servizio come membro al server di pubblicazione usando l'ID del passaggio precedente.

  2. Pubblicare un'estensione tramite l'interfaccia della riga di comando di TFX usando un sp. Eseguire il comando dell'interfaccia della riga di comando TFX seguente per usare un token di accesso SP:

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

Pipeline

D: È possibile usare un'identità gestita all'interno di una connessione al servizio? Come è possibile ruotare più facilmente i segreti per l'entità servizio nella connessione al servizio? È possibile evitare di archiviare completamente i segreti in una connessione al servizio?

supporto tecnico di Azure la federazione dell'identità del carico di lavoro usando il protocollo OpenID Connessione, che consente di creare connessioni al servizio senza segreto in Azure Pipelines supportate da entità servizio o identità gestite con credenziali federate in Microsoft Entra ID. Nell'ambito dell'esecuzione, una pipeline può scambiare il proprio token interno con un token Microsoft Entra, ottenendo così l'accesso alle risorse di Azure. Dopo l'implementazione, questo meccanismo è consigliato nel prodotto rispetto ad altri tipi di connessioni al servizio di Azure esistenti oggi. Questo meccanismo può essere usato anche per configurare distribuzioni senza segreto con qualsiasi altro provider di servizi conforme a OIDC. Questo meccanismo è disponibile in anteprima.

Repos

D: È possibile usare un'entità servizio per eseguire operazioni Git, ad esempio clonare un repository?

R: Vedere l'esempio seguente di come è stato passato un token ID Microsoft Entra di un'entità servizio invece di un pat per git clonare un repository in uno script di 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}

Suggerimento

Per proteggere il token, usare i gestori delle credenziali in modo da non dover immettere le credenziali ogni volta. È consigliabile usare Git Credential Manager, che può accettare i token Microsoft Entra( ovvero i token OAuth di Microsoft Identity) anziché i token PAT se viene modificata una variabile di ambiente.

Suggerimento utile su come ottenere il token di accesso dall'interfaccia della riga di comando di Azure per chiamare git fetch:

  1. Aprire la configurazione Git del repository:
git config -e
  1. Aggiungere le righe seguenti, in cui l'UUID della risorsa Azure DevOps è 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. Verificare che funzioni usando:
GIT_TRACE=1 GCM_TRACE=1 GIT_CURL_VERBOSE=1 git fetch

Potenziali errori

Impossibile creare un'entità servizio con ID oggetto '{provided objectId}'

Non esiste un'entità servizio con provided objectId nel tenant connesso all'organizzazione. Un motivo comune è che si passa l'ID oggetto della registrazione dell'app, anziché l'ID oggetto della relativa entità servizio. Tenere presente che un'entità servizio è un oggetto che rappresenta l'applicazione per un determinato tenant, non è l'applicazione stessa. È service principal object ID disponibile nella pagina "Applicazioni aziendali" del tenant. Cercare il nome dell'applicazione e selezionare il risultato "Applicazione aziendale" restituito. Questo risultato è la pagina dell'applicazione dell'entità servizio o dell'organizzazione ed è possibile usare l'ID oggetto disponibile in questa pagina per creare un'entità servizio in Azure DevOps.

Accesso negato: {ID of the caller identity} richiede le autorizzazioni seguenti per la risorsa Utenti per eseguire questa azione: Aggiungi utenti

Questo errore potrebbe essere dovuto a uno dei motivi seguenti:

  • Non si è il proprietario dell'organizzazione, dell'amministratore della raccolta di progetti o di un amministratore del progetto o del team.
  • Si è un progetto o un amministratore del team, ma il criterio "Consenti agli amministratori del team e del progetto di invitare nuovi utenti" è disabilitato.
  • Si è un amministratore del progetto o del team che può invitare nuovi utenti, ma si sta tentando di assegnare una licenza quando si invita un nuovo utente. Gli amministratori del progetto o del team non possono assegnare una licenza ai nuovi utenti. Qualsiasi nuovo utente invitato viene aggiunto al livello di accesso predefinito per i nuovi utenti. Contattare un PCA per modificare il livello di accesso alle licenze.

L'API Elenco Graph di Azure DevOps restituisce un elenco vuoto, anche se è noto che sono presenti entità servizio nell'organizzazione

L'API Elenco graph di Azure DevOps potrebbe restituire un elenco vuoto, anche se sono presenti ancora più pagine di utenti da restituire. Usare per continuationToken scorrere gli elenchi ed eventualmente trovare una pagina in cui vengono restituite le entità servizio. Se viene restituito un continuationToken oggetto , significa che sono disponibili più risultati tramite l'API. Anche se in questo momento si prevede di migliorare questa logica, è possibile che i primi risultati X restituisca vuoti.

TF401444: accedere almeno una volta come {tenantId'tenantId\servicePrincipalObjectId'} in un Web browser per abilitare l'accesso al servizio.

Se l'entità servizio non è stata invitata all'organizzazione, potrebbe verificarsi l'errore seguente. Assicurarsi che l'entità servizio venga aggiunta all'organizzazione appropriata e disponga di tutte le autorizzazioni necessarie per accedere alle risorse necessarie.