Azure：Microsoft Entra IDの「エンタープライズアプリケーション」と「アプリの登録」の違いでハマった話

◆ Live配信スケジュール ◆
サイオステクノロジーでは、Microsoft MVPの武井による「わかりみの深いシリーズ」など、定期的なLive配信を行っています。
⇒ 詳細スケジュールはこちらから
⇒ 見逃してしまった方はYoutubeチャンネルをご覧ください

【5/21開催】Azure OpenAI ServiceによるRAG実装ガイドを公開しました
生成AIを活用したユースケースで最も一番熱いと言われているRAGの実装ガイドを公開しました。そのガイドの紹介をおこなうイベントです!!
https://tech-lab.connpass.com/event/315703/

1 はじめに
2 作業内容
3 権限の確認
4 Pipelinesによるデプロイの流れ
5 アプリケーションオブジェクトとサービスプリンシパル
6 解決方法
7 さいごに

はじめに

こんにちは！中途入社のなーがです。前回はAzure Service Local Fabric Clusterの環境構築方法についての内容でしたが、今回はMicrosoft Entra IDの「エンタープライズアプリケーション」と「アプリの登録」の違いでハマった話について書こうと思います。

解決方法だけ知りたい方は、こちらから確認できます。

作業内容

あるアプリケーションのインフラ環境を変更するために、新規構築したService Fabricクラスターへデプロイ先を切り替えようとしました。Azure上のService FabricクラスターへのデプロイはAzure Pipelinesで行っており、Azure PipelinesからService Fabricへの接続を行うための認証用Entra IDアカウントを旧クラスターで使用していたものから変更しました。

その後、デプロイを行ったのですが失敗してしまいました。

Pipelinesのリリースログを確認したところ、以下のエラーが発生していました。

ExceptionMessage: Exception calling "GetResult" with "0" argument(s): "AADSTS50105: Your administrator has configured the application XXXXXXXXXX_xxxxx ('XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX') to block users unless they are specifically granted ('assigned') access to the application.  The signed in user '{EmailHidden}' is blocked because they are not a direct member of a group with access, nor had access directly assigned by an administrator. Please contact your administrator to assign access to this application.

エラーID：AADSTS50105より、認証アカウントがサービスプリンシパルへの権限を持っていないことが分かりました。

権限の確認

そこで、権限を確認するために、Azure Portalの「アプリの登録」にアクセスしました。

すべてのサービス > カテゴリ：ID > アプリの登録 > 「登録したいアプリケーション」> 所有者

すると、認証アカウントは所有者になっています。なぜ「アプリの登録」では所有者となっているのにも関わらず、権限エラーが発生したのでしょうか。

Pipelinesによるデプロイの流れ

まず、Pipelinesを使用したService Fabricのデプロイについて確認したいと思います。デプロイの流れは以下の公式ドキュメントにある通りです。

Pipelinesはデプロイ全体のオーケストレーションを行っており、CI/CDの実処理はPipelinesエージェントが実行します。その際に⑤の段階で以下の処理が行われます。

PipelinesエージェントがService Connectionで指定されたEntra IDアカウントでEntra ID認証する
認証されたEntraIDアカウントがサービスプリンシパルを使用してService Fabricにアクセスする

アプリケーションオブジェクトとサービスプリンシパル

次に、Entra IDについてみていきます。Entra IDでは「アプリケーションオブジェクト」と「サービスプリンシパル」という認証の際に必須となる２つの概念があります。ここでは、これらの違いについて確認したいと思います。

公式ドキュメントによると、それぞれ以下のように説明されています。

アプリケーションオブジェクト

1 つ以上のサービスプリンシパルオブジェクトを作成するためのテンプレートまたはブループリントとして使用されます。
アプリケーションオブジェクトは、アプリケーションの 3 つの側面を記述します。
サービスがアプリケーションにアクセスするためにトークンを発行する方法
アプリケーションがアクセスする必要があるリソース
アプリケーションが実行できるアクション

サービスプリンシパル

アプリケーションオブジェクトから作成された具体的なインスタンスであり、そのアプリケーションオブジェクトから特定のプロパティを継承します。サービスプリンシパルは、アプリケーションが使用される各テナントに作成され、グローバルに一意のアプリオブジェクトを参照します。サービスプリンシパルオブジェクトは、特定のテナントでアプリが実際に実行できること、アプリにアクセスできるユーザー、およびアプリがアクセスできるリソースを定義します。

つまり、「アプリケーションオブジェクトはサービスプリンシパルのひな形（テンプレート）、サービスプリンシパルはアプリケーションオブジェクトを基に作られたIDのようなもの」ということになります。オブジェクト指向プログラミングの経験がある方であれば、アプリケーションオブジェクトはクラス、サービスプリンシパルはインスタンスに該当するといった方がイメージしやすいと思います。

複数のクライアント（Entra ID）にまたがる場合はマルチテナントアプリケーションとなるのですが、詳しくは武井さんの記事で分かりやすくまとめられているのでこちらを見てみてください。

Azure Portalでは、アプリケーションオブジェクトは「アプリの登録」、サービスプリンシパルは「エンタープライズアプリケーション」で設定されています。

つまり、上記ではサービスプリンシパルではなくアプリケーションオブジェクトの設定を確認していたことになります。また、リソースにアクセスするためにはアプリケーションオブジェクトで作成した適切なアプリロールが、サービスプリンシパルで自分のアカウントに割り当てられている必要があります。

では、サービスプリンシパルで設定されているロールの割り当てを確認します。

すべてのサービス > カテゴリ：ID > Microsoft Entra ID > エンタープライズアプリケーション > 「登録したいアプリケーション」> ユーザーとグループ

解決方法

①権限ある人に変更してもらう

②自身のアカウントをサービスプリンシパルに追加してもらう

解決方法としては上記の2つがありますが、今回は自身で設定できるようにするために文章のみですが②の方法について書こうと思います。公式ドキュメントより、以下の手順で行います。こちらでは画像付きでより詳しく説明されています。

「ユーザーまたはグループの追加」をクリック
「割り当ての追加」画面が表示されるので、「選択されていません」をクリック
画面右側に「ユーザーとグループ」画面が表示されるので、アプリケーションに割り当てるユーザーまたはグループを検索して選択する
「選択」をクリック
「割り当て」をクリック

さいごに

今回はMicrosoft Entra IDの「エンタープライズアプリケーション」と「アプリの登録」の違いでハマった話について書きました。エラーの発生原因としては、サービスプリンシパルではなくアプリケーションオブジェクトの設定を確認していたこと、リソースにアクセスするために必要なロールが割り当てられていなかったためです。サービスプリンシパルやロールの設定はクラウドを扱う際に重要な権限周りの内容になるので、少しずつ使いこなせるようになろうと思います。