Azure DevOps サービス |Azure DevOps Server |Azure DevOps Server 2022
この記事では、Azure Resource Manager (ARM) サービス接続の作成時に発生する可能性がある問題を解決するのに役立つ一般的なトラブルシューティング シナリオについて説明します。 サービス接続の作成、編集、セキュリティ保護の方法については、「サービス接続の管理」を参照してください。 ワークロード ID 関連の問題を修正する方法についてはAzure Resource Managerワークロード ID サービス接続を参照してください。
Important
Azure Resource Managerサービス接続では、Azure リソースに永続的にアクセスできます。 不要な永続的なアクセスを減らすために、Azure Pipelinesは、100 日間の非アクティブ状態の後にサービス接続を自動的に無効にします。 長時間非アクティブな状態の後にデプロイが失敗する場合は、認証の問題のトラブルシューティング、シークレットのローテーション、接続の再作成を行う前に、サービス接続が無効になっているかどうかを確認します。
この記事では、"tenant" と "directory" という用語を重複する可能性のある方法で使用します。 テナントは、組織がクラウド サービスのすべての ID とアクセス制御を受け取って管理する、Microsoft Entra IDの専用の分離されたインスタンスです。 ディレクトリは、リソースへのアクセスを管理するために使用されるユーザー、グループ、アプリケーションなどのオブジェクトを保持する、そのテナント内のコンテナーです。
Important
Azure Resource Manager サービス接続で、ワークロード ID フェデレーションに非推奨のAzure DevOps発行者が使用されている場合、Azure DevOpsは、サービス接続または接続を使用するパイプライン エクスペリエンスに警告を表示します。 この警告は、サービス接続をMicrosoft Entra発行者に変換する必要があることを意味します。 この非推奨は、シングルテナント Microsoft Entra アプリケーションまたはマネージド ID を使用Azureパブリック クラウドの対象となるサービス接続にのみ適用されます。 非パブリック クラウドを対象とするサービス接続と、マルチテナント アプリケーションを使用するサービス接続は、この非推奨の対象範囲外です。 詳細については、 サービス接続の変換 を参照してください。
Azure Resource Manager サービス接続を作成するとどうなりますか
Azure Resource Manager サービス接続でAzureに接続するには、複数の認証オプションがあります。 アプリの登録またはマネージドID のいずれかでワークロード ID フェデレーションを使用することをお勧めします。
サービス接続の作成プロセスが成功すると、Azure DevOpsはMicrosoft Entra テナントでこれらの手順を自動的に実行します。 このプロセス中にエラーが発生した場合は、 以下のトラブルシューティング シナリオを参照してください。
新しいAzure Resource Manager サービス接続を保存すると、Azure DevOpsは次のアクションを実行します。
- 選択したサブスクリプションのMicrosoft Entra テナントに接続します。
- ユーザーの代わりにEntra IDでアプリケーションを作成します。
- 選択したサブスクリプションの共同作成者としてアプリケーションを割り当てます。
- このアプリケーションの詳細を使用して、Azure Resource Manager サービス接続を作成します。
注記
サービス接続を作成するには、プロジェクト設定 (プロジェクト設定>サービス接続>その他の操作>セキュリティ) でエンドポイント作成者グループ内の作成者または管理者の役割を割り当てられている必要があります。 Project共同作成者は、既定でこのグループに追加されます。
ワークロード ID フェデレーション シナリオのトラブルシューティング
サービス接続を作成、更新、または使用すると、次の問題が発生する可能性があります。
- 非アクティブな後にサービス接続が無効になりました
- パイプラインに、非推奨となった Azure DevOps 発行元の警告が表示される
- 自動変換が失敗する
- サービス接続を編集することはできますが、フェデレーション資格情報を追加することはできません
- フェデレーション資格情報の値が一致しない
- アプリの登録またはマネージド ID を所有しているユーザーがわからない
- サービス接続でマルチテナント アプリを使用する
非アクティブな後にサービス接続が無効になりました
Azure Pipelinesは、非アクティブ状態が 100 日後にサービス接続を自動的に無効にし始めます。 無効なサービス接続に依存するタスクは、Azureに対する認証を行う前に失敗する可能性があります。
この問題を解決するには:
- Azure DevOpsで、Project設定>Service 接続に移動します。
- 失敗したパイプラインによって使用されるAzure Resource Manager サービス接続を開きます。
- [使用状況履歴] タブを確認して、接続が最後に使用された日時を確認します。
- 接続がまだ必要であり、ターゲット Azure リソースへのアクセス権を引き続き持つ必要があることを確認します。
- その他のアクション>有効化 を選択します。
- パイプラインを再実行します。
パイプラインに、非推奨の Azure DevOps 発行元に関する警告が表示される
パイプラインの警告は、パイプラインが、非推奨のAzure DevOps発行者を引き続き使用するワークロード ID フェデレーション サービス接続を使用していることを意味します。
警告を解決するには:
- 警告からリンクされたサービス接続を開きます。
- Microsoft Entra発行者を使用するようにサービス接続を変換します。
- 自動変換が完了しない場合は、「Resource Managerワークロード ID サービス接続の設定」の手動変換手順に従います。
- サービス接続が変換された後、パイプラインをもう一度実行します。
自動変換が失敗する
Azure DevOps最初にサービス接続を自動的に変換しようとします。 関連付けられているアプリの登録またはマネージド ID Azure DevOps更新できない場合、自動変換が失敗する可能性があります。
この問題を解決するには:
- Azure DevOpsにサービス接続管理者またはエンドポイント管理者のアクセス許可があることを確認します。
- 関連付けられているアプリの登録またはマネージド ID にフェデレーション資格情報を追加できることを、自分または ID 所有者が確認します。
- Azure DevOpsに表示されている発行者とサブジェクトの識別子の値をコピーします。
- AzureまたはMicrosoft Entraの関連付けられている ID にフェデレーション資格情報を追加します。
- Azure DevOps サービス接続に戻り、セットアップを完了します。
サービス接続を編集することはできますが、フェデレーション資格情報を追加することはできません
Azure DevOpsサービス接続のアクセス許可では、AzureまたはMicrosoft Entraの ID を更新するアクセス許可は付与されません。 アプリの登録またはマネージド ID は、別のユーザーまたはチームが所有している可能性があります。
この問題を解決するには、Azure管理者、アプリ登録所有者、またはマネージド ID 所有者にフェデレーション資格情報の追加を依頼します。 Azure DevOps サービス接続から生成された発行者とサブジェクト識別子の値を指定します。
フェデレーション資格情報の値が一致しない
ワークロード ID サービス接続は、フェデレーション資格情報の値の一致に依存します。 AzureまたはMicrosoft Entraの発行者またはサブジェクト識別子がAzure DevOpsによって生成された値と一致しない場合、認証が失敗する可能性があります。
この問題を解決するには:
- Azure DevOpsでサービス接続を開きます。
- 生成された 発行者 と サブジェクト識別子 の値をコピーします。
- 関連付けられているアプリの登録またはマネージド ID をAzureまたはMicrosoft Entraで開きます。
- フェデレーション資格情報の値を比較します。
- 値が一致するように、フェデレーション資格情報を更新または再作成します。
アプリの登録またはマネージド ID を所有しているユーザーがわからない
一部の組織では、Azure DevOps管理をAzureまたはMicrosoft Entra ID 管理から分離します。 現在のサービス接続管理者が ID を所有していない場合、管理者は変換を完了できない可能性があります。
この問題を解決するには:
- アプリの登録については、Microsoft Entraでアプリ登録の所有者を確認します。
- マネージド ID の場合は、マネージド ID またはそのリソース グループにロールが割り当てられているユーザーを確認します。
- 所有者を特定できない場合は、テナント管理者またはサブスクリプション管理者に問い合わせてください。
サービス接続でマルチテナント アプリを使用する
マルチテナント アプリのシナリオは、この非推奨の対象範囲外です。 Azure DevOps発行者は、マルチテナント アプリケーションを使用するサービス接続で引き続きサポートされます。
ユーザーはディレクトリ内のゲストアクセス許可のみを持っている
このエラーは、Azure DevOpsがアプリケーションを作成し、Microsoft Entra IDでアクセス許可を割り当てようとしたときに、サービス接続の自動作成プロセス中に発生します (
この問題を解決するには、次の手順を実行します。
管理者アカウントを使用してAzure ポータルにサインインします。 このアカウントは、所有者またはユーザー アカウント管理者である必要があります。
左側のナビゲーション バーで Microsoft Entra ID を選択します。
ユーザー サブスクリプションに対応する適切なディレクトリを編集していることを確認します。 そうでない場合は、[ ディレクトリの切り替え ] を選択し、必要に応じて適切な資格情報でサインインします。
[管理] セクションから [ユーザー] を選択します。
[ユーザー設定] を選択します。
[外部ユーザー] セクションから [外部コラボレーションの設定を管理します] を選択します。
[Guest user permissions are limited] (ゲスト ユーザーのアクセス許可が制限されます) オプションを [いいえ] に変更します。
または、ユーザーに管理者レベルのアクセス許可を付与する準備ができたら、ユーザーを管理者ロールのメンバーにすることができます。 次の手順を実行します。
警告
グローバル管理者ロールにユーザーを割り当てると、Microsoft Entra組織内のすべての管理設定を読み取って変更できます。 ベスト プラクティスとして、組織内でこのロールを割り当てる人は 5 人未満にすることをが推奨されます。
管理者アカウントを使用してAzure ポータルにサインインします。 このアカウントは、所有者またはユーザー アカウント管理者である必要があります。
左側のナビゲーション ウィンドウから Microsoft Entra ID を選択します。
ユーザー サブスクリプションに対応する適切なディレクトリを編集していることを確認します。 そうでない場合は、[ ディレクトリの切り替え ] を選択し、必要に応じて適切な資格情報でサインインします。
[管理] セクションから [ユーザー] を選択します。
検索ボックスを使用して、管理するユーザーを見つけます。
[管理] セクションで、[ディレクトリ ロール] を選択し、ロールを変更します。 完了したら、 [保存] を選択します。
通常、変更をグローバルに適用するまでに 15 分から 20 分かかります。 その後、ユーザーはサービス接続の再作成を試すことができます。
ユーザーは、ディレクトリにアプリケーションを追加する権限がありません
このエラーは、Azure DevOpsがユーザーの代わりにMicrosoft Entra IDでアプリケーションを作成しようとしたときに、自動サービス接続の作成プロセス中に発生します (
この問題を解決するには、次の手順を実行します。
左側のナビゲーション ウィンドウで Microsoft Entra ID を選択します。
ユーザー サブスクリプションに対応する適切なディレクトリを編集していることを確認します。 そうでない場合は、[ ディレクトリの切り替え ] を選択し、必要に応じて適切な資格情報でサインインします。
[ ユーザー] を選択し、[ ユーザー設定] を選択します。
アプリの登録で、Users can register applications オプションを Yes に変更します。
Entra IDで必要なアクセス許可を既に持っている既存のユーザーでサービス プリンシパルを作成することもできます。 詳細については、「既存のサービス プリンシパルを使用してAzure Resource Managerサービス接続を作成するを参照してください。
アクセス トークンの取得に失敗したか、有効な更新トークンが見つかりませんでした
これらのエラーは、通常、セッションの有効期限が切れると発生します。
このような問題を解決するには:
Azure DevOpsからサインアウトします。
InPrivate または incognito ブラウザー ウィンドウを開き、Azure DevOps に移動します。
適切な資格情報でサインインします。
組織とプロジェクトを選択します。
サービス接続をもう一度作成してみてください。 詳細な手順については、「 サービス接続の管理」を参照してください。
新しいサービス接続を編集または作成しようとしたときに、アクティブなAzure サブスクリプションが表示されない
このエラーは、通常、複数のEntra ID テナントの一部である場合に発生します。
この問題を解決するには、次の手順を実行します。
VS プロファイルに移動します。
テナントが複数あるかどうかを確認します。
各テナントを選択し、再認証します。
サービス接続を作成してから、サブスクリプションが読み込まれるかどうかを確認します。
コントリビューターロールの割り当てに失敗しました
このエラーは、Azure DevOpsがアプリケーションをサブスクリプションの共同作成者として割り当てようとしたときに、サービス接続の自動作成プロセス中に発生します (
この問題を解決するには、サブスクリプション管理者にMicrosoft Entra IDで適切なロールを割り当てるように依頼します。
サービス接続の作成時にサブスクリプションがリスト表示されない
この問題には複数の原因が考えられます。
さまざまなAzure サブスクリプション のドロップダウン メニューに表示される最大 50 個のAzure サブスクリプション (課金、サービス接続など): サービス接続を設定していて、50 を超えるAzure サブスクリプションがある場合、一部のサブスクリプションは一覧表示されません。 この状況の場合は、次の手順を実行します。
Azure サブスクリプションのMicrosoft Entra インスタンスに、新しいネイティブ Microsoft Entra ユーザーを作成します。
課金を設定したり、サービス接続を作成したりするための適切なアクセス許可が付与されるように、Microsoft Entra ユーザーを設定します。 詳細については、「
Azure DevOps を参照してください。Microsoft Entra ユーザーを Stakeholder アクセス レベルでAzure DevOps組織に追加し、それを Project コレクション管理者 グループ (課金用) に追加するか、ユーザーがサービス接続を作成するための十分なアクセス許可をチーム Projectに持っていることを確認します。
新しいユーザー資格情報でAzure DevOpsにサインインし、課金を設定します。 一覧に表示されるAzureサブスクリプションは 1 つだけです。
Azure DevOps Services: Azure Resource Manager (ARM) サービス接続の作成時にAzure サブスクリプションが表示されない場合は、Azure DevOps Services にキャッシュされた古いユーザー トークンが原因である可能性があります。 このシナリオは、Azureサブスクリプションの一覧画面に、ユーザー トークンが古いことを示すエラーや警告メッセージが表示されないため、すぐには明らかではありません。 この問題を解決するには、次の手順を実行して、Azure DevOps Services でキャッシュされたユーザー トークンを手動で更新します。- Azure DevOps サービスからサインアウトし、もう一度サインインします。 このアクションにより、ユーザー トークンを更新できます。
- ブラウザーのキャッシュと Cookie をクリアして、以前のトークンが確実に削除されるようにします。
- Azure DevOps ポータルからサービス接続に移動し、Azureへの接続を再認証します。 この手順では、新しいトークンの使用をAzure DevOpsに求めます。
不適切なサポート アカウントの種類の設定: この問題を解決するには、 サポートされているアカウントの種類 の設定を変更し、アプリケーションを使用できるユーザーを定義します。 次の手順に従います。
Azure ポータルにサインインします。
複数のテナントにアクセスできる場合は、トップ メニューにある [ディレクトリとサブスクリプション] フィルターを使用して、アプリケーションを登録するテナントを選択します。
Azureポータルでディレクトリとサブスクリプションのアイコンを示すスクリーンショット 左側のウィンドウから Microsoft Entra ID を選択します。
アプリの登録 を選択します。
登録アプリケーションの一覧からアプリケーションを選択します。
[認証] で、[Supported account types] (サポートされているアカウントの種類) を選択します。
[Supported account types] (サポートされているアカウントの種類) の [Who can use this application or access this API?] (このアプリケーションを使用できるユーザーまたはこの API にアクセスできるユーザー) で、[Accounts in any organizational directory] (任意の組織のディレクトリ内のアカウント) を選択します。
完了したら、 [保存] を選択します。
サービス プリンシパルまたはシークレットの有効期限が切れている
Azure DevOpsにより自動的に作成されたサービス プリンシパルまたはシークレットは、有効期限が切れるため、更新が必要です。 トークンの更新で問題が発生した場合は、「 アクセス トークンの取得に失敗したか、有効な更新トークンが見つかりませんでした」を参照してください。 シークレットを更新する必要を回避するには、 Azure Resource Manager とのワークロード ID フェデレーションを使用します。
トークンの有効期限が切れると、次のいずれかのエラー メッセージが表示されることがあります。
AADSTS7000215: Invalid client secret is providedAADSTS7000222: The provided client secret keys for app '***' are expiredInvalid client id or client secret
自動作成されたサービス プリンシパルまたはシークレットのアクセス トークンを更新するには:
Project settings>Service connections に移動し、更新するサービス接続を選択します。
シークレットをローテーションを選択します。
サービス プリンシパルまたはシークレットのトークンが、さらに 3 か月更新されました。
注記
この操作は、サービス プリンシパルのトークンの有効期限が切れていない場合でも使用できます。
操作を実行しているユーザーが、サービス プリンシパルに登録されているアプリのシークレットを更新するため、サブスクリプションとMicrosoft Entra IDに対する適切なアクセス許可を持っていることを確認します。 詳細については、「
サービス プリンシパル クライアント ID を使用した JWT の取得に失敗する
この問題は、有効期限が切れたシークレットまたはその他の問題があるサービス接続をMicrosoft Entra ID レベルで保存しようとすると発生します。
この状態のサービス接続は、Project 設定>Service 接続の下に表示されていても、パイプライン タスクのドロップダウン (Azure App Service Deploy や Azure PowerShell など) にも表示されない場合があります。
これは、基になるサービス プリンシパルが削除されたか、接続の isReady 状態が false場合に発生します。
この問題を解決するには、次の手順を実行します。
- Project設定>Service connections に移動し、変更するサービス接続を選択します。
- [ 編集] を選択し、[ 確認 ] を選択して接続の状態を確認します。
-
AADSTS700016エラー ("識別子を持つアプリケーションがディレクトリに見つかりませんでした") で検証が失敗した場合、サービス プリンシパルは削除されました。 新しいサービス接続を作成するか、手動接続の場合は、新しいサービス プリンシパルの詳細で接続を更新します。 - 検証が成功した場合は、[ 保存] を選択してサービス接続を保存します。
注記
Failed to obtain the Json Web Token(JWT) using service principal client ID. Exception message: AADSTS7000112: Application is disabled. などのエラーが発生した場合は、Microsoft Entra ID チームと協力して、サービス プリンシパルにリンクされているエンタープライズ アプリケーションのユーザーがサインインできるようにオプションが無効になっていないことを確認します。
Azureサブスクリプションが前のタスク出力から渡されない
リリース パイプラインにAzure サブスクリプションを動的に設定し、前のタスクの出力変数を使用する場合、この問題が発生する可能性があります。
この問題を解決するには、パイプラインの変数セクション内で値が定義されていることを確認します。 そうすることで、この変数はパイプラインのタスク間で渡せるようになります。
どの認証メカニズムがサポートされていますか? マネージド ID はどのように動作しますか?
Azure Resource Manager サービス接続は、サービス プリンシパル認証 (SPA) またはマネージド ID 認証を使用して、Azure サブスクリプションに接続できます。
Azure Resource Manager サービス接続は、次を使用して、Azure サブスクリプション、管理グループ、または機械学習ワークスペースに接続できます。
- アプリの登録 (推奨): ワークロード ID フェデレーションまたはシークレットを使用して接続を認証します。
- マネージド ID: Azure リソースのマネージド ID は、Microsoft Entra IDで自動的に管理される ID をAzureサービスに提供します。 エージェント割り当てマネージド ID を使用することもできます。
認証方法としてマネージド ID を使用してサービス接続を設定すると、プロセスによって新しいマネージド ID は作成されません。 サービス接続を確立するだけです。 この認証方法を正しく機能させるには、特定の条件を満たす必要があります。 具体的には、マネージド ID が選択された認証方法であるため、使用している仮想マシンにはシステム割り当て ID が必要です。 さらに、この仮想マシンは、ワークフローを完全に実行するためにパイプライン内でセルフホステッド エージェントとして機能する必要があります。これにより、パイプラインはサービス接続を介して変更をデプロイできます。 VM 上のシステム割り当て ID は、同じ VM がパイプラインでエージェントとして機能し、認証を有効にしていることを特定します。 このセットアップにより、既存のマネージド ID を活用できます。
仮想マシンのマネージド ID については、「ロールの割り当て」を参照してください。
注記
Microsoftホストされるエージェントは、マネージド ID をサポートしていません。 このシナリオでは、Azure VM でセルフホステッド エージェントを設定し、その VM のマネージド ID を構成する必要があります。
パイプライン タスクの実行時に AuthorizationFailed エラーが発生する
Azure リソースに対してパイプライン タスクを実行すると、次のエラーが表示されることがあります。
AuthorizationFailed: The client '<ClientName>' with object id '<ObjectId>' does not have authorization
to perform action '<ActionName>' over scope '/subscriptions/<SubscriptionId>/...'
エラー メッセージのクライアント ID とオブジェクト ID は、サービス接続をバックアップするサービス プリンシパルを参照します。
この問題を解決するには、次の手順を実行します。
- Azure ポータルで、エラーのスコープで参照されているリソースまたはリソース グループに移動します。
- [アクセス制御 (IAM)]>[ロールの割り当て] を選択します。
- エラーに示されているサービス プリンシパルに、必要なアクション ( 共同作成者 ロールやカスタム ロールなど) が含まれていることを確認します。
- ロールの割り当てが見つからない場合は、[ 追加>ロールの割り当てを追加 して、サービス プリンシパルに適切なロールを割り当てます。
- ロールの割り当てが反映されるまで数分待ってから、パイプラインを再試行します。
Azure RBAC の詳細については、「Azure組み込みロールを参照してください。
パイプラインに対して承認されていないサービス接続
パイプラインを実行すると、次のエラーが表示されることがあります。
Resource not authorized. You need to authorize the resource before it can be used.
このエラーは、サービス接続を使用しようとしているパイプラインへのアクセス許可がサービス接続に付与されていない場合に発生します。
この問題を解決するには、次の手順を実行します。
- Project settings>Service connections に移動します。
- パイプラインが使用するサービス接続を選択します。
- その他のアクション (...) を選択>セキュリティ。
- [ パイプラインのアクセス許可] で、 + を選択し、アクセスが必要なパイプラインを追加します。
または、すべてのパイプラインへのアクセスを許可することもできます。 これはお勧めしません。 すべてのパイプラインへのアクセスを許可するには:
サービス接続のセキュリティ ページで、[その他のアクション] >[アクセスを開く] を選択します。
注記
オープン アクセスを使用すると、プロジェクト内のすべてのパイプラインでサービス接続を使用できます。 より厳密な制御を行う場合は、特定のパイプラインにのみアクセス権を付与します。
詳細については、「 サービス接続のセキュリティ」を参照してください。
Azureのサブスクリプションのアクセス許可がないサービス プリンシパルを作成する
Azure サブスクリプションまたは Microsoft Entra ID に必要なアクセス許可を持っておらず、自動方法でサービス接続を作成できない場合は、管理者にサービス プリンシパルを手動で作成してもらうよう依頼してください。 その後、Azure DevOpsにサービス プリンシパルの詳細を入力して、サービス接続を作成できます。
- 必要なAzureサブスクリプションとMicrosoft Entra IDアクセス許可を持つユーザーに依頼して、Microsoft Entra IDでサービス プリンシパルを作成し、サブスクリプションに適切なロールを割り当ててもらってください。
- 管理者から、 アプリケーション (クライアント) ID、 ディレクトリ (テナント) ID、 サブスクリプション ID、 クライアント シークレット または 証明書の詳細を取得します。
- Azure DevOpsで、プロジェクト設定>サービス接続>新しいサービス接続>Azure Resource Manager>サービス プリンシパル (手動)に移動します。
- 管理者から提供された詳細を入力し、接続を保存します。
詳細については、「既存のサービス プリンシパルを使用してAzure Resource Managerサービス接続を作成するを参照してください。
サービス接続を削除できません
Azure Resource Manager サービス接続を削除しようとすると、"Azureアクセス許可の削除に失敗しました" や "Microsoft Entra IDからサービス プリンシパルを削除できませんでした" などのエラーが表示されることがあります。場合によっては、エラーが表示されない場合でも、接続は一覧に残ります。
この問題を解決するには、次の手順を実行します。
サービス接続を選択し、[ 削除] を選択します。 Azureアクセス許可またはサービス プリンシパルに関するエラー メッセージが表示された場合でも、接続はAzure DevOpsから削除する必要があります。
削除に失敗した場合は、 サービス エンドポイント REST API を使用して直接削除します。 基になるサービス プリンシパルのクリーンアップをスキップするには、
deepパラメーターをfalseに設定します。DELETE https://dev.azure.com/{organization}/{project}/_apis/serviceendpoint/endpoints/{endpointId}?deep=false&api-version=7.1接続を削除した後、Azure ポータルの アプリの登録 から関連付けられているサービス プリンシパルを手動で削除または更新します。
ヒント
エラー メッセージのトラブルシューティングについては、Copilot に問い合わせてください。 詳細については、「 AI を使用してAzure DevOpsサービス接続エラーのトラブルシューティングを行うを参照してください。
AI を使用してAzure DevOps サービス接続エラーのトラブルシューティングを行う
Copilot Chat 用のプロンプト例は、Copilot がエラーコードやエラーメッセージのトラブルシューティングを行う際に役立ちます。 このプロンプトをコピーしてCopilot Chatに貼り付け、プレースホルダーを特定のエラー メッセージに置き換えます。
I'm getting this Azure DevOps service connection error: [PASTE YOUR ERROR MESSAGE HERE]
Can you help me troubleshoot this issue? Please provide step-by-step instructions to:
1. Identify the root cause
2. Fix the configuration in Azure or Entra ID
3. Verify the solution works
Context: This is for an Azure Resource Manager service connection in Azure DevOps.