Usar entidades de serviço e identidades gerenciadas

Azure DevOps Services

Adicione entidades de serviço e identidades gerenciadas do Microsoft Entra às suas organizações do Azure DevOps Services para conceder acesso aos recursos da sua organização. Para muitas equipes, esse recurso pode ser uma alternativa viável e preferencial aos PATs (tokens de acesso pessoal) quando você autentica aplicativos que alimentam fluxos de trabalho de automação em sua empresa.

Sobre entidades de serviço e identidades gerenciadas

As entidades de serviço são objetos de segurança em um aplicativo do Microsoft Entra que definem o que um aplicativo pode fazer em um determinado locatário. Eles são configurados no portal do Azure durante o processo de registro do aplicativo e configurados para acessar recursos do Azure, como o Azure DevOps. Ao adicionar entidades de serviço à sua organização e configurar permissões sobre elas, podemos determinar se uma entidade de serviço está autorizada a acessar seus recursos organizacionais e quais deles.

As identidades gerenciadas são outro recurso do Microsoft Entra que atua de forma semelhante às entidades de serviço de um aplicativo. Esses objetos fornecem identidades para recursos do Azure e permitem uma maneira fácil para que os serviços que dão suporte à autenticação do Microsoft Entra compartilhem credenciais. Eles são uma opção atraente porque o Microsoft Entra ID cuida do gerenciamento e da rotação de credenciais. Embora a configuração de uma identidade gerenciada possa parecer diferente no portal do Azure, o Azure DevOps trata os dois objetos de segurança da mesma forma que uma nova identidade em uma organização com permissões definidas. Ao longo do restante deste artigo, nos referimos a identidades gerenciadas e entidades de serviço intercambiáveis como entidade de serviço, a menos que especificado.

Use as etapas a seguir para autenticar essas identidades no Azure DevOps para permitir que elas executem ações em nome de si mesmas.

Configurar identidades gerenciadas e entidades de serviço

Sua implementação pode variar, mas em um alto nível, as etapas a seguir ajudam você a começar a usar entidades de serviço em seu fluxo de trabalho. Considere examinar um de nossos aplicativos de exemplo para acompanhar um exemplo por conta própria.

1. Criar uma nova identidade gerenciada ou uma entidade de serviço de aplicativo

Crie uma entidade de serviço de aplicativo ou uma identidade gerenciada no portal do Azure.

Criar uma entidade de serviço de aplicativo

Quando você cria um novo registro de aplicativo, um objeto de aplicativo é criado na ID do Microsoft Entra. A entidade de serviço de aplicativo é uma representação desse objeto de aplicativo para um determinado locatário. Quando você registra um aplicativo como um aplicativo multilocatário, há um objeto de entidade de serviço exclusivo que representa o objeto de aplicativo para cada locatário ao qual o aplicativo é adicionado.

Mais informações:

• Objetos de entidade de serviço e aplicativo no Microsoft Entra ID
• Proteção de entidades de serviço
• Use o portal para criar um aplicativo do Microsoft Entra e uma entidade de serviço que possa acessar recursos

Criar uma identidade gerenciada

A criação de identidades gerenciadas no portal do Azure difere significativamente da configuração de aplicativos com entidades de serviço. Antes de iniciar o processo de criação, você deve primeiro considerar qual tipo de identidade gerenciada deseja criar:

• Identidade gerenciada atribuída pelo sistema: Alguns serviços do Azure permitem habilitar uma identidade gerenciada diretamente em uma instância de serviço. Quando você habilita uma identidade gerenciada atribuída pelo sistema, uma identidade é criada no Microsoft Entra ID. A identidade é vinculada ao ciclo de vida dessa instância de serviço. Quando o recurso é excluído, o Azure exclui automaticamente a identidade para você. Por design, somente o recurso do Azure pode usar essa identidade para solicitar tokens do Microsoft Entra ID.
• Identidade gerenciada atribuída pelo usuário Você também pode criar uma identidade gerenciada como um recurso autônomo do Azure criando uma identidade gerenciada atribuída pelo usuário e atribuindo-a a uma ou mais instâncias de um serviço do Azure. Para identidades gerenciadas atribuídas pelo usuário, a identidade é gerenciada separadamente dos recursos que a usam.

Para obter mais informações, consulte os seguintes artigos e vídeos:

• O que são identidades gerenciadas para recursos do Azure?
• Gerenciar identidades gerenciadas e atribuídas pelo usuário
• Configurar identidades gerenciadas para recursos do Azure em uma VM usando o portal do Azure

2. Adicionar e gerenciar entidades de serviço em uma organização do Azure DevOps

Depois de configurar as entidades de serviço no centro de administração do Microsoft Entra, você deve fazer o mesmo no Azure DevOps adicionando as entidades de serviço à sua organização. Você pode adicioná-los por meio da página Usuários ou com as APIs ServicePrincipalEntitlements. Como eles não podem entrar interativamente, uma conta de usuário que pode adicionar usuários a uma organização, projeto ou equipe deve adicioná-los. Esses usuários incluem PCA (Administradores de Coleção de Projetos ) ou Administradores de Projeto e Administradores de Equipe quando a política "Permitir que administradores de equipe e de projeto convidem novos usuários" está habilitada.

Se você for um PCA, também poderá conceder a uma entidade de serviço acesso a projetos específicos e atribuir uma licença. Se você não for um PCA, entre em contato com o PCA para atualizar quaisquer associações de projeto ou níveis de acesso de licença.

Depois que suas entidades de serviço forem adicionadas à organização, você poderá tratá-las de forma semelhante às contas de usuário padrão. Você pode atribuir permissões diretamente em uma entidade de serviço, adicioná-la a grupos de segurança e equipes, atribuí-la a qualquer nível de acesso e removê-la da organização. Você também pode usar o Service Principal Graph APIs para executar operações CRUD em entidades de serviço.

O gerenciamento de entidades de serviço difere das contas de usuário das seguintes maneiras principais:

• As entidades de serviço não têm emails e, como tal, não podem ser convidadas para uma organização por email.
• Atualmente, as regras de grupo para licenciamento não se aplicam às entidades de serviço. Se você quiser atribuir um nível de acesso a uma entidade de serviço, é melhor fazer isso diretamente.
• Embora as entidades de serviço possam ser adicionadas a grupos do Microsoft Entra (no portal do Azure), temos uma limitação técnica atual que nos impede de exibi-las em uma lista de membros do grupo do Microsoft Entra. Essa limitação não é verdadeira para grupos do Azure DevOps. Dito isso, uma entidade de serviço ainda herda todas as permissões de grupo definidas sobre um grupo do Microsoft Entra ao qual pertence.
• Nem todos os usuários em um grupo do Microsoft Entra fazem parte imediatamente de uma organização do Azure DevOps apenas porque um administrador cria um grupo e adiciona um grupo do Microsoft Entra a ele. Temos um processo chamado "materialização" que acontece quando um usuário de um grupo do Microsoft Entra na organização pela primeira vez. Um usuário que entra em uma organização nos permite determinar quais usuários devem receber uma licença. Como a entrada não é possível para entidades de serviço, um administrador deve adicioná-la explicitamente a uma organização, conforme descrito anteriormente.
• Você não pode modificar o nome de exibição ou avatar de uma entidade de serviço no Azure DevOps.
• Uma entidade de serviço conta como uma licença para cada organização à qual ela é adicionada, mesmo que a cobrança de várias organizações seja selecionada.

3. Acessar recursos do Azure DevOps com um token de ID do Microsoft Entra

Obter um token de ID do Microsoft Entra

A aquisição de um token de acesso para uma identidade gerenciada pode ser feita seguindo a documentação da ID do Microsoft Entra. Para obter mais informações, consulte os exemplos de entidades de serviço e identidades gerenciadas.

O token de acesso retornado é um JWT com as funções definidas, que podem ser usadas para acessar recursos da organização usando o token como Portador.

Usar o token de ID do Microsoft Entra para autenticar em recursos do Azure DevOps

No exemplo de vídeo a seguir, passamos da autenticação com um PAT para o uso de um token de uma entidade de serviço. Começamos usando um segredo do cliente para autenticação e, em seguida, passamos a usar um certificado do cliente.

• Embora as entidades de serviço possam ser adicionadas a grupos de ID do Microsoft Entra (no portal do Azure), temos uma limitação técnica atual que nos impede de exibi-las em uma lista de membros do grupo de ID do Microsoft Entra. Essa limitação não é verdadeira para grupos do Azure DevOps. Dito isso, uma entidade de serviço ainda herda todas as permissões de grupo definidas sobre um grupo de ID do Microsoft Entra ao qual pertence.
• Nem todos os usuários em um grupo de ID do Microsoft Entra fazem parte imediatamente de uma organização do Azure DevOps apenas porque um administrador cria um grupo e adiciona um grupo de ID do Microsoft Entra a ele. Temos um processo chamado "materialização" que acontece quando um usuário de um grupo de ID do Microsoft Entra na organização pela primeira vez. Um usuário que entra em uma organização nos permite determinar quais usuários devem receber uma licença. Como a entrada não é possível para entidades de serviço, um administrador deve adicioná-la explicitamente a uma organização, conforme descrito anteriormente.
• Você não pode modificar o nome de exibição ou avatar de uma entidade de serviço no Azure DevOps.
• Uma entidade de serviço conta como uma licença para cada organização à qual ela é adicionada, mesmo que a cobrança de várias organizações seja selecionada.

Outro exemplo demonstra como se conectar ao Azure DevOps usando uma Identidade Gerenciada Atribuída pelo Usuário em uma Função do Azure.

Acompanhe esses exemplos encontrando o código do aplicativo em nossa coleção de aplicativos de exemplo.

As entidades de serviço podem ser usadas para chamar APIs REST do Azure DevOps e realizar a maioria das ações, mas elas são limitadas das seguintes operações:

• As entidades de serviço não podem ser proprietárias da organização ou criar organizações.
• As entidades de serviço não podem criar tokens, como PATs (tokens de acesso pessoal) ou chaves SSH. Eles podem gerar seus próprios tokens de ID do Microsoft Entra e esses tokens podem ser usados para chamar APIs REST do Azure DevOps.
• Não damos suporte ao OAuth do Azure DevOps para entidades de serviço.

Perguntas Frequentes

Geral

P: Por que devo usar uma entidade de serviço ou uma identidade gerenciada em vez de um PAT?

R: Muitos de nossos clientes procuram uma entidade de serviço ou identidade gerenciada para substituir um PAT existente (token de acesso pessoal). Esses PATs geralmente pertencem a uma conta de serviço (conta de equipe compartilhada) que as está usando para autenticar um aplicativo com recursos do Azure DevOps. Os PATs devem ser girados laboriosamente de vez em quando (no mínimo 180 dias). Como os PATs são simplesmente tokens de portador, o que significa que as cadeias de caracteres de token que representam o nome de usuário e a senha de um usuário, elas são incrivelmente arriscadas de usar, pois podem facilmente cair nas mãos da pessoa errada. Os tokens do Microsoft Entra expiram a cada hora e devem ser regenerados com um token de atualização para obter um novo token de acesso, o que limita o fator de risco geral quando vazado.

Você não pode usar uma entidade de serviço para criar um token de acesso pessoal.

P: Quais são os limites de taxa em entidades de serviço e identidades gerenciadas?

R: Neste momento, as entidades de serviço e as identidades gerenciadas têm os mesmos limites de taxa que os usuários .

P: Usar esse recurso custará mais?

R: Entidades de serviço e identidades gerenciadas têm um preço semelhante ao dos usuários, com base no nível de acesso. Uma alteração notável diz respeito à forma como tratamos a "cobrança de várias organizações" para entidades de serviço. Os usuários são contados como apenas uma licença, independentemente de quantas organizações estejam. As entidades de serviço são contadas como uma licença por cada organização em que o usuário está. Esse cenário é semelhante ao "faturamento baseado em atribuição de usuário" padrão.

P: Posso usar uma entidade de serviço ou uma identidade gerenciada com a CLI do Azure?

A: Sim. Qualquer lugar que solicite PATs na CLI do Azure também pode aceitar tokens de acesso da ID do Microsoft Entra. Veja estes exemplos de como você pode passar um token do Microsoft Entra para autenticar com a 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

Agora, vamos obter um token do Microsoft Entra (o UUID do recurso do Azure DevOps é 499b84ac-1321-427f-aa17-267ca6975798) e tentar chamar uma API do Azure DevOps passando-a nos cabeçalhos como um 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

Agora, você pode usar az cli comandos de costume.

P: Posso adicionar uma identidade gerenciada de um locatário diferente à minha organização?

R: Você só pode adicionar uma identidade gerenciada do mesmo locatário ao qual sua organização está conectada. No entanto, temos uma solução alternativa que permite configurar uma identidade gerenciada no "locatário do recurso", onde estão todos os seus recursos. Em seguida, você pode habilitá-lo para ser usado por uma entidade de serviço no "locatário de destino", onde sua organização está conectada. Execute as seguintes etapas como uma solução alternativa:

1. Crie uma identidade gerenciada atribuída pelo usuário em portal do Azure para seu locatário de recurso.
2. Conecte-o a uma máquina virtual e atribua essa identidade gerenciada a ela.
3. Criar um cofre de chaves e gerar um certificado (não pode ser do tipo "PEM"). Quando você gera esse certificado, um segredo com o mesmo nome também é gerado, que usamos posteriormente.
4. Conceda acesso à identidade gerenciada para que ela possa ler a chave privada do cofre de chaves. Crie uma política de acesso no cofre de chaves com as permissões "Obter/Listar" (em "Permissões secretas" e pesquise a identidade gerenciada em "Selecionar entidade de segurança".
5. Baixe o certificado criado no formato "CER", o que garante que ele não contenha a parte privada do certificado.
6. Crie um novo registro de aplicativo no locatário de destino.
7. Carregue o certificado baixado para este novo aplicativo na guia "Certificados e segredos".
8. Adicione a entidade de serviço desse aplicativo à organização do Azure DevOps que desejamos acessar e lembre-se de configurar a entidade de serviço com as permissões necessárias.
9. Para obter um token de acesso do Microsoft Entra dessa entidade de serviço que usa o certificado de identidade gerenciada, consulte o seguinte exemplo de código:

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

P: Posso usar uma entidade de serviço para me conectar aos feeds?

R: Sim, você pode se conectar a qualquer feed do Azure Artifacts com uma entidade de serviço. Nos exemplos a seguir, demonstramos como se conectar a um token de ID do Microsoft Entra para NuGet, npm e Maven, mas outros tipos de feed também devem funcionar.

Configuração do projeto NuGet com o token do Microsoft Entra

1. Verifique se você tem o NuGet mais recente.

2. Baixe e instale o Provedor de Credenciais do Azure Artifacts:

   • Windows

   • Linux/Mac

3. Adicione um arquivo nuget.config ao seu projeto, na mesma pasta que o arquivo .csproj ou .sln :

   • Feed do projeto com escopo:

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

   • Feed da organização com escopo:

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

4. Defina a variável de ambiente ARTIFACTS_CREDENTIALPROVIDER_FEED_ENDPOINTS conforme mostrado abaixo, especificando a URL do feed, a ID do aplicativo (cliente) da entidade de serviço e o caminho para o certificado da entidade de serviço:

   • PowerShell:

     $env:ARTIFACTS_CREDENTIALPROVIDER_FEED_ENDPOINTS = @'
     {
       "endpointCredentials": [
         {
           "endpoint": "<FEED_URL>",
           "clientId": "<SERVICE_PRINCIPAL_APPLICATION_(CLIENT)_ID>",
           "clientCertificateFilePath": "<SERVICE_PRINCIPAL_CERTIFICATE_PATH>"
         }
       ]
     }
     '@
     

   • Bash:

     export ARTIFACTS_CREDENTIALPROVIDER_FEED_ENDPOINTS='{
       "endpointCredentials": [
         {
           "endpoint": "<FEED_URL>",
           "clientId": "<SERVICE_PRINCIPAL_APPLICATION_(CLIENT)_ID>",
           "clientCertificateFilePath": "<SERVICE_PRINCIPAL_CERTIFICATE_PATH>"
         }
       ]
     }'
     

Configuração do projeto npm com tokens do Microsoft Entra

1. Adicione um .npmrc ao seu projeto, no mesmo diretório que seu package.json.

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

2. Obtenha um token de acesso para sua entidade de serviço ou identidade gerenciada.

3. Adicione esse código ao seu ${user.home}/.npmrc e substitua o espaço reservado [AAD_SERVICE_PRINCIPAL_ACCESS_TOKEN] pelo token de acesso da etapa anterior.

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

Configuração do projeto Maven com tokens do Microsoft Entra

1. Adicione o repositório às suas pom.xmlseções e <distributionManagement> .<repositories>

   <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. Obtenha um token de acesso para sua Entidade de Serviço ou Identidade Gerenciada.

3. Adicione ou edite o settings.xml arquivo em ${user.home}/.m2 e substitua o espaço reservado [AAD_SERVICE_PRINCIPAL_ACCESS_TOKEN] pelo token de acesso da etapa anterior.

   <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

P: Posso usar uma entidade de serviço para publicar extensões no Visual Studio Marketplace?

A: Sim. Execute etapas a seguir.

1. Adicione uma entidade de serviço como membro a uma conta de publicador. Você pode obter a ID da entidade de serviço de seu perfil usando Perfis – Obter. Em seguida, você pode adicionar a entidade de serviço como membro ao editor usando a ID da etapa anterior.

2. Publique uma extensão por meio da CLI do TFX usando um SP. Execute o seguinte comando da CLI TFX para usar um token de acesso SP:

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

Pipelines

P: Posso usar uma identidade gerenciada em uma conexão de serviço? Como posso girar mais facilmente os segredos da entidade de serviço na minha conexão de serviço? Posso evitar o armazenamento de segredos em uma conexão de serviço?

O Azure dá suporte à federação de identidades de carga de trabalho usando o protocolo OpenID Connect, que nos permite criar conexões de serviço sem segredo no Azure Pipelines com suporte de entidades de serviço ou identidades gerenciadas com credenciais federadas na ID do Microsoft Entra. Como parte de sua execução, um pipeline pode trocar seu próprio token interno por um token do Microsoft Entra, obtendo assim acesso aos recursos do Azure. Depois de implementado, esse mecanismo é recomendado no produto em relação a outros tipos de conexões de serviço do Azure que existem hoje. Esse mecanismo também pode ser usado para configurar implantações sem segredo com qualquer outro provedor de serviços compatível com OIDC. Esse mecanismo está em versão prévia.

Repos

P: Posso usar uma entidade de serviço para fazer operações git, como clonar um repositório?

R: Veja o exemplo a seguir de como passamos um token de ID do Microsoft Entra de uma entidade de serviço em vez de um PAT para clonar um repositório em um script do 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}

Uma dica útil sobre como obter o token de acesso da CLI do Azure para chamar o git fetch:

1. Abra a configuração do Git do repositório:

git config -e

1. Adicione as seguintes linhas, em que o UUID do recurso do Azure DevOps é 00000000-0000-0000-0000-000000000000:

[credential]
    helper = "!f() { test \"$1\" = get && echo \"password=$(az account get-access-token --resource     00000000-0000-0000-0000-000000000000 --query accessToken -o tsv)\"; }; f" 

1. Teste se ele funciona usando:

GIT_TRACE=1 GCM_TRACE=1 GIT_CURL_VERBOSE=1 git fetch

Possíveis erros

Falha ao criar a entidade de serviço com a ID do objeto '{provided objectId}'

Não há nenhuma entidade de serviço com o provided objectId no locatário conectado à sua organização. Um motivo comum é que você está passando a ID do objeto do registro do aplicativo, em vez da ID do objeto de sua entidade de serviço. Lembre-se de que uma entidade de serviço é um objeto que representa o aplicativo para um determinado locatário, não é o aplicativo em si. O service principal object ID pode ser encontrado na página "Aplicativos Empresariais" do locatário. Pesquise o nome do aplicativo e selecione no resultado "Aplicativo Empresarial" que retorna. Esse resultado é a página da entidade de serviço/aplicativo empresarial e você pode usar a ID de Objeto encontrada nesta página para criar uma entidade de serviço no Azure DevOps.

Acesso Negado: {ID of the caller identity} precisa das seguintes permissões no recurso Usuários para executar esta ação: Adicionar Usuários

Esse erro pode ser devido a um dos seguintes motivos:

• Você não é o proprietário da organização, do administrador da coleção de projetos ou de um projeto ou administrador de equipe.
• Você é um administrador de projeto ou equipe, mas a política "Permitir que administradores de equipe e de projeto convidem novos usuários" está desativada.
• Você é um administrador de projeto ou equipe que pode convidar novos usuários, mas está tentando atribuir uma licença ao convidar um novo usuário. Os administradores do projeto ou da equipe não têm permissão para atribuir uma licença a novos usuários. Qualquer novo usuário convidado é adicionado no nível de acesso padrão para novos usuários. Entre em contato com um PCA para alterar o nível de acesso à licença.

A API de Lista do Graph do Azure DevOps retorna uma lista vazia, mesmo sabendo que há entidades de serviço na organização

A API de Lista de Graph do Azure DevOps pode retornar uma lista vazia, mesmo que ainda haja mais páginas de usuários a serem retornadas. Use o continuationToken para iterar por meio das listas e, eventualmente, você pode encontrar uma página em que as entidades de serviço são retornadas. Se um continuationToken for retornado, isso significa que há mais resultados disponíveis por meio da API. Embora tenhamos planos para melhorar essa lógica, neste momento, é possível que os primeiros resultados X retornem vazios.

TF401444: Entre pelo menos uma vez como {tenantId'tenantId\servicePrincipalObjectId'} em um navegador da Web para habilitar o acesso ao serviço.

Se a entidade de serviço não tiver sido convidada para a organização, você poderá encontrar o seguinte erro. Verifique se a entidade de serviço foi adicionada à organização apropriada e tem todas as permissões necessárias para acessar os recursos necessários.

Artigos relacionados

• Vincular a aplicativos de exemplo
• Referência de API de Direitos de Entidades de Serviço
• Referência de API do Graph da entidade de serviço