Uso de entidades de servicio e identidades administradas

  • Artículo

Azure DevOps Services

Agregue entidades de servicio de Microsoft Entra e identidades administradas a las organizaciones de Azure DevOps para conceder acceso a los recursos de la organización. Para muchos equipos, esta característica puede ser una alternativa viable y preferida a los tokens de acceso personal (PAT) al autenticar las aplicaciones que impulsan los flujos de trabajo de automatización de la empresa.

Acerca de las entidades de servicio e identidades administradas

Las entidades de servicio son objetos de seguridad dentro de una aplicación de Microsoft Entra que definen lo que una aplicación puede hacer en un inquilino determinado. Están configurados en el Azure Portal durante el proceso de registro de la aplicación y configurados para acceder a los recursos de Azure, como Azure DevOps. Al agregar entidades de servicio a su organización y configurar permisos sobre ellos, podemos determinar si una entidad de servicio está autorizada para acceder a los recursos de la organización y cuáles.

Las identidades administradas son otra característica de Microsoft Entra que actúa de forma similar a las entidades de servicio de una aplicación. Estos objetos proporcionan identidades para los recursos de Azure y permiten una manera sencilla de que los servicios que admiten la autenticación de Microsoft Entra compartan credenciales. Son una opción atractiva porque Microsoft Entra ID se encarga de la administración y rotación de credenciales. Aunque la configuración de una identidad administrada podría ser diferente en Azure Portal, Azure DevOps trata ambos objetos de seguridad igual que una nueva identidad en una organización con permisos definidos. En el resto de este artículo, nos referimos a identidades administradas y entidades de servicio indistintamente como entidad de servicio, a menos que se especifique.

Siga estos pasos para autenticar estas identidades en Azure DevOps para permitirles realizar acciones en nombre de sí mismas.

Configuración de identidades administradas y entidades de servicio

La implementación puede variar, pero en un nivel alto, los pasos siguientes le ayudarán a empezar a usar entidades de servicio en el flujo de trabajo. Considere la posibilidad de examinar una de nuestras aplicaciones de ejemplo para seguir un ejemplo por su cuenta.

1. Creación de una nueva identidad administrada o una entidad de servicio de aplicación

Cree una entidad de servicio de aplicación o una identidad administrada en el Azure Portal.

Creación de una entidad de servicio de aplicación

Al crear un nuevo registro de aplicación, se crea un objeto de aplicación en microsoft Entra ID. La entidad de servicio de la aplicación es una representación de este objeto de aplicación para un inquilino determinado. Al registrar una aplicación como una aplicación multiinquilino, hay un objeto de entidad de servicio único que representa el objeto de aplicación para cada inquilino al que se agrega la aplicación.

Información adicional:

Creación de una entidad administrada

La creación de identidades administradas en la Azure Portal difiere significativamente de la configuración de aplicaciones con entidades de servicio. Antes de comenzar el proceso de creación, primero debe tener en cuenta qué tipo de identidad administrada desea crear:

  • Identidad administrada asignada por el sistema: Algunos servicios de Azure permiten habilitar una identidad administrada directamente en una instancia de servicio. Al habilitar una identidad administrada asignada por el sistema, se crea una identidad en Microsoft Entra ID. La identidad está vinculada al ciclo de vida de esa instancia de servicio. Por tanto, cuando se elimina el recurso, Azure elimina automáticamente la identidad. Por diseño, solo ese recurso de Azure puede usar esta identidad para solicitar tokens de Microsoft Entra ID.
  • Identidad administrada asignada por el usuario También puede crear una identidad administrada como un recurso de Azure independiente mediante la creación de una identidad administrada asignada por el usuario y asignarla a una o varias instancias de un servicio de Azure. En las identidades administradas asignadas por el usuario, la identidad se administra independientemente de los recursos que la utilicen.

Para obtener más información, consulte los siguientes artículos y vídeos:

2. Incorporación y administración de entidades de servicio en una organización de Azure DevOps

Una vez configuradas las entidades de servicio en el Centro de administración de Microsoft Entra, debe hacer lo mismo en Azure DevOps agregando las entidades de servicio a su organización. Puede agregarlos a través de la página Usuarios o con las API ServicePrincipalEntitlements. Puesto que no pueden iniciar sesión de forma interactiva, una cuenta de usuario que pueda agregar usuarios a una organización, un proyecto o un equipo debe agregarlos. Estos usuarios incluyen administradores de colecciones de proyectos (PCA) o administradores de proyectos y administradores de equipo cuando está habilitada la directiva "Permitir que los administradores de equipos y proyectos inviten a nuevos usuarios ".

Sugerencia

Para agregar una entidad de servicio a la organización, escriba el nombre para mostrar de la aplicación o la identidad administrada. Si decide agregar una entidad de servicio mediante programación a través de la API, asegúrese de pasar el identificador de objeto de la ServicePrincipalEntitlementsentidad de servicio y no el identificador de objeto de la aplicación.

Si es un PCA, también puede conceder a una entidad de servicio acceso a proyectos específicos y asignar una licencia. Si no es un PCA, debe ponerse en contacto con el PCA para actualizar las pertenencias a proyectos o los niveles de acceso a licencias.

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

Nota:

Solo puede agregar una identidad administrada o una entidad de servicio para el inquilino al que está conectada la organización. Para acceder a una identidad administrada en un inquilino diferente, consulte la solución alternativa en las preguntas más frecuentes.

Una vez agregadas las entidades de servicio a la organización, puede tratarlas de forma similar a las cuentas de usuario estándar. Puede asignar permisos directamente en una entidad de servicio, agregarlos a grupos de seguridad y equipos, asignarlos a cualquier nivel de acceso y quitarlos de la organización. También puede usar Service Principal Graph APIs para realizar operaciones CRUD en entidades de servicio.

La administración de entidades de servicio difiere de las cuentas de usuario de las siguientes maneras clave:

  • Las entidades de servicio no tienen correos electrónicos y, como tal, no se pueden invitar a una organización por correo electrónico.
  • Actualmente, las reglas de grupo para las licencias no se aplican a las entidades de servicio. Si desea asignar un nivel de acceso a una entidad de servicio, es mejor hacerlo directamente.
  • Aunque las entidades de servicio se pueden agregar a grupos de Microsoft Entra (en Azure Portal), tenemos una limitación técnica actual que nos impide mostrarlas en una lista de miembros del grupo De Microsoft Entra. Esta limitación no es cierta para los grupos de Azure DevOps. Dicho esto, una entidad de servicio todavía hereda los permisos de grupo establecidos sobre un grupo de Microsoft Entra al que pertenecen.
  • No todos los usuarios de un grupo de Microsoft Entra forman parte inmediatamente de una organización de Azure DevOps solo porque un administrador crea un grupo y le agrega un grupo de Microsoft Entra. Tenemos un proceso denominado "materialización" que se produce una vez que un usuario de un grupo de Microsoft Entra inicia sesión en la organización por primera vez. Un usuario que inicia sesión en una organización nos permite determinar qué usuarios deben concederse una licencia. Dado que el inicio de sesión no es posible para las entidades de servicio, un administrador debe agregarlo explícitamente a una organización, como se ha descrito anteriormente.
  • No se puede modificar el nombre para mostrar de una entidad de servicio ni un avatar en Azure DevOps.
  • Una entidad de servicio cuenta como una licencia para cada organización a la que se agrega, incluso si se selecciona la facturación de varias organizaciones.

3. Acceso a los recursos de Azure DevOps con un token de identificador de Microsoft Entra

Obtención de un token de id. de Microsoft Entra

Para adquirir un token de acceso para una identidad administrada, siga la documentación de Microsoft Entra ID. Para más información, consulte los ejemplos de entidades de servicio e identidades administradas.

El token de acceso devuelto es un JWT con los roles definidos, que se pueden usar para acceder a los recursos de la organización mediante el token como portador.

Uso del token de identificador de Microsoft Entra para autenticarse en recursos de Azure DevOps

En el siguiente ejemplo de vídeo, pasamos de autenticarse con un PAT a usar un token de una entidad de servicio. Comenzamos con un secreto de cliente para la autenticación y, a continuación, pasamos a usar un certificado de cliente.

  • Aunque las entidades de servicio se pueden agregar a los grupos de identificadores de Microsoft Entra (en Azure Portal), tenemos una limitación técnica actual que nos impide mostrarlas en una lista de miembros del grupo de id. de Microsoft Entra. Esta limitación no es cierta para los grupos de Azure DevOps. Dicho esto, una entidad de servicio sigue heredando los permisos de grupo establecidos sobre un grupo de id. de Microsoft Entra al que pertenecen.
  • No todos los usuarios de un grupo de identificadores de Microsoft Entra forman parte inmediatamente de una organización de Azure DevOps solo porque un administrador crea un grupo y agrega un grupo de identificadores de Microsoft Entra a él. Tenemos un proceso denominado "materialización" que se produce una vez que un usuario de un grupo de identificadores de Microsoft Entra inicia sesión en la organización por primera vez. Un usuario que inicia sesión en una organización nos permite determinar qué usuarios deben concederse una licencia. Dado que el inicio de sesión no es posible para las entidades de servicio, un administrador debe agregarlo explícitamente a una organización, como se ha descrito anteriormente.
  • No se puede modificar el nombre para mostrar de una entidad de servicio ni un avatar en Azure DevOps.
  • Una entidad de servicio cuenta como una licencia para cada organización a la que se agrega, incluso si se selecciona la facturación de varias organizaciones.

Otro ejemplo muestra cómo conectarse a Azure DevOps mediante una identidad administrada asignada por el usuario dentro de una función de Azure.

Para seguir estos ejemplos, busque el código de la aplicación en nuestra colección de aplicaciones de ejemplo.

Las entidades de servicio se pueden usar para llamar a las API REST de Azure DevOps y realizar la mayoría de las acciones, pero se limita a las siguientes operaciones:

  • Las entidades de servicio no pueden ser propietarios de la organización ni crear organizaciones.
  • Las entidades de servicio no pueden crear tokens, como tokens de acceso personal (PAT) o claves SSH. Pueden generar sus propios tokens de identificador de Entra de Microsoft y estos tokens se pueden usar para llamar a las API rest de Azure DevOps.
  • No se admite OAuth de Azure DevOps para entidades de servicio.

Nota:

Solo puede usar el identificador de aplicación y no los URI de recursos asociados a Azure DevOps para generar tokens.

Preguntas más frecuentes

General

P: ¿Por qué debo usar una entidad de servicio o una identidad administrada en lugar de un PAT?

R: Muchos de nuestros clientes buscan una entidad de servicio o una identidad administrada para reemplazar un PAT existente (token de acceso personal). Estas PAT suelen pertenecer a una cuenta de servicio (cuenta de equipo compartida) que las usa para autenticar una aplicación con recursos de Azure DevOps. Las PAT deben rotarse de forma laboriosa cada una de las veces (mínimo 180 días). Como los PAT son simplemente tokens de portador, lo que significa cadenas de token que representan el nombre de usuario y la contraseña de un usuario, son increíblemente arriesgados de usar, ya que pueden caer fácilmente en las manos de la persona incorrecta. Los tokens de Microsoft Entra expiran cada hora y se deben volver a generar con un token de actualización para obtener un nuevo token de acceso, lo que limita el factor de riesgo general cuando se filtra.

No puede usar una entidad de servicio para crear un token de acceso personal.

P: ¿Cuáles son los límites de frecuencia en las entidades de servicio e identidades administradas?

R: En este momento, las entidades de servicio y las identidades administradas tienen los mismos límites de frecuencia que los usuarios.

P: ¿El uso de esta característica costará más?

R: Las entidades de servicio y las identidades administradas tienen un precio similar al de los usuarios, en función del nivel de acceso. Un cambio importante se refiere a cómo tratamos la "facturación de varias organizaciones" para las entidades de servicio. Los usuarios se cuentan como una sola licencia, independientemente del número de organizaciones en las que se encuentra. Las entidades de servicio se cuentan como una licencia por cada organización en la que se encuentra el usuario. Este escenario es similar al estándar "facturación basada en asignaciones de usuarios".

P: ¿Puedo usar una entidad de servicio o una identidad administrada con la CLI de Azure?

R: Sí. Cualquier lugar que solicite PAT en la CLI de Azure también puede aceptar tokens de acceso de Id. de Microsoft Entra. Consulte estos ejemplos sobre cómo puede pasar un token de Microsoft Entra para autenticarse con la 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

Ahora, vamos a obtener un token de Microsoft Entra (el UUID del recurso de Azure DevOps es 499b84ac-1321-427f-aa17-267ca6975798) e intente llamar a una API de Azure DevOps pasando los encabezados como un 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

Ahora, puede usar az cli comandos por lo habitual.

P: ¿Puedo agregar una identidad administrada desde un inquilino diferente a mi organización?

R: Solo puede agregar una identidad administrada desde el mismo inquilino al que está conectada la organización. Sin embargo, tenemos una solución alternativa que le permite configurar una identidad administrada en el "inquilino de recursos", donde están todos los recursos. A continuación, puede habilitarlo para que lo use una entidad de servicio en el "inquilino de destino", donde está conectada la organización. Siga estos pasos como solución alternativa:

  1. Cree una identidad administrada asignada por el usuario en Azure Portal para el inquilino de recursos.
  2. Conéctelo a una máquina virtual y asígnele esta identidad administrada .
  3. Cree un almacén de claves y genere un certificado (no puede ser de tipo "PEM"). Al generar este certificado, también se genera un secreto con el mismo nombre, que usamos más adelante.
  4. Conceda acceso a la identidad administrada para que pueda leer la clave privada desde el almacén de claves. Cree una directiva de acceso en el almacén de claves con los permisos "Get/List" (en "Permisos secretos" y busque la identidad administrada en "Seleccionar entidad de seguridad".
  5. Descargue el certificado creado en formato "CER", lo que garantiza que no contenga la parte privada del certificado.
  6. Cree un nuevo registro de aplicación en el inquilino de destino.
  7. Cargue el certificado descargado en esta nueva aplicación en la pestaña "Certificados y secretos".
  8. Agregue la entidad de servicio de esta aplicación a la organización de Azure DevOps a la que queremos que acceda y recuerde configurar la entidad de servicio con los permisos necesarios.
  9. Para obtener un token de acceso de Microsoft Entra desde esta entidad de servicio que usa el certificado de identidad administrada, consulte el ejemplo de código siguiente:

Nota:

Debe rotar periódicamente los certificados, como siempre.

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: ¿Puedo usar una entidad de servicio para conectarse a fuentes?

R: Sí, puede conectarse a cualquier fuente de Azure Artifacts con una entidad de servicio. En los ejemplos siguientes, se muestra cómo conectarse con un token de id. de Microsoft Entra para NuGet, npm y Maven, pero otros tipos de fuente también deben funcionar.

Configuración del proyecto de NuGet con el token de Microsoft Entra

  1. Agregue un archivo nuget.config al proyecto, en la misma carpeta que el archivo .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. Obtenga un token de id. de Microsoft Entra para la entidad de servicio.

  3. Ejecute el siguiente comando para autenticarse con sus credenciales y agregue el token mediante el comando setapikey. Este comando agrega el origen de la fuente a nuget.config:

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

nuget setapikey <YOUR_ACCESS_TOKEN> -source <SOURCE_URL>

Configuración del proyecto de npm con tokens de Microsoft Entra

Nota:

La herramienta vsts-npm-auth no admite tokens de acceso de Microsoft Entra.

  1. Agregue un .npmrc elemento al proyecto, en el mismo directorio que el package.json.

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

  2. Obtenga un token de acceso para la entidad de servicio o la identidad administrada.

  3. Agregue este código a ${user.home}/.npmrc y reemplace el marcador [AAD_SERVICE_PRINCIPAL_ACCESS_TOKEN] de posición por el token de acceso del paso anterior.

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

Configuración del proyecto de Maven con tokens de Microsoft Entra

  1. Agregue el repositorio a pom.xml<repositories> las secciones y <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. Obtenga un token de acceso para la entidad de servicio o la identidad administrada.

  3. Agregue o edite el settings.xml archivo en ${user.home}/.m2 y reemplace el marcador [AAD_SERVICE_PRINCIPAL_ACCESS_TOKEN] de posición por el token de acceso del paso 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: ¿Puedo usar una entidad de servicio para publicar extensiones en Visual Studio Marketplace?

A. Sí. Siga estos pasos.

  1. Agregue una entidad de servicio como miembro a una cuenta de publicador. Puede obtener el identificador de la entidad de servicio de su perfil mediante Profiles - Get. A continuación, puede agregar la entidad de servicio como miembro al publicador mediante el identificador del paso anterior.

  2. Publique una extensión a través de la CLI de TFX mediante un SP. Ejecute el siguiente comando de la CLI de TFX para usar un token de acceso de 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: ¿Puedo usar una identidad administrada dentro de una conexión de servicio? ¿Cómo puedo rotar más fácilmente los secretos de la entidad de servicio en mi conexión de servicio? ¿Puedo evitar almacenar los secretos en una conexión de servicio por completo?

Soporte técnico de Azure la federación de identidades de carga de trabajo mediante el protocolo OpenID Conectar, lo que nos permite crear conexiones de servicio sin secretos en Azure Pipelines respaldadas por entidades de servicio o identidades administradas con credenciales federadas en microsoft Entra ID. Como parte de su ejecución, una canalización puede intercambiar su propio token interno con un token de Microsoft Entra, lo que obtiene acceso a los recursos de Azure. Una vez implementado, este mecanismo se recomienda en el producto sobre otros tipos de conexiones de servicio de Azure que existen actualmente. Este mecanismo también se puede usar para configurar implementaciones sin secretos con cualquier otro proveedor de servicios compatible con OIDC. Este mecanismo está en versión preliminar.

Repos

P: ¿Puedo usar una entidad de servicio para realizar operaciones de Git, como clonar un repositorio?

R: Vea el ejemplo siguiente de cómo pasamos un token de identificador de Microsoft Entra de una entidad de servicio en lugar de un PAT para clonar un repositorio en un script de 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}

Sugerencia

Para mantener el token más seguro, use administradores de credenciales para que no tenga que escribir las credenciales cada vez. Se recomienda el Administrador de credenciales de Git, que puede aceptar tokens de Microsoft Entra (es decir, tokens de OAuth de Microsoft Identity) en lugar de PAT si se cambia una variable de entorno.

Una sugerencia útil sobre cómo obtener el token de acceso de la CLI de Azure para llamar a git fetch:

  1. Abra la configuración de Git del repositorio:
git config -e
  1. Agregue las líneas siguientes, donde el UUID del recurso de Azure DevOps es 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. Pruebe que funciona con:
GIT_TRACE=1 GCM_TRACE=1 GIT_CURL_VERBOSE=1 git fetch

Posibles errores

No se pudo crear la entidad de servicio con el identificador de objeto '{provided objectId}'

No hay ninguna entidad de servicio con en provided objectId el inquilino conectado a su organización. Una razón común es que se pasa el identificador de objeto del registro de la aplicación, en lugar del identificador de objeto de su entidad de servicio. Recuerde que una entidad de servicio es un objeto que representa la aplicación para un inquilino determinado, no es la propia aplicación. service principal object ID Puede encontrarse en la página "Aplicaciones empresariales" de su inquilino. Busque el nombre de la aplicación y seleccione el resultado "Aplicación empresarial" que devuelve. Este resultado es la página de la entidad de servicio o la aplicación empresarial y puede usar el identificador de objeto que se encuentra en esta página para crear una entidad de servicio en Azure DevOps.

Acceso denegado: {ID of the caller identity} necesita los siguientes permisos en el recurso Usuarios para realizar esta acción: Agregar usuarios

Este error puede deberse a uno de los siguientes motivos:

  • No es el propietario de la organización, el administrador de colecciones de proyectos ni un proyecto o administrador de equipo.
  • Es administrador de proyectos o equipos, pero la directiva "Permitir que los administradores de equipos y proyectos inviten a nuevos usuarios" está deshabilitada.
  • Es un administrador de proyecto o equipo que puede invitar a nuevos usuarios, pero está intentando asignar una licencia al invitar a un nuevo usuario. Los administradores del proyecto o del equipo no pueden asignar una licencia a los nuevos usuarios. Cualquier nuevo usuario invitado se agrega en el nivel de acceso predeterminado para los nuevos usuarios. Póngase en contacto con un PCA para cambiar el nivel de acceso de licencia.

Graph List API de Azure DevOps devuelve una lista vacía, aunque sabemos que hay entidades de servicio en la organización.

Graph List API de Azure DevOps podría devolver una lista vacía, incluso si todavía hay más páginas de usuarios que devolver. continuationToken Use para recorrer en iteración las listas y, finalmente, puede encontrar una página donde se devuelven las entidades de servicio. Si se devuelve un continuationToken , significa que hay más resultados disponibles a través de la API. Aunque tenemos planes para mejorar esta lógica, en este momento, es posible que los primeros resultados X devuelvan vacíos.

TF401444: inicie sesión al menos una vez como {tenantId'tenantId\servicePrincipalObjectId'} en un explorador web para habilitar el acceso al servicio.

Si no se ha invitado a la entidad de servicio a la organización, es posible que se produzca el siguiente error. Asegúrese de que la entidad de servicio se agrega a la organización adecuada y tiene todos los permisos necesarios para acceder a los recursos necesarios.