サービス プリンシパル と マネージド ID を使用する

Azure DevOps Services

Microsoft Entra サービス プリンシパルとマネージド ID を Azure DevOps 組織に追加して、組織のリソースへのアクセスを許可します。 多くのチームにとって、この機能は、社内の自動化ワークフローに力を入れるアプリケーションを認証する際に 、個人用アクセス トークン (AT) に代わる有効で推奨される代替手段となる可能性があります。

サービス プリンシパルとマネージド ID について

サービス プリンシパルは、特定の テナントでアプリケーションが実行できる操作を定義する Microsoft Entra アプリケーション内のセキュリティ オブジェクトです。 これらは、アプリケーション登録プロセス中にAzure portalで設定され、Azure DevOps などの Azure リソースにアクセスするように構成されます。 サービス プリンシパルをorganizationに追加し、その上にアクセス許可を設定することで、サービス プリンシパルが組織のリソースにアクセスする権限を持っているかどうか、およびどのサービス プリンシパルにアクセスするかを判断できます。

マネージド ID は、アプリケーションの サービス プリンシパルと同様に機能する Microsoft Entra のもう 1 つの機能です。 これらのオブジェクトは、Azure リソースの ID を提供し、Microsoft Entra 認証をサポートするサービスが資格情報を共有するための簡単な方法を提供します。 Microsoft Entra ID が資格情報の管理とローテーションを処理するため、これらは魅力的なオプションです。 マネージド ID のセットアップは Azure portal で異なる場合があります。Azure DevOps では、両方のセキュリティ オブジェクトが、定義されたアクセス許可を持つ組織内の新しい ID と同じように扱われます。 この記事の残りの部分では、指定されていない限り、マネージド ID とサービス プリンシパルをサービス プリンシパルと同じ意味で参照します。

これらの ID を Azure DevOps に対して認証し、ユーザーが自分に代わってアクションを実行できるようにするには、次の手順を使用します。

マネージド ID とサービス プリンシパルを構成する

実装は異なる場合がありますが、大まかに言えば、次の手順を実行すると、ワークフローでサービス プリンシパルの使用を開始できます。 サンプル アプリの 1 つを見て、独自の例に従うことを検討してください。

1. 新しいマネージド ID またはアプリケーション サービス プリンシパルを作成する

Azure portalでアプリケーション サービス プリンシパルまたはマネージド ID を作成します。

アプリケーション サービス プリンシパルを作成する

新しいアプリケーション登録を作成すると、Microsoft Entra ID にアプリケーション オブジェクトが作成されます。 アプリケーション サービス プリンシパルは、特定のテナントに対するこのアプリケーション オブジェクトを表します。 アプリケーションをマルチテナント アプリケーションとして登録すると、アプリケーションが追加されるすべてのテナントのアプリケーション オブジェクトを表す一意のサービス プリンシパル オブジェクトがあります。

詳細情報:

マネージド ID の作成

Azure portalでのマネージド ID の作成は、サービス プリンシパルを使用してアプリケーションを設定するのとは大きく異なります。 作成プロセスを開始する前に、まず、作成するマネージド ID の種類を検討する必要があります。

  • システム割り当てマネージド ID: 一部の Azure サービスでは、サービス インスタンスでマネージド ID を直接有効にすることができます。 システム割り当てマネージド ID を有効にすると、Microsoft Entra ID に ID が作成されます。 この ID は、そのサービス インスタンスのライフサイクルに関連付けられています。 リソースが削除されると、その ID も Azure によって自動的に削除されます。 その ID を使用して Microsoft Entra ID にトークンを要求できるのは、必然的に、その Azure リソースのみとなります。
  • ユーザー割り当てマネージド ID ユーザー割り当てマネージド ID を作成し、Azure サービスの 1 つ以上のインスタンスに割り当てることで、スタンドアロンの Azure リソースとしてマネージド ID を作成することもできます。 ユーザー割り当てマネージド ID の場合、ID は、それを使用するリソースとは別に管理されます。

詳細については、次の記事とビデオを参照してください。

2. Azure DevOps organizationでサービス プリンシパルを追加および管理する

Microsoft Entra 管理センターでサービス プリンシパルを構成したら、組織にサービス プリンシパルを追加して、Azure DevOps で同じ操作を行う必要があります。 [ユーザー] ページまたは ServicePrincipalEntitlements API を使用して追加できます。 対話形式でサインインできないため、ユーザーをorganization、プロジェクト、またはチームに追加できるユーザー アカウントで追加する必要があります。 このようなユーザーには、"チームおよびプロジェクト管理者に新しいユーザーの招待を許可する" ポリシーが有効になっている場合は、プロジェクト コレクション管理者 (PCA) またはプロジェクト管理者とチーム管理者が含まれます。

ヒント

organizationにサービス プリンシパルを追加するには、アプリケーションまたはマネージド ID の表示名を入力します。 API を使用してServicePrincipalEntitlementsサービス プリンシパルをプログラムで追加する場合は、アプリケーションのオブジェクト ID ではなく、サービス プリンシパルのオブジェクト ID を渡してください。

PCA の場合は、特定のプロジェクトへのアクセス権をサービス プリンシパルに付与し、ライセンスを割り当てることもできます。 PCA でない場合は、PCA に連絡して、プロジェクト メンバーシップまたはライセンス アクセス レベルを更新する必要があります。

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

Note

追加できるのは、組織が接続しているテナントのマネージド ID またはサービス プリンシパルのみです。 別のテナントのマネージド ID にアクセスするには、FAQ回避策を参照してください。

サービス プリンシパルをorganizationに追加した後は、標準ユーザー アカウントと同様に扱うことができます。 サービス プリンシパルに直接アクセス許可を割り当て、セキュリティ グループとチームに追加し、任意のアクセス レベルに割り当てて、organizationから削除することができます。 を使用 Service Principal Graph APIs して、サービス プリンシパルに対して CRUD 操作を実行することもできます。

サービス プリンシパルの管理は、次の主な方法でユーザー アカウントとは異なります。

  • サービス プリンシパルには電子メールがないため、メールを介してorganizationに招待することはできません。
  • 現在、ライセンスのグループルールはサービス プリンシパルには適用されません。 アクセス レベルをサービス プリンシパルに割り当てる場合は、直接割り当てることをお勧めします。
  • サービス プリンシパルは (Azure portal で) Microsoft Entra グループに追加できますが、Microsoft Entra グループ メンバーの一覧に表示できない技術的な制限があります。 この制限は、Azure DevOps グループには当てはまらない。 つまり、サービス プリンシパルは、所属する Microsoft Entra グループの上に設定されたグループのアクセス許可を継承します。
  • 管理者がグループを作成して Microsoft Entra グループを追加したからといって、Microsoft Entra グループのすべてのユーザーが Azure DevOps 組織にすぐに参加するわけではありません。 Microsoft Entra グループのユーザーが初めて組織にサインインすると、"具体化" と呼ばれるプロセスが行われます。 organizationにサインインするユーザーは、ライセンスを付与する必要があるユーザーを判断できます。 サービス プリンシパルではサインインできないため、管理者は前述のように明示的にorganizationに追加する必要があります。
  • Azure DevOps でサービス プリンシパルの表示名またはアバターを変更することはできません。
  • サービス プリンシパルは、複数組織の課金が選択されている場合でも、追加される各組織のライセンスとしてカウントされます。

3. Microsoft Entra ID トークンを使用して Azure DevOps リソースにアクセスする

Microsoft Entra ID トークンを取得する

マネージド ID のアクセス トークンの取得は、Microsoft Entra ID のドキュメントに従って行うことができます。 詳細については、 サービス プリンシパルマネージド ID の例を参照してください。

返されるアクセス トークンは、定義済みのロールを持つ JWT であり、トークンを Bearer として使用してorganizationリソースにアクセスするために使用できます。

Microsoft Entra ID トークンを使用して Azure DevOps リソースに対する認証を行う

次のビデオ例では、PAT を使用した認証からサービス プリンシパルからのトークンの使用に移行します。 まず、認証にクライアント シークレットを使用してから、クライアント証明書の使用に移行します。

  • サービス プリンシパルは Microsoft Entra ID グループ (Azure portal) に追加できますが、Microsoft Entra ID グループ メンバーの一覧に表示できない技術的な制限があります。 この制限は、Azure DevOps グループには当てはまらない。 ただし、サービス プリンシパルは、所属する Microsoft Entra ID グループの上に設定されたグループのアクセス許可を継承します。
  • 管理者がグループを作成し、そのグループに Microsoft Entra ID グループを追加したからといって、Microsoft Entra ID グループ内のすべてのユーザーが Azure DevOps 組織にすぐに参加するわけではありません。 Microsoft Entra ID グループのユーザーが初めて組織にサインインすると、"具体化" と呼ばれるプロセスが行われます。 organizationにサインインするユーザーは、ライセンスを付与する必要があるユーザーを判断できます。 サービス プリンシパルではサインインできないため、管理者は前述のように明示的にorganizationに追加する必要があります。
  • Azure DevOps でサービス プリンシパルの表示名またはアバターを変更することはできません。
  • サービス プリンシパルは、複数組織の課金が選択されている場合でも、追加される各組織のライセンスとしてカウントされます。

別の例では、Azure 関数内でユーザー割り当てマネージド ID を使用して Azure DevOps に接続する方法を示します。

サンプル アプリのコレクションでアプリ コードを見つけて、これらの例に従います。

サービス プリンシパルを使用して Azure DevOps REST API を呼び出し、ほとんどのアクションを実行できますが、次の操作には制限があります。

  • サービス プリンシパルを組織の所有者にしたり、組織を作成したりすることはできません。
  • サービス プリンシパルは、 個人用アクセス トークン (PAT)SSH キーなどのトークンを作成できません。 独自の Microsoft Entra ID トークンを生成でき、これらのトークンを使用して Azure DevOps REST API を呼び出すことができます。
  • サービス プリンシパルの Azure DevOps OAuth はサポートされていません。

Note

トークンの生成には、Azure DevOps に関連付けられているリソース URI ではなく、アプリケーション ID のみを使用できます。

よく寄せられる質問

全般

Q: PAT の代わりにサービス プリンシパルまたはマネージド ID を使用する必要があるのはなぜですか?

A: 多くのお客様は、既存の PAT (個人用アクセス トークン) を置き換えるためにサービス プリンシパルまたはマネージド ID を探しています。 このような PAT は、多くの場合、Azure DevOps リソースを使用してアプリケーションを認証するために使用されるサービス アカウント (共有チーム アカウント) に属します。 PAT は、頻繁に (最小 180 日) ごとに手間のかかってローテーションする必要があります。 PAT は単にベアラー トークンであり、ユーザーのユーザー名とパスワードを表すトークン文字列を意味するため、間違った人の手に簡単に落ちる可能性があるため、使用するのは非常に危険です。 Microsoft Entra トークンは 1 時間ごとに期限切れになり、新しいアクセス トークンを取得するには更新トークンで再生成する必要があります。これによって、リーク時の全体的なリスク要因が制限されます。

サービス プリンシパルを使用して個人用アクセス トークンを作成することはできません。

Q: サービス プリンシパルとマネージド ID のレート制限は何ですか?

A: 現時点では、サービス プリンシパルとマネージド ID には、ユーザーと同じ レート制限があります

Q: この機能を使用すると、コストは高くなりますか?

A: サービス プリンシパルとマネージド ID は、アクセス レベルに基づいて、ユーザーと同様に価格が設定されます。 重要な変更の 1 つは、サービス プリンシパルに対する "複数組織の課金" の処理方法に関連しています。 ユーザーは、組織の数に関係なく、1 つのライセンスとしてカウントされます。 サービス プリンシパルは、ユーザーのorganizationごとに 1 つのライセンスとしてカウントされます。 このシナリオは、標準の "ユーザー割り当てベースの課金" に似ています。

Q: Azure CLI でサービス プリンシパルまたはマネージド ID を使用できますか?

A:はい。 Azure CLI で PAT を要求する任意の場所で、Microsoft Entra ID アクセス トークンを受け入れることもできます。 CLI で認証するために Microsoft Entra トークンを渡す方法については、次の例を参照してください。

# 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

次に、Microsoft Entra トークン (Azure DevOps リソースの UUID) 499b84ac-1321-427f-aa17-267ca6975798を取得し、トークンとして Bearer ヘッダーに渡して Azure DevOps API を呼び出そうとします。

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

これで、通常どおりコマンドを使用 az cli できるようになりました。

Q: 別のテナントのマネージド ID をorganizationに追加できますか?

A: マネージド ID は、organizationが接続されているのと同じテナントからのみ追加できます。 ただし、すべてのリソースがある "リソース テナント" にマネージド ID を設定できる回避策があります。 その後、組織が接続されている "ターゲット テナント" のサービス プリンシパルによって使用されるようにすることができます。 回避策として、次の手順を実行します。

  1. リソース テナントのAzure portalでユーザー割り当てマネージド ID を作成します。
  2. 仮想マシンに接続 し、このマネージド ID を割り当てます
  3. キー コンテナーを作成し、証明書を生成します ("PEM" 型にすることはできません)。 この証明書を生成すると、同じ名前のシークレットも生成され、後で使用します。
  4. キー コンテナーから秘密キーを読み取ることができるように、マネージド ID へのアクセス権を付与します。 "Get/List" アクセス許可 ([シークレットのアクセス許可] の下) を使用してキー コンテナーにアクセス ポリシーを作成し、[プリンシパルの選択] でマネージド ID を検索します。
  5. 作成した証明書を "CER" 形式でダウンロードします。これにより、証明書のプライベート部分が含まれていないことが保証されます。
  6. ターゲット テナントに新しいアプリケーション登録を作成します。
  7. [証明書とシークレット] タブで、ダウンロードした証明書をこの新しいアプリケーションにアップロードします。
  8. このアプリケーションのサービス プリンシパルを Azure DevOps organizationに追加し、必要なアクセス許可を持つサービス プリンシパルを設定してください。
  9. マネージド ID 証明書を使用するこのサービス プリンシパルから Microsoft Entra アクセス トークンを取得するには、次のコード サンプルを参照してください。

Note

証明書は、常に定期的にローテーションする必要があります。

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

Q: サービス プリンシパルを使用してフィードに接続できますか?

A: はい。サービス プリンシパルを使用して、任意の Azure Artifacts フィードに接続できます。 次の例では、NuGet、npm、Maven 用の Microsoft Entra ID トークンを使用して接続する方法を示していますが、他のフィードの種類も機能する必要があります。

Microsoft Entra トークンを使用した NuGet プロジェクトのセットアップ
  1. .csproj または .sln ファイルと同じフォルダーにある nuget.config ファイルをプロジェクトに追加します。

    <?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. サービス プリンシパルの Microsoft Entra ID トークン を取得します。

  3. 次のコマンドを実行して資格情報で認証し、setapikey コマンドを使用してトークンを追加します。 このコマンドは、フィード ソースを nuget.config に追加します。

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

Microsoft Entra トークンを使用した npm プロジェクトのセットアップ

Note

vsts-npm-auth ツールは、Microsoft Entra アクセス トークンをサポートしていません。

  1. .npmrcと同じディレクトリに、 をプロジェクトに追加しますpackage.json

    registry=https://pkgs.dev.azure.com/Fabrikam/_packaging/FabrikamFeed/npm/registry/ 
    always-auth=true
    
  2. サービス プリンシパルまたはマネージド ID のアクセス トークンを取得します。

  3. このコードを に ${user.home}/.npmrc 追加し、プレースホルダー [AAD_SERVICE_PRINCIPAL_ACCESS_TOKEN] を前の手順のアクセス トークンに置き換えます。

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

Microsoft Entra トークンを使用した Maven プロジェクトのセットアップ
  1. リポジトリを セクションと <distributionManagement> セクションの<repositories>両方pom.xmlに追加します。

    <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. サービス プリンシパルまたはマネージド ID のアクセス トークンを取得します。

  3. ${user.home}/.m2ファイルをsettings.xml追加または編集し、プレースホルダー[AAD_SERVICE_PRINCIPAL_ACCESS_TOKEN]を前の手順のアクセス トークンに置き換えます。

    <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

Q: サービス プリンシパルを使用して Visual Studio Marketplace に拡張機能を発行できますか?

A:はい。 手順は次のとおりです。

  1. サービス プリンシパルをメンバーとしてパブリッシャー アカウントに追加します。 プロファイル - 取得を使用して、プロファイルからサービス プリンシパルの ID を取得できます。 その後、前の手順の ID を使用して、 サービス プリンシパルをメンバーとして パブリッシャーに追加できます。

  2. SP を使用して TFX CLI を使用して拡張機能を発行します。 SP アクセス トークンを使用するには、次の TFX CLI コマンドを実行します。

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

Pipelines

Q: サービス接続内でマネージド ID を使用できますか。 サービス接続でサービス プリンシパルのシークレットをより簡単にローテーションするにはどうすればよいですか? サービス接続にシークレットを格納しないようにすることはできますか?

OpenID Connect プロトコルを使用してワークロード ID フェデレーションをAzure サポートします。これにより、Microsoft Entra ID のフェデレーション資格情報を使用して、サービス プリンシパルまたはマネージド ID によってサポートされるシークレットのないサービス接続を Azure Pipelines に作成できます。 パイプラインは、実行の一環として、独自の内部トークンを Microsoft Entra トークンと交換できるため、Azure リソースにアクセスできます。 実装後、このメカニズムは、現在存在する他の種類の Azure サービス接続よりも製品で推奨されます。 このメカニズムを使用して、他の OIDC 準拠のサービス プロバイダーとのシークレットのない展開を設定することもできます。 このメカニズムはプレビュー段階です。

Repos

Q: リポジトリのクローンなど、サービス プリンシパルを使用して Git 操作を行うことができますか?

A: POWERShell スクリプトでリポジトリを複製するために PAT ではなく、サービス プリンシパルの Microsoft Entra ID トークンを渡す方法の次の例を参照してください。

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

ヒント

トークンの安全性を高めるために、資格情報マネージャーを使用して、毎回資格情報を入力する必要がないようにします。 環境変数が変更された場合は、GIT Credential Manager を使用することをお勧めします。これは、環境変数が変更された場合に、AT ではなく Microsoft Entra トークン (つまり、Microsoft Identity OAuth トークン) を受け入れることが可能です。

Azure CLI からアクセス トークンを取得して git fetch を呼び出す方法に関する便利なヒント:

  1. リポジトリの Git 構成を開きます。
git config -e
  1. 次の行を追加します。Azure DevOps リソースの UUID は 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. 次を使用して動作することをテストします。
GIT_TRACE=1 GCM_TRACE=1 GIT_CURL_VERBOSE=1 git fetch

潜在的なエラー

オブジェクト ID '{provided objectId}' を使用してサービス プリンシパルを作成できませんでした

organizationに接続されているテナントに を持つprovided objectIdサービス プリンシパルはありません。 一般的な理由の 1 つは、サービス プリンシパルのオブジェクト ID ではなく、アプリ登録のオブジェクト ID を渡すことです。 サービス プリンシパルは、特定のテナントのアプリケーションを表すオブジェクトであり、アプリケーション自体ではないことに注意してください。 は service principal object ID 、テナントの [エンタープライズ アプリケーション] ページにあります。 アプリケーションの名前を検索し、返される "エンタープライズ アプリケーション" の結果を選択します。 この結果は、サービス プリンシパル/エンタープライズ アプリケーションのページであり、このページにあるオブジェクト ID を使用して、Azure DevOps でサービス プリンシパルを作成できます。

アクセスが拒否されました: {ID of the caller identity} には、このアクションを実行するために、リソースユーザーに対する次のアクセス許可が必要です: [ユーザーの追加]

このエラーは、次のいずれかの理由が原因である可能性があります。

  • organization、プロジェクト コレクション管理者、またはプロジェクトまたはチーム管理者の所有者ではありません。
  • あなたはプロジェクト管理者またはチーム管理者ですが、[チーム管理者とプロジェクト管理者に新しいユーザーの招待を許可する] ポリシーは無効になっています。
  • 新しいユーザーを招待できるプロジェクトまたはチーム管理者ですが、新しいユーザーを招待するときにライセンスを割り当てようとしています。 プロジェクト管理者またはチーム管理者は、新しいユーザーにライセンスを割り当てることはできません。 新しい招待されたユーザーは、 新しいユーザーの既定のアクセス レベルで追加されます。 ライセンス アクセス レベルを変更するには、PCA に問い合わせてください。

Azure DevOps Graph List API は、organizationにサービス プリンシパルがあることがわかっている場合でも、空のリストを返します

返すユーザーのページが増えても、Azure DevOps Graph List API は空のリストを返す可能性があります。 を continuationToken 使用してリストを反復処理し、最終的にサービス プリンシパルが返されるページを見つけることができます。 continuationTokenが返された場合は、API を通じてより多くの結果が得られます。 このロジックを改善する計画はありますが、現時点では、最初の X の結果が空に戻る可能性があります。

TF401444: Web ブラウザーで {tenantId'tenantId\servicePrincipalObjectId'} として少なくとも 1 回サインインして、サービスへのアクセスを有効にします。

サービス プリンシパルが組織に招待されていない場合は、次のエラーが発生する可能性があります。 サービス プリンシパルが適切な組織に追加され、必要なリソースにアクセスするために必要なすべてのアクセス許可があることを確認します。