Microsoft Entra IDでゲストユーザーのMFA再登録とセッション無効化だけを許可するロール設計ガイド

「ゲストユーザーのMFAだけを扱えるヘルプデスク権限を作りたい」「でもグローバル管理者は渡したくない」――そんな要望はどのテナントでも出てきます。本記事では、Microsoft Entra ID（旧Azure AD）で「ゲスト限定のMFAリセット担当者」を、カスタムロールではなく組み込みロール＋管理単位（Administrative Unit）＋PIMで実現する方法を、設計から運用まで詳しく解説します。

前提整理：やりたいこととEntra IDの実情

今回のゴールは次の通りです。

対象ユーザー：テナント内のゲストユーザー（userType = Guest）のみ
許可したい操作：
- 「Require re-register multifactor authentication（MFA の再登録を要求）」
- 「Revoke multifactor authentication sessions（MFA セッションの取り消し）」※将来的に「Revoke sessions」へ置き換え予定
ロール割り当て：特権ID管理（PIM）で必要なときだけ昇格させたい
できれば：上記の操作だけを許可するカスタムロールで最小権限化したい

結論から言うと、2025年末時点でもカスタムロール単体ではこの要件を満たせません。技術的な理由と、そのうえでの現実解（組み込みロール＋管理単位＋PIM）を順に見ていきます。

なぜカスタムロールでは実現できないのか

「認証方法」の操作権限がカスタムロールに解放されていない

ユーザーのMFAをリセットする「Require re-register MFA」や「Revoke MFA sessions」は、裏側では microsoft.directory/users/authenticationMethods/* 系の権限で制御されています。これらは組み込みロール「Authentication Administrator」「Privileged Authentication Administrator」などに含まれるアクションです。

しかし、カスタムロールで使えるアクションは限定されており、長年の要望にもかかわらず、microsoft.directory/users/authenticationMethods/* 系はカスタムロールではサポート対象外のままです。

Microsoft Q&A では、microsoft.directory/users/authenticationMethods/create を許可したカスタムロールを作ろうとしても「Custom Role creation ではサポートされていない」とエラーになることが報告されています。
別のQ&Aでも、「ユーザーの認証方法を管理する最小権限ロールは Authentication Administrator であり、カスタムロールはまだ使えない」と明言されています。
Redditでも、Graph API で authenticationMethods 系アクションを含むカスタムロールを作成しても、実際にはユーザー認証方法を削除できず、最終的に Authentication Administrator で代替している事例が共有されています。

つまり、「MFA再登録だけ」「MFAセッション取り消しだけ」といった粒度のカスタムロールは現状作れない、というのが現実です。

これらの操作ができるのはどのロールか

公式ドキュメントやQ&Aから、次のように整理できます。

操作	最低限必要なロール	補足
MFA の再登録を要求（Require re-register MFA）	Authentication Administrator 以上	Authentication Administrator または Global Administrator が実行可能と明記されています。
MFA セッションの取り消し（Revoke MFA sessions）	Authentication Administrator 以上	同じく Authentication Administrator が実行できると案内されています。
サインインセッションの取り消し（Revoke sessions / invalidateAllRefreshTokens）	Authentication Administrator / User Administrator など	Authentication Administrator の許可アクションに `microsoft.directory/users/invalidateAllRefreshTokens` が含まれます。

また、Authentication Administrator は次のように定義されています。

「一部のユーザーの認証方法情報を表示・設定・リセットできる」「非管理者ユーザーのパスワードリセット、ユーザーの無効化／有効化なども可能」

このように、認証方法まわりの操作をカスタムロールにバラして委任することはできず、最小でも Authentication Administrator（あるいはそれ以上のロール）を使う必要があります。

現実解の全体像：組み込みロール＋管理単位＋PIM

以上を踏まえると、要件を満たしつつ「できるだけ最小権限」に近づける現実的な構成は次の形になります。

ゲストユーザーだけを含む管理単位（Administrative Unit：AU）を作成
そのAUに対して、Authentication Administrator または Privileged Authentication Administratorをスコープ付きで割り当てる
ロール割り当ては特権ID管理（PIM）で「適格（Eligible）」とし、必要なときだけ昇格
標準運用としては条件付きアクセス＋認証方法ポリシーでMFAを強制し、MFAリセットは例外対応として扱う

このアプローチなら、「ゲスト以外は触らせない」「常時ではなく必要時のみ権限付与」という2つのポイントを押さえつつ、実現可能な最小権限を確保できます。

ゲスト専用の管理単位（AU）を作る

管理単位とは？

管理単位は、Entra ID の中に作れる「ユーザー／グループ／デバイス用のコンテナ」で、ロールの有効範囲（スコープ）をその単位に限定する仕組みです。

テナント全体ではなく、特定のユーザー集合にだけ管理権限を効かせたいときに使う
2025年現在は、動的メンバーシップ（Dynamic Administrative Unit）もサポートされており、ルールベースでメンバーを自動管理できます。

「ゲストだけ」の動的管理単位を作る

ゲスト限定にしたい場合、最も分かりやすいのは user.userType を使った動的ルールです。

Entra 管理センターで Entra ID > ロールと管理者 > 管理単位 を開く
＋新しい管理単位 から「Guest-Only」などの名前で作成
作成後、その管理単位の プロパティ > メンバーシップの種類 を「動的ユーザー」に変更
メンバーシップルール に以下を設定して保存

(user.userType -eq "Guest")

実際にこのルールで「ゲスト専用の管理単位」を作っている事例も公開されています。

注意点として、動的メンバーシップを使う管理単位では、メンバー1人につき Entra ID P1 ライセンスが必要になる点があります（管理単位自体の作成はFreeでも可）。

動的管理単位のよくあるハマりどころ

ルール保存後、メンバーが反映されるまで数分〜十数分程度のラグがあることがあります。
テスト環境では、最初に少数のゲストだけで動作検証し、本番では段階的に適用するのがおすすめです。

どのロールを使うか：Authentication Administrator vs Privileged Authentication Administrator

主な認証関連ロールの比較

ロール	認証方法の管理	対象	主な用途
Authentication Administrator	ユーザーの認証方法の表示・設定・リセットが可能	一部のユーザー（非管理者が中心）	一般ユーザーやゲストのMFAサポート、パスワードリセットなど
Privileged Authentication Administrator	認証方法の表示・設定・リセットが可能	すべてのユーザー（管理者も含む）	管理者アカウントを含む環境全体の認証運用
Global Administrator	当然可能だが権限が広すぎる	テナント全体	設計・初期構築用。日常運用のヘルプデスク向きではない

公式の比較表でも、Authentication Administrator / Privileged Authentication Administrator は「ユーザーの認証方法を管理できるロール」として位置づけられています。

また、「管理単位スコープで割り当て可能なロール」として Authentication Administrator / Privileged Authentication Administrator が明示されており、管理単位内のユーザーに対してのみ認証方法を管理できるとされています。

ゲストMFA運用におすすめのロール選択

多くのケース：
- Authentication Administrator をゲスト用AUに割り当てる
- ゲストは通常「非管理者」なので、これで十分なことが多い
ゲストに管理者も混ざる場合：
- 外部委託の管理者など「guest かつ admin」なケースが多いなら、Privileged Authentication Administratorを検討
- ただし権限が広がるため、PIM と承認フローを厳しめにすることが必須

いずれの場合も、ロールそのものから「パスワードリセット」「ユーザー無効化」などの権限だけを削ることはできません。権限の削減は「対象ユーザーを減らす（管理単位）」「有効時間を短くする（PIM）」の2軸で行う、という発想に切り替える必要があります。

PIMで「ゲストMFA担当者」をJIT運用する

PIM側での設定イメージ

ここでは例として、Authentication Administrator をゲスト用管理単位「Guest-Only」に対して割り当てるケースを想定します。

Entra 管理センターで Entra ID > 特権ID管理（PIM） > Entra ID ロール を開く
ロール一覧から Authentication Administrator を選択
割り当て > 追加 をクリック
ウィザードで次を設定
- 割り当ての種類： 適格（Eligible）
- スコープ： 管理単位 を選択し、「Guest-Only」を指定
- メンバー： ヘルプデスク担当者（もしくはロール割り当て可能グループ）を選択
ロール設定（必要に応じて強化）
- 有効化に承認者を要求（例：セキュリティチーム）
- 有効化時にMFA必須
- 最大有効時間を 1〜4時間程度に制限
- 有効化時に理由（Justification）入力を必須にする

こうすることで、ヘルプデスク担当者は次のようなフローでMFAリセット業務を実行することになります。

ユーザーから「MFAが使えない」「スマホ紛失」などの問い合わせを受ける
PIM ポータルor Entra ポータル上でAuthentication Administrator ロールを有効化
対象ユーザー（ゲスト）の認証方法画面から
- Require re-register multifactor authentication
- 必要に応じて Revoke multifactor authentication sessions
を実行
作業完了後、ロールの有効期限が切れるのを待つ（または手動で「延長せず終了」）

権限が使える時間と対象ユーザーをここまで絞ることで、「どうしても消しきれない権限の広さ」を時間軸＋スコープで補うことができます。

実際に押すボタンの挙動を正しく理解する

Require re-register MFA がやっていること

Entra の「Authentication methods」画面にある Require re-register multifactor authentication は、主に次の動作を行います。

ユーザーの以下の認証方法を削除
- 電話番号
- Microsoft Authenticator アプリ
- ソフトウェアOATHトークン
- ハードウェアOATHトークンの無効化
次回サインイン時に新しいMFA方法の登録を強制

つまり、「今登録されているMFAの”器”を全部壊して、次回サインインで再登録させる」ボタンと考えるとイメージしやすいです。

Revoke MFA sessions がやっていること

Revoke multifactor authentication sessions は、主にper-user MFA（従来のユーザーごとMFA）向けの機能で、次のような効果があります。

「このデバイスではMFAを省略する」などで記憶されているMFAセッション情報をクリアする
次回サインイン時に、再びMFAを実行させる
ブラウザセッションには影響が薄く、主にアプリケーション側のMFA状態に効くとされる（環境によって挙動に差がある報告あり）
2026年2月以降は、より汎用的な「Revoke sessions」ボタンに統合される予定で、すべてのセッション（MFA含む）を無効化する挙動に変わるとアナウンスされています。

注意すべきなのは、このボタンは「per-user MFA」が前提であり、条件付きアクセスベースのMFAには直接効かないケースがある点です。そのため、今後は「Revoke sessions」へ移行し、MFAも含めたセッション全体をトークンレベルで無効化する運用に変わっていくと見込まれます。

Revoke sessions との違い

Revoke MFA sessions：「覚えられているMFAの通過状態」を消すイメージ（per-user MFA向け）
Revoke sessions：ユーザーのリフレッシュトークンを無効化し、すべてのサインインセッションを切る（次回パスワード＋MFAが必要）

実務では、次のように使い分けると分かりやすいです。

デバイス紛失・スマホ変更：
- Require re-register MFA ＋ Revoke MFA sessions（または Revoke sessions）
アカウント侵害の疑い：
- ユーザーのサインインブロック or アカウント無効化＋ Revoke sessions（将来はこれが主役）

ゲストMFA運用のベースライン：条件付きアクセス＋認証方法ポリシー

MFAリセット権限を誰かに渡す前に、そもそもの標準MFA運用をしっかり固めておくことが重要です。

per-user MFA はレガシー。条件付きアクセスが前提

Microsoft は従来の「ユーザーごとMFA（per-user MFA）」を段階的にレガシー扱いにしており、最新ドキュメントでも条件付きアクセスポリシーでMFAを強制する運用を推奨しています。

ゲスト向けには、次のようなポリシー構成が典型です。

対象ユーザー：「Guests and external users（ゲストと外部ユーザー）」
対象クラウドアプリ： Microsoft 365 / 自社業務アプリなど
条件：
- サインインリスクが中以上、または
- 社外IPからのアクセス　など
制御：「多要素認証を要求」

認証方法ポリシーと認証強度で「何でMFAするか」を制御

条件付きアクセスは「いつMFAを要求するか」を制御し、認証方法ポリシーと認証強度は「どの認証方法を許可するか」「どのレベルの強度が必要か」を決める役割です。

Authenticator アプリ + FIDO2 セキュリティキーを許可し、SMS/電話は許可しない
高度なアプリや管理操作には「高い認証強度（例：FIDO2必須）」を要求する

こうした標準運用でMFAをきちんと設計しておくと、「MFA再登録／セッション無効化」は本当に例外ケース（紛失・誤登録など）のみになり、権限委任に伴うリスクを大きく下げられます。

よくあるつまずきポイントと対策

「カスタムロールでどうにか細かく縛りたい」は現状不可

何度も触れた通り、microsoft.directory/users/authenticationMethods/* 系のアクションは、まだカスタムロールで正式サポートされていません。Q&A やコミュニティでも「いつになったら対応するのか」という声が上がり続けていますが、2025年時点でも状況は変わっていません。

したがって、「カスタムロールでMFA関連の権限だけを切り出す」のではなく、

組み込みロール（Authentication Administrator など）を前提にし
管理単位スコープ＋PIMで「どのユーザーに」「どのタイミングだけ」効かせるかを制御する

という設計思想に切り替える必要があります。

管理単位のメンバーが意図せず広がる／足りない問題

動的ルールを (user.userType -eq "Guest") にしているつもりでも、実際には
- ゲストをメンバーに昇格させた結果、userType が変わってしまった
- 外部IDシナリオで少し異なる属性が使われている
などの事情で、意図通りに集約されないことがあります。
運用開始後も、定期的に 管理単位のメンバーを棚卸しし、「想定外のユーザーが含まれていないか」を確認する仕組み（レポート or Access Review）があると安心です。

ボタンがグレーアウトして押せない

「Require re-register MFA」や「Revoke MFA sessions」がグレーアウトする場合、次のポイントを確認します。

自分にAuthentication Administrator / Privileged Authentication Administratorが割り当てられているか
そのロールがPIM で有効化済みか（Eligible のままで有効化を忘れているケースが多い）
管理単位スコープで割り当てている場合、対象ユーザーがそのAUのメンバーか
対象ユーザーが per-user MFA で有効／強制状態になっているか（Revoke MFA sessions は per-user MFA 前提）

外部IdPでMFAしているゲストには効きが限定的

ゲストによっては、自社テナントではなく外部テナントや外部IdP（ADFSなど）側でMFAを満たしている場合があります。この場合、Entra 側の「Require re-register MFA」や「Revoke MFA sessions」は、あくまでEntra 側で管理しているMFA情報にしか影響しないことがあります。

こうしたゲストについては、

可能なら「自組織テナント側でのMFA登録」に寄せる
条件付きアクセスで「外部ユーザーに対しても、自組織側のMFAを要求」する設定にする

といった設計を検討するとよいでしょう。

サンプル設計：外部委託ベンダー向けゲストMFA運用

最後に、ここまでの内容を踏まえた具体的な設計例を示します。

要件例

外部委託ベンダーをゲストとして受け入れている
ベンダー向け業務アプリにアクセスする際は必ずMFAが必要
ヘルプデスク（社内）の数名だけが、ベンダーアカウントのMFAトラブルに対応できるようにしたい

設計のまとめ

項目	設計内容
管理単位	「Guest-Only」AUを作成し、`(user.userType -eq "Guest")` で動的メンバーシップ
ロール	Authentication Administrator を「Guest-Only」AUスコープで割り当て
PIM	Authentication Administrator をヘルプデスクグループに「適格（Eligible）」割り当て。1回の有効化は 2時間、MFA＋承認必須。
MFAポリシー	条件付きアクセスで「ゲストと外部ユーザー」＋業務アプリに対しMFA必須。
認証方法ポリシー	ゲストには Microsoft Authenticator または FIDO2のみ許可。SMS/電話は原則禁止。
運用フロー	ヘルプデスクがPIMで昇格 → ゲストユーザーの Authentication methods 画面から「Require re-register MFA」「Revoke MFA sessions / Revoke sessions」を実行。

この構成では、

ゲスト以外のユーザーには管理権限が及ばない（AUで制限）
通常時はヘルプデスクに特権がない（PIMでJIT）
MFAの標準運用は条件付きアクセスと認証方法ポリシーに集約

という、現時点で取り得る「実用的な最小権限設計」にかなり近づけます。

まとめ

MFA再登録やMFAセッション取り消しに必要な microsoft.directory/users/authenticationMethods/* 系アクションは、いまだカスタムロールでは正式サポートされていないため、要件を満たすカスタムロールは作れません。
代わりに、組み込みロールであるAuthentication Administrator / Privileged Authentication Administratorを使い、管理単位（AU）スコープにすることで対象をゲストだけに絞るのが現実解です。
ロールの割り当てはPIMで「適格」＋短時間有効＋承認必須とし、常時特権を持たせない運用が推奨されます。
MFA自体の標準運用は、条件付きアクセス＋認証方法ポリシー＋認証強度で構成し、MFA再登録／セッション無効化はあくまで例外対応として位置づけると安全です。
2026年以降、「Revoke MFA sessions」は「Revoke sessions」に統合され、セッション管理の考え方も変わっていきます。ボタン名に依存しすぎず、「必要なときに、ゲストだけのセッションとMFA状態を確実にリセットできる仕組み」を意識して設計しておくと、将来の変更にも適応しやすくなります。

「カスタムロールで全部きれいに縛る」のはまだ難しい世界ですが、組み込みロール＋管理単位＋PIMをうまく組み合わせれば、「ゲストMFA専任ヘルプデスク」という現場ニーズに十分応えられる構成を作れます。自社のライセンス状況やガバナンス要件に合わせて、少人数のテスト環境から段階的に導入してみてください。

この記事を書いた人

佐藤健司

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

Microsoft Entra IDでゲストユーザーのMFA再登録とセッション無効化だけを許可するロール設計ガイド

前提整理：やりたいこととEntra IDの実情