Power Automate の所有者をサービスプリンシパルに変更する
はじめに
Power Automate は通常ユーザーを所有者としますが、サービスプリンシパルを所有者とすることもできます。
所有者をサービスプリンシパルとすることで以下のメリットを享受することができます。
- 個々のユーザーの退職や役割変更、ライセンス変更に影響されずにフロー実行を継続することができる
- 組織が DevOps パイプラインを使用して、開発、テスト、および運用環境にフローを展開できる
本記事では、上記公開記事の手順をベースに実際に Power Automate の所有者をサービスプリンシパルに変更してみます。
作業手順
0. 前提
- 所有者変更対象の Power Automate フローをソリューションに追加します（ソリューションフローのみが所有者変更をサポートしているため）
- サービスプリンシパル作成（アプリの登録）には最低限クラウド アプリケーション管理者ロールが必要です
- Power Platform におけるアプリケーション ユーザーの作成には最低限対象環境の環境管理者ロールが必要です（もちろん Power Platform 管理者でも可）
1. サービスプリンシパルの作成
サービスプリンシパル 作成の説明自体は Power Platform における Learn に記載がないので、 Entra ID の Learn に従って作成します。
クラウド アプリケーション管理者ロールが付与されたユーザーで Entra ID 管理センターにアクセスし、「アプリの登録」画面に遷移します。
「＋新規登録」をクリックします。
アプリ新規登録画面にて以下を設定し「登録」をクリックします。
- 名前：分かりやすいよう任意で
- サポートされているアカウントの種類：この組織ディレクトリにのみ含まれるアカウント
- リダイレクトURI：設定なし
以下の通り正しく作成されていることを確認します。
後続の手順ではアプリケーション ID 等を入力することはないので、値を控える必要はありません。
2. アプリケーション ユーザーの作成
サービスプリンシパルを Power Platform 領域で使用するためには、アプリケーション ユーザーを作成してサービスプリンシパルと関連付ける必要があるようです。
Power Platform 管理センターから操作対象の環境ページを開き、アクセス ブレード内の「S2S アプリ」をクリックします。
上部の「＋新規アプリ ユーザー」をクリックします。
作成画面ではまず最初に「＋アプリの追加」をクリックし、一覧から 1. で作成したアプリを選択します。
次に、必須入力の部署を設定して「登録」をクリックします。
今回はアプリケーション ユーザー をフローの所有者として利用するのみのため、セキュリティロールの設定は行いません。
以下の通り正しく作成されていることを確認します。
3. Power Automate フローの所有者をアプリケーション ユーザーに変更する
所有者変更対象のフロー詳細画面を開き、「主要な所有者を設定する」をクリックします。
主要な所有者欄に元々登録されているユーザーを削除し、 2. で作成したアプリケーション ユーザーに変更して「保存」ボタンをクリックします。
所有者の変更に関するダイアログが表示されたら「所有者の変更」をクリックします。
フローを実行してみます。問題なく実行できていることが確認できました。
気になるライセンス管理
上記の通り Power Automate フローの所有者をサービスプリンシパル（を紐づけたアプリケーション ユーザー）に変更することはできましたが、Power Automate は Process ライセンス以外はユーザーベースのライセンスです。
非対話型ユーザー（ユーザーライセンスを割り当てられないユーザー）におけるフロー実行はライセンスの観点でどのような取り扱いとなっているのでしょうか？
公開情報には以下の通り記載されています。
サービス プリンシパル アプリケーション ユーザーは非対話型ユーザーであるため、ユーザー ライセンスを関連付けることはできません。 プレミアム サービス プリンシパル アプリケーションのユーザー所有フローには、Power Automate プロセス/Power Automate フロー単位ライセンスが必要です。 ただし、フローがプレミアム コネクタを使用しない場合、またはフローが Dynamics 365アプリケーションのコンテキストにおいて独占的に使用される場合は、Power Automate プロセスまたは Power Automate フロー単位ライセンスが免除されます。
そうなると、プレミアム コネクタ を使用しないフローの所有者をユーザーライセンスを関連付けることのできないアプリケーション ユーザー とした場合に必要なライセンスは何か？と疑問が湧きますが、こちらも公開情報で以下の通り記載されています。（API 要求数の文脈です）
ユーザーがサービスを操作する必要のない特定のアクティビティ (例: データベース間でデータを移行するバックグラウンド プロセス) には、個別の制限が設定されています。 これらの制限は、テナント レベルで定義およびプールされます。 Dataverse では、サービスを操作するのにユーザーを必要としない ID を設定できます。 これらには、以下が含まれます。
アプリケーション ユーザー
非対話型ユーザー
管理ユーザー
システム ユーザー
また、Dynamics 365 Marketing のような Dynamics 365 アプリケーションとの対話に使用する特別な無料 ($0) ライセンスがあります。 詳細は、マーケティングのライセンス取得方法 を参照してください。
これらの非ライセンス ID の場合、すべてのテナントは、テナントの有料ライセンスによって決定される初期基本要求制限に加えて、有料の Dynamics 365 Enterprise および Professional ライセンスの数によって発生する制限を取得します。1 このプールは、これらの非ライセンス ユーザーのみが使用でき、対話型ユーザー ライセンスが割り当てられているユーザーは使用できません。
| 製品 | 24 時間ごとにプールされた非ライセンスのテナントレベルの要求 |
|---|---|
| Dynamics 365 Enterprise および Professional アプリケーション 1 | 500,000 の基本要求+ USL ごとに発生した 5,000 の要求 1、最大 10,000,000 まで 2 |
| Power Apps (すべてのライセンス) | テナントのライセンスごとの発生なしで 25,000 の基本要求 |
| Power Automate (すべてのライセンス) | テナントのライセンスごとの発生なしで 25,000 の基本要求 |
要求についてはテナントの有料ライセンスによって決定される初期基本要求制限がベースと記載されています。
この表の「すべてのライセンス」が Power Apps Basic / Power Automate Basic も含むのか判断に迷うところではあります。
運用される際にはライセンスの考え方について問い合わせたほうが良さそうです。
さいごに
この対応はある程度有効そうですが、接続情報まで個人ユーザーから切り離さないとユーザー依存の問題は解決しないですね。
（接続で認証しているユーザーが削除されたら？パスワードが変更されたら？アクセス許可が変更されたら？）
ここを完全に解決するには接続までサービスプリンシパルで認証しないといけません。
こちらはまた別の機会に。
Discussion