「Cannot find user or service principal」エラー解決！Azure RBACの正しい削除方法

1 初めに
2 この記事で分かること
3 この問題に遭遇するシナリオ
4 なぜこの問題が発生するのか？
- 4.1 なぜ自動削除されないのか？
5 セキュリティ上の懸念
6 運用上の問題点
- 6.1 権限トラブルシューティングが困難に
- 6.2 管理者からの確認依頼が来る
7 問題の発見方法
- 7.1 権限確認コマンドで Unknown Principal もしくは null を検出
8 削除方法：ハマったポイントと解決策
- 8.1 ❌ 最初に試して失敗した方法
- 8.2 ✅ 正解：割り当て ID（Assignment ID）を直接指定
9 実務での推奨運用フロー
10 まとめ
- 10.1 学んだこと
- 10.2 実務での教訓
11 参考資料
12 おわりに
13 関連記事

初めに

ども！今月は Azure 関連の情報をメインにまとめている龍ちゃんです。今回は、実際に詰まった内容をもとに原因探求と対応方法についてまとめていきます。
Azure でリソースグループの権限確認したら、Unknown Principal が大量に残ってた…なんて経験ありませんか？（これにぶち当たったあなたは勤勉です！）
実は私も先日、OIDC 認証の設定中にこの問題に遭遇して、めちゃくちゃハマりました。削除しようとしたら「Cannot find user or service principal in graph database」エラーが出て、「削除できんやん！」ってなったんですよね。
今回は、削除された Managed Identity のロール割り当てを削除する方法と、なぜこの問題が発生するのかを解説します。

この記事で分かること

Unknown Principal が発生する原因と Azure の仕様
プリンシパル ID では削除できない理由（エラーメッセージの解説）
割り当て ID（Assignment ID）を使った正しい削除方法
実務での推奨運用フローとセキュリティ対策

それでは、さっそく見ていきましょう！

この問題に遭遇するシナリオ

Azure を使っていると、こんな状況に遭遇したことありませんか？

テスト環境で OIDC 認証を試していたが、うまくいかずに Managed Identity を削除してやり直した
プロジェクト終了時にリソースを削除したが、ロール割り当てだけが残ってしまった
別の担当者が作成した Managed Identity を削除したが、権限周りのクリーンアップを忘れていた
リソースグループの権限確認をしたら、Unknown Principal が大量に残っている…

なぜこの問題が発生するのか？

Azure では、以下のような仕組みになっています：

Managed Identity や Service Principal を削除
- Azure AD（Microsoft Entra ID）からプリンシパル自体が削除される
ロール割り当ては自動削除されない
- ロール割り当ては Azure Resource Manager（ARM）のリソースとして別管理
- プリンシパルを削除しても、ロール割り当ては残り続ける

つまり、ロール割り当ては明示的に削除しない限り、永遠に残り続けます。厄介な仕様ですね～

なぜ自動削除されないのか？

これ、最初は「なんで自動削除してくれないの？」って思ったんですが、調べたところ以下のような理由があるようです。：

誤削除防止: プリンシパルを誤って削除した場合、同じ ID で再作成すれば権限が復元できる
監査ログの保持: 誰がどのリソースにアクセスできたかの履歴を残す
依存関係の問題: ロール割り当てを自動削除すると、意図しない権限喪失が発生する可能性

ただし、この仕様のせいでゴミが残りやすいのも事実です。

セキュリティ上の懸念

削除されたプリンシパルのロール割り当てが残っていると、以下のリスクがあります：

1. 同じプリンシパル ID で再作成されるリスク

注意すべきパターンですが、実際のリスクは超限定的です。

過去に削除したプリンシパルの ID は、理論的には再利用可能
攻撃者が同じ ID でプリンシパルを作成した場合、古いロール割り当てが有効になる
結果的に、意図しない権限昇格が発生する可能性

ただし、超絶レアケース やはりこの辺は Azure 側で防止されています。：

30 日間のソフトデリート: Managed Identity や Service Principal は削除後 30 日間ソフトデリート状態になり、その間は同じ ID を再利用できません
GUID の性質: Azure が使用する GUID（Globally Unique Identifier）は、実質的に衝突しない設計になっています
30 日経過後も: ソフトデリート期間終了後に同じ ID が再割り当てされる確率は天文学的に低い

理論的なシナリオ:

1. テスト用 Managed Identity（ID: xxx-xxx-xxx）を作成 → Owner 権限付与
2. テスト終了後、Managed Identity を削除（でもロール割り当ては残る）
3. 30日間のソフトデリート期間が経過
4. 数ヶ月〜数年後、Azure が偶然同じIDを再割り当て（極めて低確率）
5. 新しいプリンシパルに、過去の Owner 権限が復活してしまう

現実的なリスク評価:

可能性は極めて低いですが、理論的にはゼロではありません。より現実的なリスクは、以下のような運用上の問題です：

セキュリティ監査で Unknown Principal の説明ができない
権限管理の可視性が失われる
コンプライアンス要件に抵触する可能性

つまり、セキュリティ侵害のリスク < 運用上の問題 という認識が正確ですね。

2. 権限管理の可視性が失われる

「誰がどのリソースにアクセスできるか」を確認するとき、Unknown Principal が大量にあると混乱する
セキュリティ監査で「これ何ですか？」と質問され、説明に困る
本当に必要な権限と、ゴミの区別がつかなくなる

3. コンプライアンス違反のリスク

多くの企業では「最小権限の原則」をポリシーとして定めている
不要なロール割り当てが残っていると、このポリシーに違反する可能性
内部監査や外部監査で指摘される原因になる

運用上の問題点

セキュリティだけでなく、日々の運用でも問題になります。

権限トラブルシューティングが困難に

権限周りの問題をデバッグするとき、Unknown Principal があると混乱します：

# 権限確認したら...
az role assignment list --resource-group rg-prod --output table

# 出力例
Principal                         Role        Scope
--------------------------------  ----------  -------
user@example.com                  Owner       ...
app-prod-deploy                   Contributor ...
Unknown                           Owner       ...  ← これ何？
Unknown                           Contributor ...  ← これも何？
app-prod-monitor                  Reader      ...

「Unknown が何者か」を特定するには：

Azure ポータルで Activity Log を確認
過去のデプロイ履歴を調査
前任者に確認（いない場合は詰む）

時間の無駄ですよね。

管理者からの確認依頼が来る

特に大規模な組織では、セキュリティチームから定期的に権限監査の依頼が来ます（ちなみにこれは妄想..）：

件名: リソースグループ権限の確認依頼

以下のリソースグループに Unknown Principal のロール割り当てが
検出されました。これらは何に使用されていますか？

- リソースグループ: rg-prod
- Principal ID: xxx-xxx-xxx
- ロール: Owner
- 割り当て日: 2024-03-15

本日中にご回答ください。

答えられないんですよね。だって削除されたプリンシパルだから。

説明するのも面倒だし、「管理が甘い」って思われるのも嫌です。

問題の発見方法

権限確認コマンドで Unknown Principal もしくは null を検出

# リソースグループのロール割り当てを確認
RESOURCE_GROUP="rg-example"

az role assignment list \
  --resource-group $RESOURCE_GROUP \
  --query "[].{ID:id, Principal:principalName, PrincipalID:principalId, Role:roleDefinitionName}" \
  --output table

出力例:

ID                                                                                                               Principal    PrincipalID                          Role
---------------------------------------------------------------------------------------------------------------  -----------  -----------------------------------  -----
/subscriptions/xxx/.../roleAssignments/aaa                                                                       user@ex.com  111-111-111-111                      Owner
/subscriptions/xxx/.../roleAssignments/bbb                                                                       Unknown      222-222-222-222                      Owner
/subscriptions/xxx/.../roleAssignments/ccc                                                                                    333-333-333-333                      Contributor

Principal が Unknown になっているのが、削除されたプリンシパルのロール割り当てです。

削除方法：ハマったポイントと解決策

❌ 最初に試して失敗した方法

普通にプリンシパル ID を指定して削除しようとしました：

# プリンシパルIDを指定して削除を試みる
az role assignment delete \
  --assignee 222-222-222-222 \
  --resource-group $RESOURCE_GROUP

エラーメッセージ:

Cannot find user or service principal in graph database for 222-222-222-222.
If the assignee is an appId, make sure the corresponding service principal is
created with 'az ad sp create --id 222-222-222-222'

原因:

az role assignment delete --assignee は、Azure AD のグラフデータベースでプリンシパルを検索する
プリンシパル自体が既に削除されているので、グラフデータベースに存在しない
結果的に「見つかりません」エラーになる

✅ 正解：割り当て ID（Assignment ID）を直接指定

ロール割り当て自体は Azure Resource Manager（ARM）のリソースとして残っているので、リソース ID を直接指定すれば削除できます。

手順 1: 削除対象の割り当て ID を確認

# 割り当てIDを含めて表示
az role assignment list \
  --resource-group $RESOURCE_GROUP \
  --query "[].{ID:id, Principal:principalName, Role:roleDefinitionName}" \
  --output table

出力例:

ID                                                                                                               Principal    Role
---------------------------------------------------------------------------------------------------------------  -----------  -----------
/subscriptions/xxx/resourceGroups/rg-example/providers/Microsoft.Authorization/roleAssignments/bbb              Unknown      Owner

手順 2: 割り当て ID を指定して削除

# 割り当てID全体をコピーして実行
az role assignment delete --ids "/subscriptions/xxx/resourceGroups/rg-example/providers/Microsoft.Authorization/roleAssignments/bbb"

成功！

手順 3: 削除確認

az role assignment list \
  --resource-group $RESOURCE_GROUP \
  --query "[].{Principal:principalName, Role:roleDefinitionName}" \
  --output table

Unknown Principal が消えていれば OK です。

実務での推奨運用フロー

OIDC 認証を設定する前に、以下のクリーンアップフローを実施しましょう：

1. 権限確認

RESOURCE_GROUP="rg-example"

# すべてのロール割り当てを確認
az role assignment list \
  --resource-group $RESOURCE_GROUP \
  --query "[].{Principal:principalName, Role:roleDefinitionName, AssignedDate:createdOn}" \
  --output table

2. Unknown Principal の削除

各割り当て ID を個別に削除することで、より安全に削除できます：

# Unknown Principal の割り当てIDを確認
az role assignment list \
  --resource-group $RESOURCE_GROUP \
  --query "[?principalName==null].{ID:id, Role:roleDefinitionName}" \
  --output table

# 確認した割り当てIDを1つずつ削除
# 例：1つ目の Unknown Principal を削除
az role assignment delete --ids "/subscriptions/xxx/resourceGroups/rg-example/providers/Microsoft.Authorization/roleAssignments/bbb"

# 例：2つ目の Unknown Principal を削除
az role assignment delete --ids "/subscriptions/xxx/resourceGroups/rg-example/providers/Microsoft.Authorization/roleAssignments/ccc"

# 削除後、都度確認しながら進める
az role assignment list \
  --resource-group $RESOURCE_GROUP \
  --query "[].{Principal:principalName, Role:roleDefinitionName}" \
  --output table

ポイント：

各削除の結果を確認しながら慎重に進められる
誤削除のリスクを最小限に抑えられる
どの権限を削除したか記録しやすい

3. 削除確認

# Unknown Principal が消えたことを確認
az role assignment list \
  --resource-group $RESOURCE_GROUP \
  --query "[].{Principal:principalName, Role:roleDefinitionName}" \
  --output table

4. OIDC 認証設定開始

クリーンな状態になったので、安心して OIDC 認証の設定を進められます。

まとめ

学んだこと

Managed Identity を削除しても、ロール割り当ては自動削除されない
- Azure の仕様で、意図的にそうなっている
- セキュリティと監査ログ保持のためだが、ゴミが残りやすい
Unknown Principal はセキュリティリスク
- 同じ ID で再作成されると、意図しない権限昇格の可能性
- 権限管理の可視性が失われる
- コンプライアンス違反のリスク
削除にはコツがある
- プリンシパル ID ではなく、割り当て ID（Assignment ID）を直接指定
定期的なクリーンアップが重要
- OIDC 認証設定前だけでなく、定期的に確認
- 特にテスト環境では頻繁に発生する

実務での教訓

「リソースを削除したら、関連する権限も必ず削除する」

これを習慣化すると、後々のトラブルが減ります。特に：

Managed Identity や Service Principal を削除する前に、ロール割り当てを確認
削除後、Unknown Principal が残っていないか確認
チームメンバーにもこの手順を共有

セキュリティは「意識」と「習慣」です。この記事が、誰かの役に立てば嬉しいです！

参考資料

この記事は以下の公式ドキュメントと実際の検証結果に基づいています：

Microsoft 公式ドキュメント

Azure ロールベースのアクセス制御 (Azure RBAC) のトラブルシューティング
- ロール割り当ての管理とトラブルシューティング手順
削除されたエンタープライズアプリケーション、サービスプリンシパル、Managed ID を復元または削除する
- 30 日間のソフトデリート期間についての公式説明
Azure RBAC の制限
- サブスクリプションあたり 4,000 のロール割り当て制限
Azure CLI – az role assignment
- Azure CLI コマンドリファレンス

DevContainer 実践入門：Azure CLI+GitHub CLI 環境をチーム全体で統一
- Azure CLI を含む開発環境のセットアップ方法

検証環境

Azure CLI: バージョン 2.50.0 以上
検証日: 2025 年 11 月
検証環境: Azure サブスクリプション

おわりに

Unknown Principal の削除、無事にできましたか？
これは実際に Azure CLI で操作を行っている際に衝突した問題です。いや～ Tips としては超限定的な問題ですね。
この記事で紹介した方法を使えば、Unknown Principal を一掃できます。特に OIDC 認証の設定前にクリーンアップしておくと、後々のトラブルシューティングが楽になりますよ。

ポイントをおさらい:

削除は割り当て ID（Assignment ID）を直接指定
定期的なクリーンアップを習慣化
リソース削除前にロール割り当ても確認

セキュリティは「意識」と「習慣」です。今回の問題は「怠慢」ですね wwwww。この記事が、誰かの Azure ライフを少しでも楽にできたら嬉しいです！
もし役に立ったら、ぜひ X（旧 Twitter）でシェアしてください。また、「こんな方法もあるよ」「ここが分かりにくかった」などのフィードバックがあれば、コメント欄や X で教えてもらえると嬉しいです。
それでは、良い Azure ライフを！

この記事と合わせて読むと、さらに理解が深まります：

DevContainer 実践入門：Azure CLI+GitHub CLI 環境をチーム全体で統一
- Azure CLI を含む開発環境のセットアップ方法を詳しく解説
Azure OIDC 認証で安全な GitHub Actions デプロイを実現する方法
- OIDC 認証の設定方法と、この記事で紹介したクリーンアップを実践する方法
- こちらのトラブルシューティングの内容

ご覧いただきありがとうございます！この投稿はお役に立ちましたか？

役に立った役に立たなかった

0人がこの投稿は役に立ったと言っています。

初めに