MENU

Microsoft Entra IDで認証方法だけのカスタムロールを作れない理由と回避策

Azure

Azure AD（現 Microsoft Entra ID）で、ヘルプデスク向けに「ユーザーの認証方法だけ」を触れる最小権限ロールを作りたい──そんなニーズは多くのテナントで高まっています。しかし実際には、Authentication Administrator ロールが持つ microsoft.directory/users/authenticationMethods/* 系アクションだけを抜き出したカスタムロールは、2025 年 11 月時点でもまだ作成できません。本記事では、その理由と現実的な回避策、今後チェックすべきポイントを整理します。

目次

結論の先出し：認証方法だけのカスタムロールは「まだ無理」

項目内容
現状Microsoft Entra ID のカスタムロールが扱えるユーザー関連アクションは、公式ドキュメントに列挙されたごく一部のみ。
そこに microsoft.directory/users/authenticationMethods/* 系アクションは含まれていません。
問題となる点組み込みロール「Authentication Administrator」には、認証方法の作成・削除・更新・閲覧などのアクションが多数含まれていますが、これらは「ビルトイン専用」の扱いで、カスタムロールにコピーできません。
公式回答の方向性Microsoft Q&A などでも「custom roles では microsoft.directory/users/authenticationMethods スコープはサポートされていないため、MFA リセット専用ロールなどは作成できない」と明言されています。
実務での落としどころ余分な権限を飲み込んで Authentication Administrator を使いつつ、PIM（Privileged Identity Management）で JIT（Just-in-Time）付与し、管理対象を管理者以外のユーザーに限定する構成が現実的な解です。

なぜ「認証方法だけ」のカスタムロールを作りたくなるのか

まず、要件を整理してみます。

  • ヘルプデスク／一次サポート担当者に「ユーザーの MFA／認証方法のリセット・登録・削除」だけを行わせたい
  • しかし、アカウント削除・有効化／無効化・パスワード変更など、他の強い権限は与えたくない
  • 理想は、Authentication Administrator ロールに含まれる
    • microsoft.directory/users/authenticationMethods/create
    • microsoft.directory/users/authenticationMethods/delete
    • microsoft.directory/users/authenticationMethods/basic/update
    • microsoft.directory/users/authenticationMethods/standard/read
    などだけを抽出した「最小権限ロール」

ところが、Entra 管理センターの「カスタム ロール」作成画面でこれらのアクションを検索しても候補に出てこず、PowerShell や Microsoft Graph から New-MgRoleManagementDirectoryRoleDefinition などで指定すると、400 エラーで弾かれてしまいます。

# 典型的な例（意図的にシンプル化）
$rolePermissions = @{
  allowedResourceActions = @(
    "microsoft.directory/users/authenticationMethods/create"
  )
}

New-MgRoleManagementDirectoryRoleDefinition `
  -DisplayName "Custom Auth Method Admin" `
  -Description "Manage user authentication methods only" `
  -RolePermissions $rolePermissions `
  -TemplateId (New-Guid).Guid `
  -IsEnabled:$true
# => Action '.../authenticationMethods/create' is not supported for Custom Role creation

この挙動はバグではなく、「仕様」です。その背景を見ていきます。

Microsoft Entra ID のカスタムロールの前提

Microsoft Entra ID には大きく分けて以下の二種類のロールモデルがあります。

  • Azure リソース向けの Azure RBAC（サブスクリプション / RG / リソース単位のロール）
  • ディレクトリ向けの Entra ID ロール（Global Administrator / User Administrator など）

今回のテーマは後者、ディレクトリロール側の話です。Entra ID のカスタムロールは、「許可された一部のアクション」だけを組み合わせて作ることができる仕組みになっています。

  • アクションは microsoft.directory/<エンティティ>/<プロパティセット>/<操作> の形式
  • 例：microsoft.directory/users/standard/read、microsoft.directory/groups/members/update など
  • カスタムロールで使えるアクションは、Microsoft が「カスタムロール対応」として公開している一覧のみ

ユーザー管理用にカスタムロールで使えるアクションは、「User management permissions for Microsoft Entra custom roles」というドキュメントに一覧化されています。そこには、ユーザーの基本属性更新・ライセンス管理・グループ所属閲覧など、多数のアクションが載っていますが、users/authenticationMethods 系のエントリは存在しません。

つまり、「authenticationMethods 系のアクションは、そもそもカスタムロールの材料として公開されていない」というのが根本原因です。

Authentication Administrator ロールが持つ「強すぎる」権限

一方、組み込みの Authentication Administrator ロールはどうでしょうか。このロールの権限定義を Microsoft Graph で見ると、次のようなアクションが含まれています（抜粋）。

  • microsoft.directory/users/authenticationMethods/create
  • microsoft.directory/users/authenticationMethods/delete
  • microsoft.directory/users/authenticationMethods/standard/restrictedRead
  • microsoft.directory/users/authenticationMethods/basic/update
  • microsoft.directory/users/password/update
  • microsoft.directory/users/delete
  • microsoft.directory/users/enable / disable
  • microsoft.directory/users/invalidateAllRefreshTokens
  • ほか、サービス正常性・サポートチケット関連アクション etc.

つまり Authentication Administrator は、

  • MFA 再登録や認証方法の追加・削除といった「認証方法そのもの」の操作
  • アカウント有効化／無効化、削除、パスワードリセットなど、アカウントライフサイクルに関わる操作
  • 一部のサービス正常性・サポート関連操作

をひとまとめに持っている「かなり強めのロール」です。これをそのままヘルプデスクに付与するのは、多くの組織にとってオーバーキルに感じられるでしょう。

なぜ authenticationMethods 系アクションはカスタムロールに追加できないのか

ポータルや PowerShell で authenticationMethods 系アクションを指定してもエラーになる理由は、シンプルに言えば 「カスタムロールで使えるアクション一覧に含まれていないから」です。

いくつかの事例を踏まえて整理します。

ドキュメント上の制限

先述のとおり、「User management permissions for Microsoft Entra custom roles」の「Full list of permissions」には、ユーザー管理で使える全アクションが掲載されていますが、ここに users/authenticationMethods 系は登場しません。

また、Microsoft Q&A では、

  • microsoft.directory/users/authenticationMethods/create を AllowedResourceAction に指定して New-AzureADMSRoleDefinition を実行すると、BadRequest（Action … is not supported for Custom Role creation） で失敗する
  • サポート担当者から「カスタムロールがサポートするのは、アプリ登録・サービス プリンシパル・グループ管理などごく一部であり、authenticationMethods 系はカスタムロールでは利用できない」とのコメント

といった回答が寄せられています。

Microsoft 公式 Q&A の明言

2024 年の Microsoft Q&A では、「MFA の再登録だけを許可するロールを作りたい」という質問に対して、Microsoft 社員が次のように回答しています。

  • カスタム Entra ID ロールで利用できるアクションには、現時点で microsoft.directory/users/authenticationMethods スコープが含まれていない
  • したがって、MFA リセットだけを行う専用ロールをカスタムロールで作ることはできない
  • 現時点での最小権限ロールは Authentication Administrator であり、これを PIM で制御するのが推奨

同様に、「ヘルプデスクに MFA リセット権限だけを渡したい」という質問に対しても、「カスタムロールは使えず、Authentication Administrator が唯一の最小権限ロール」というコメントが出ています。

2025 年になっても変わっていない？ コミュニティの声

2025 年の Reddit（r/AZURE）では、

  • microsoft.directory/users/authenticationMethods/read/update/delete/create を含むカスタムロールを作ろうとしても、ポータル側の UI には出てこない
  • PowerShell で似たアクションを指定してロール定義を作成できたように見えても、ユーザー側の権限としては実際に効いていない
  • 2025 年 8 月時点でも「Temporary Access Pass 用のカスタム TAP ロール」が作れず嘆いている投稿

といった報告が続いており、2025 年後半になっても状況は大きく変わっていないことが読み取れます。

内部的には存在しているが「特権」扱い

興味深いのは、Microsoft Graph の RBAC API で roleManagement/directory/resourceNamespaces('microsoft.directory')/resourceActions を列挙すると、authenticationMethods 系アクションを含む長大な一覧が取得できる点です。

  • microsoft.directory/users/authenticationMethods.sms/create
  • microsoft.directory/users/authenticationMethods.securityQuestion/delete
  • microsoft.directory/users/authenticationMethods.temporaryAccessPass/basic/update

などが並び、それぞれに isPrivileged フラグが付いています。多くの authenticationMethods 系アクションは privileged（特権） とされており、カスタムロールではなくビルトインロールでのみ利用される設計であることが示唆されます。

まとめると、

  • ディレクトリ内部の RBAC スキーマとしては authenticationMethods 系アクションは存在する
  • しかしカスタムロールで利用できるアクション一覧には露出しておらず、ポータルでも PowerShell でもサポート外と扱われる
  • 標準の Authentication Administrator / Privileged Authentication Administrator などのビルトインロール専用権限、という位置付け

と考えるのが自然です。

よくある試行とハマりどころ

ポータルで検索しても出てこない

Entra 管理センターの「カスタム ロール」作成画面では、アクションの候補一覧から選択する形になっています。ここに表示されるのは「カスタムロールでサポートされるアクション」だけです。

  • Authentication Administrator の権限一覧にあるアクション名をコピペして検索してもヒットしない
  • authenticationMethods で検索してもゼロ件

この時点で、「ポータルで見つからないアクションは、そもそもカスタムロールとしては使えない」と理解しておくのがポイントです。

PowerShell / Graph で直接指定しても 400 エラー

ポータルに出てこないアクションを PowerShell や Graph で直接指定しても、裏側のバリデーションで弾かれます。

典型的なエラーメッセージは次のようなものです（意訳）。

  • Action 'microsoft.directory/users/authenticationMethods/create' is not supported for Custom Role creation.
  • カスタムロールでは、サポートされているアクションのみ指定可能

これは 2022 年頃から報告されており、2025 年時点でも仕様は変わっていません。

Graph 経由で「作れてしまう」ケースに要注意

一部のブログや検証記事では、Graph API で JSON を直接投げることで authenticationMethods 系アクションを含んだカスタムロール定義が作れてしまった、という報告もあります。しかし、

  • ポータル上でそのロールを確認すると「有効な権限」として扱われていない
  • 対象ユーザーにロールを割り当てても、実際には認証方法の変更ができない

といった状況が多数報告されており、「定義はできたように見えても、実際には権限が効いていない」パターンが多い印象です。公式にサポートされたルートではないため、本番環境で利用するべきではありません。

2025 年 11 月時点での整理

ここまでを踏まえ、2025 年 11 月時点の状況を簡単にタイムラインで振り返ってみます。

時期出来事authenticationMethods 系カスタムロール対応
〜2022 年カスタムロールは主にアプリ登録・エンタープライズアプリ・一部グループ操作のみ対応。ユーザー管理はほぼ対象外。当然未対応
2022〜2023 年「User management permissions for custom roles」が追加され、ユーザーの基本プロパティやライセンス管理などがカスタムロールで扱えるようになる。一覧に authenticationMethods 系は入らず。
2024 年MFA リセット専用ロールを作りたい、という Q&A に対し、Microsoft 社員が「custom roles では authenticationMethods スコープを扱えない」と明言。未対応継続
2025 年Temporary Access Pass や QR コード認証など、新しい認証方法は増える一方だが、コミュニティでは「2025 年 8 月の時点でも TAP 用カスタムロールを作れない」との声。少なくとも一般公開ドキュメント上は未対応のまま

現時点で「authenticationMethods 系アクションがカスタムロール対応になった」という公式アナウンスやドキュメント更新は確認できません。そのため、「ユーザー認証方法だけを扱えるカスタムロール」は、まだ構成不可能と判断するのが妥当です。

現実的な回避策：どう設計すべきか

「できない」で終わってしまっては業務が回りません。ここからは、実際のテナント設計で取り得る現実的な回避策を整理します。

1. Authentication Administrator を前提とし、PIM で JIT 付与する

まずは王道のパターンです。

  • ヘルプデスク担当者には Authentication Administrator ロールを割り当てる
  • ただし常時アクティブにはせず、Privileged Identity Management（PIM）で「適格（Eligible）」割り当てにしておく
  • MFA リセットなどが必要なときだけ、時間限定でロールをアクティブ化

PIM を使うことで、次のような制御が可能です。

  • ロール有効化時に必ず MFA を要求
  • 有効期間を 30〜60 分など短時間に制限
  • 有効化のたびに「チケット番号を必須入力」にして証跡を残す
  • 上長やセキュリティチームの承認フローを挟む
  • ロール有効化／利用の監査ログを定期的にレビュー

「Authentication Administrator は強すぎる」という懸念に対しては、技術的な最小権限ではなく「時間とプロセス」でリスクを抑えるアプローチと割り切ることになります。

2. 管理対象を非管理者ユーザーに限定する（Administrative Unit）

Entra ID の Administrative Unit（AU）を使うと、ロールの有効範囲をテナント全体ではなく一部のユーザー／グループに絞り込むことができます。

  • 「一般ユーザーだけ」を対象にした AU を作成
  • グローバル管理者や他の特権ロールを持つアカウントは、AU のスコープから意図的に外す
  • その AU に対してのみ Authentication Administrator を割り当てる

こうすることで、「ヘルプデスクが誤って Global Administrator の認証方法を消してしまう」といった事故のリスクを減らせます。Restricted management administrative unit を活用すると、特権アカウントの扱いをさらに厳格にできます。

3. My Staff などの委任管理を併用する

フロントラインワーカーや店舗スタッフ向けであれば、My Staff ポータルによる委任管理という選択肢もあります。

  • My Staff を有効化すると、店舗マネージャーなどフロントライン管理者が、自分のチームに対して
    • パスワードリセット
    • 電話番号など一部属性の更新
    • QR コード認証など特定の認証方法の管理
    をブラウザやモバイルから簡単に操作できる
  • Entra 管理者は、Administrative Unit とロールを組み合わせて、My Staff の操作範囲をきめ細かく制御できる

My Staff は「フロントラインワーカー管理」「Delegated user management」として公式に位置付けられており、パスワードリセットや認証方法に関する操作を、IT 管理者ではなく現場のマネージャーに委任するシナリオを前提に設計されています。

ヘルプデスクがすべての認証方法を扱うのではなく、

  • 店舗スタッフのような特定セグメント → My Staff で現場に委任
  • それ以外のユーザー → Authentication Administrator + PIM で中央ヘルプデスクが対応

といった棲み分けを検討する価値があります。

4. セルフサービスを最大限活用する（SSPR / 認証方法登録の自動化）

そもそも管理者が認証方法をいじる頻度を下げる、というのも有効なアプローチです。

  • SSPR（Self Service Password Reset）と MFA の統合登録（combined registration）を有効化し、ユーザーに複数の認証方法登録を促す
  • 認証方法ポリシーで SMS / 音声通話 / Authenticator / FIDO2 などの許可・禁止を明確化
  • 定期的に「Authentication methods activity」レポートをチェックし、登録状況に偏りがないか確認する

これにより、

  • 「スマホを変えたので MFA をリセットしてほしい」系のチケットを大幅に減らせる
  • 管理者が認証方法を手動で変更するケースを例外的なものにできる

結果として、「強いロールを JIT で付与する頻度」自体を抑えられるため、リスク低減につながります。

5. 運用ルールと監査で「人の権限」を締める

技術だけで完全な最小権限を実現できないときは、運用ルールと監査で補完するのが現実解です。

  • Authentication Administrator を付与できるのは、限定されたセキュリティチームのメンバーだけにする
  • PIM のアクティベーション理由に「チケット番号＋ユーザー UPN」を必須入力
  • 月次で
    • ロールアクティベーション履歴
    • 認証方法変更の監査ログ
    を突き合わせて不審な操作がないかチェック
  • 勝手なアクティベーションや手順無視があった場合のペナルティや是正フローを明文化

技術的なカスタムロールが用意されていない以上、「人間側の統制」を強めてリスクを下げる、という考え方が重要になります。

「もし認証方法アクションがカスタムロール対応になったら」チェックすべきポイント

今後、Microsoft が authenticationMethods 系アクションをカスタムロールに解放してくる可能性は十分あります。そのときに備えて、どこをウォッチしておくべきかをまとめておきます。

確認ポイントチェック内容
カスタムロール作成画面の候補一覧authenticationMethods で検索してヒットするかどうか。出てくれば大きな前進。
User management permissions for custom roles「Full list of permissions」に microsoft.directory/users/authenticationMethods/... が追加されていないか。
Privileged roles and permissions ドキュメントAuthentication Administrator / Privileged Authentication Administrator の説明に「カスタムロールで利用可能」等の文言が追加されていないか。
Entra ID の「What’s new」「Custom roles support for authentication methods actions」のようなリリースノートが出ていないか。
コミュニティ（Microsoft Q&A / Reddit など）「ついに MFA リセット用カスタムロールが作れた」という成功例が出てくるかどうか。

少なくとも現在のところ、これらのいずれにも「対応しました」という情報は見当たりません。authenticationMethods 系のカスタムロール対応が入った場合は、かなり大きな仕様変更になるため、公式ドキュメントやリリースノートでしっかり告知されると考えられます。

サンプル：最小限安全寄りに設計する構成例

最後に、実際にテナントを設計するときの一例を示します。

前提

  • Microsoft Entra ID P1 テナント
  • グローバル管理者アカウントで構成作業可能
  • ヘルプデスク部門に 10 名程度の一次サポート要員

ステップ 1：Administrative Unit でスコープを分離

  1. 「All Standard Users」という AU を作成し、全ての一般ユーザーをメンバーにする
  2. Global Administrator や各種特権ロールを持つアカウントは、この AU から意図的に除外

ステップ 2：Authentication Administrator を AU スコープで付与

  1. PIM を開き、「ロール」から Authentication Administrator を選択
  2. 割り当てスコープとして「Administrative Unit」を選択し、先ほど作成した「All Standard Users」を指定
  3. ヘルプデスクの Azure AD グループを「適格（Eligible）」として割り当てる

ステップ 3：PIM のポリシーを厳しめに設定

  • 有効期間：最大 1 時間
  • MFA 要求：必須
  • 理由入力：必須（チケット番号＋対象ユーザー UPN の記入を運用ルールで徹底）
  • 必要に応じてマネージャー承認を要求

ステップ 4：SSPR と combined registration を有効化

  • できる限りユーザー自身に認証方法を登録・更新してもらう
  • Authentication methods activity レポートで登録状況を可視化し、未登録ユーザーにはキャンペーンを実施

ステップ 5：前線部門には My Staff を検討

  • フロントラインワーカーを抱える部門には My Staff を導入し、店舗マネージャーにパスワードリセットや一部認証方法の管理を委任
  • これにより、中央ヘルプデスクが対応する範囲をさらに減らす

この構成であれば、

  • 技術的には Authentication Administrator という「強いロール」を使いつつも
  • 対象ユーザーを一般ユーザーに限定し
  • JIT 付与 + 厳格な運用ルール + 監査

によってリスクを許容範囲まで抑えることができます。

まとめ

  • 2025 年 11 月時点では、microsoft.directory/users/authenticationMethods/* 系アクションだけを持つカスタムロールは作成できません。
  • Authentication Administrator に含まれる認証方法関連アクションは、内部的には RBAC スキーマ上に存在しますが、「特権」扱いでビルトインロール専用とみなされており、カスタムロールには露出していません。
  • ポータルに候補が出てこないアクションは、PowerShell や Graph で直接指定しても「Custom Role creation ではサポートされていない」として拒否されます。
  • MFA リセット専用ロールなどを実現したい場合は、Authentication Administrator を前提にしつつ、PIM・Administrative Unit・My Staff・SSPR などを組み合わせて、時間・対象・プロセスの三方向からリスクを抑える設計が現実的です。
  • 将来的に authenticationMethods 系アクションがカスタムロール対応になる可能性もあるため、カスタムロール用のユーザー権限一覧や Entra ID の「What’s new」を定期的にチェックしておくとよいでしょう。

「認証方法だけのカスタムロール」が作れないのは確かに痛い制約ですが、逆に言えば「いまはそこまで細かく分解できないほど強い操作」であるということでもあります。ビルトインロール＋PIM＋運用で丁寧にリスクを抑えつつ、今後のアップデートに期待しながらロードマップをウォッチしていく、というのが 2025 年時点での現実的な落としどころと言えるでしょう。

Azure
MFA Azure AD Microsoft Entra ID PIM カスタムロール 認証方法

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次