オンプレミスの Azure Multi-Factor Authentication Server（MFA Server）はリタイアとされており、クラウドの Microsoft Entra MFA（旧 Azure AD MFA）への移行は避けて通れません。この記事では Microsoft 公式ガイドを軸に、AD FS の要否・推奨バージョン（FBL）・必要な権限、そして段階的に切り替えるための実務的な進め方までをまとめます。
MFA Server から Azure AD MFA（Microsoft Entra MFA）へ移行すべき理由
MFA Server はオンプレミスで多要素認証を提供できる一方、Microsoft 側では新規展開の停止や廃止が明確化され、移行が強く推奨されています。Microsoft Entra 側の推奨事項では、MFA Server のリタイア日が 2024 年 9 月 30 日とされ、2019 年以降は新規展開が許可されず、2022 年に正式な廃止アナウンスが行われた旨が説明されています。
また、公式の移行概要ドキュメントでも「MFA Server は新規展開向けに提供されず、すでに非推奨であり、利用中の組織はクラウドベースの Microsoft Entra MFA へ移行すべき」という前提で整理されています（Azure AD という名称は現在 Microsoft Entra ID にリブランディングされています）。
最初に決めるべきゴール（到達点）
移行プロジェクトが炎上しやすい理由のひとつは、「MFA Server を置き換えるだけ」なのか、「ユーザー認証（サインイン）自体もクラウドへ寄せる」なのか、「AD FS も最終的に撤去する」なのかが曖昧なまま着手してしまう点です。Microsoft の移行概要では、到達点を複数パターンとして整理しています。
| 到達点 | 何が残る/何を廃止する | 向いている組織 | 難易度/効果 |
|---|---|---|---|
| MFA Server だけ廃止 | AD FS は継続。MFA プロバイダーをクラウド（Entra MFA）に置換 | AD FS 配下に業務アプリが多く、すぐに移せない | 短期で効果。中程度 |
| MFA Server 廃止 + ユーザー認証をクラウドへ | Entra ID で PHS/PTA + SSO へ寄せる。AD FS は段階的に縮小 | 中長期で “脱フェデレーション” を進めたい | 効果大。やや高 |
| MFA Server 廃止 + AD FS も廃止 | アプリ認証も Entra ID に移行し、AD FS 依存を解消 | SaaS/モダン認証へ移せるアプリが多い | 最も効果大。高 |
結論として、短期で「認証停止リスク」を潰すなら “MFA Server だけ廃止” をまず完了させ、その後にアプリ移行・AD FS 縮小へ進む二段階が現実的です（特に製造/医療/自治体のようにレガシーアプリが残りやすい環境）。
公式移行ガイドはどれを読めばよいか
Microsoft 公式の移行情報は、以下の 3 本柱で押さえるのが近道です（記事名で Microsoft Learn 内検索すると確実です）。
- 移行の全体像（前提・到達点・AD FS 推奨バージョン・権限）：Migrate from MFA Server to Microsoft Entra multifactor authentication
- ユーザーの登録情報（電話番号/Authenticator/トークン等）の同期：How to use the MFA Server Migration Utility
- オンプレ（AD FS / RADIUS）側のつなぎ込み：Configure AD FS and Microsoft Entra multifactor authentication、Use Microsoft Entra multifactor authentication with NPS
ポイントは「ユーザーの MFA 情報をクラウドに持ち上げる（Migration Utility）」と「実際の MFA 判定をクラウドに寄せる（Staged Rollout やドメイン設定変更）」が別工程になっている点です。これを混同すると、移行途中でユーザーが急に登録を求められ、ヘルプデスクがパンクします。
前提条件：AD FS は必須なのか？
結論から言うと、アプリケーションを事前にすべて Microsoft Entra ID に統合しきれていない場合、AD FS 環境が必要になるのが基本です。公式の前提条件でも「アプリを先に Entra 側へ移行しないなら AD FS 環境が必要」と明記されています。
逆に、AD FS 配下に残っているアプリを Entra ID（SAML / OpenID Connect / OAuth）へ寄せられるなら、MFA の設計は一気にシンプルになります。Microsoft の手順でも「アプリを移行する予定があるなら、MFA 移行より先にアプリ移行を行う」ことが注意書きとして示されています。
| 状況 | おすすめ方針 | 理由 |
|---|---|---|
| AD FS 配下の業務アプリが多い（SAML/OIDC へ移行困難） | AD FS を残しつつ MFA を Entra MFA に置換 | 認証経路を保ちながら MFA だけ切替しやすい |
| Microsoft 365 と一部 SaaS が中心、AD FS 依存が薄い | ユーザー認証をクラウド（PHS/PTA）へ寄せる | 運用コスト・障害点が減り、CA を活かせる |
| VPN/RDG/Citrix など RADIUS 依存が濃い | SAML 化できるものは SAML 化、難しければ NPS 拡張 | NPS は CA 非対応など制約があるため最小化したい |
AD FS のバージョン要件：推奨は Windows Server 2019 / FBL 4
公式ドキュメント上、AD FS を併用する場合の推奨は Windows Server 2019 の AD FS（Farm behavior level: FBL 4）です。理由は明快で、グループメンバーシップに基づいて認証プロバイダーを切り替えられるため、段階移行がユーザーにとってシームレスになるからです。
一方、Windows Server 2016（FBL 3）でも移行は可能ですが、移行途中のユーザーは「MFA Server か Entra MFA か、どちらのプロバイダーで認証するか」を選択するよう促され、体験が煩雑になりやすい点が公式に注意されています。
| 観点 | AD FS 2016（FBL 3） | AD FS 2019（FBL 4） |
|---|---|---|
| 段階移行のやりやすさ | 移行途中に選択を求められやすい | グループベースで切替しやすい |
| ユーザー体験 | ヘルプデスク問い合わせが増えがち | 比較的スムーズ |
| アプリごとの MFA 指定 | 制約が出やすい | 追加認証方法をアプリ（RP）単位で指定しやすい |
なお、AD FS 側で MFA を提供する前提として、AD FS は Windows Server 2016 以上が必要であることも明記されています（AD FS 依存アプリが残る場合は特に重要です）。
また AD FS 2019 を使う場合、Microsoft の AD FS + Entra MFA 構成手順では、アンカー クレーム種別を UPN へ変更する作業が必要になる点が挙げられています（既存運用への影響は基本的に限定的ですが、ログオン再要求が発生する可能性があります）。
必要な権限：どこで何が必要か（最短で迷わない整理）
移行作業は「オンプレ（AD / AD FS）」と「Entra（クラウド）」の両方で設定が発生します。公式の前提条件として、AD 側は Enterprise Administrator、Entra 側は Global Administrator が必要とされています。
一方で、実際の手順では「PowerShell で Entra 側を構成するために Application Administrator が必要」と明記されている箇所もあります。つまり、どの手順を誰が担当するかによって、必要ロールが変わります（作業分担を先に決めるのがコツです）。
| 作業 | 主な実施場所 | 必要になりやすい権限（目安） |
|---|---|---|
| AD FS ファームを Entra MFA 向けに構成 | オンプレ（AD/AD FS） | Enterprise Administrator |
| 移行機能（MFA Server → Entra）の管理 | Entra（クラウド） | Global Administrator |
| PowerShell で Entra 側を構成 | Entra（クラウド） | Application Administrator |
| MFA Server Migration Utility 用アプリ作成/同意 | Entra（クラウド） | Application Administrator（スクリプト実行時）＋管理者同意 |
| 監査ログで移行結果を確認 | Entra（クラウド） | Authentication Administrator 以上 |
特に「管理者同意（Admin consent）」や「アプリ登録」が絡む工程は、組織によってはセキュリティチームの承認フローに引っかかります。移行開始前に、申請テンプレ（目的・権限範囲・期間・ロールバック方針）まで用意しておくと手戻りが減ります。
移行前チェックリスト（ここを落とすと詰まる）
ライセンスと機能の前提
AD FS と Entra MFA を組み合わせる構成手順では、Microsoft Entra ID P1/P2（または EMS）に Entra ID と Entra MFA が含まれる旨が示されています。まずは、対象ユーザーに必要なライセンスが割り当てられているかを棚卸しします。
フェデレーションと通信要件
AD FS + Entra MFA を使う場合、オンプレ環境が Entra ID とフェデレーションされていることが前提になります。また AD FS サーバーが特定のエンドポイントへ 443 で到達できる必要がある点も明記されています（プロキシ/ファイアウォール配下では要注意です）。
| コンポーネント | 主な到達要件 | 実務メモ |
|---|---|---|
| AD FS | adnotifications.windowsazure.com / login.microsoftonline.com へ 443 | 通信経路・プロキシ例外を事前確認 |
| NPS 拡張（RADIUS 継続の場合） | Entra へ 443、RADIUS は UDP 1812/1813 等 | RADIUS クライアント⇔NPS 間のポートも忘れがち |
グループ設計（段階移行の心臓部）
段階移行は「どのユーザーをいつ切り替えるか」をグループで制御します。公式手順では、Staged Rollout 用のグループは クラウド専用（cloud-only） が推奨され、さらに ネスト（入れ子）や動的グループは非対応と明記されています。
また Staged Rollout には規模上限（最大 50 万ユーザー、最大 10 グループなど）が示されています。大規模組織は、部署・拠点単位でグループを割り切り、運用しやすい単位でロールアウト計画を作るのが安全です。
さらに重要なのが、「Migration Utility で同期するグループ」と「Staged Rollout で切り替えるグループ」を分けることです。同一グループを使うと「同期が終わる前に切り替わる」事故が起こり得るため、公式でも分離が推奨されています。
MFA Server の機能をどう置き換えるか（設計の考え方）
移行は単に「電話番号を移す」だけではありません。公式の移行概要でも、MFA Server はさまざまなシステムと統合され得るため、依存関係を評価して最適な統合方法を選ぶ必要があると説明されています。
よくある置き換えパターン
| MFA Server で使っていたもの | Entra 側の置き換え先（代表例） | 移行時の注意点 |
|---|---|---|
| 電話/SMS/Authenticator（一般的な MFA） | Entra MFA（認証方法ポリシー） | ユーザーに「登録（セキュリティ情報）」を先行させる |
| ユーザーポータルでの各種操作 | Entra の統合登録（セキュリティ情報） | 一度 Entra 側で変更するとオンプレへ同期されない前提で運用を切替 |
| RADIUS（VPN / RDG / Citrix 等） | 可能なら SAML/OIDC 化、難しければ NPS 拡張 | NPS は CA を使わず「常に MFA」になりがち、方法選択も制約 |
| LDAP 連携 | 可能ならアプリ刷新、代替検討（Entra Domain Services 等） | アプリ要件次第で “MFA そのものの設計変更” が必要 |
MFA Server Migration Utility は、オンプレに保存されている MFA データを Entra に同期し、ユーザーが再登録なしでクラウド MFA を使える状態を目指すための仕組みとして説明されています。運用上は「再登録ゼロ」を目標にしつつ、例外（古い電話番号、機種変更、退職者の残骸）を現場で拾う体制を作るのが成功の鍵です。
公式に沿った移行手順（実務向けに噛み砕いた流れ）
ステップ：依存関係の洗い出し
まずは MFA Server がどこで呼ばれているかを棚卸しします。特に多いのは以下です。
- AD FS と連携している（AD FS の MFA アダプター/プロバイダー）
- VPN / RD Gateway / Citrix など RADIUS クライアント
- 古い業務アプリが LDAP で認証プロキシ的に利用している
- ユーザーが MFA Server のユーザーポータルを使って登録/変更している
RADIUS については公式の移行概要で、まず SAML / OpenID Connect / OAuth などのモダンプロトコルへ移行できないかを検討し、難しければ NPS + 拡張機能（アダプター）で Entra MFA に接続する方針が示されています。
ステップ：AD FS を使う場合は 2019 / FBL4 を優先して整備
アプリが AD FS に残る場合、最も事故が少ないのは「AD FS 2019（FBL4）で、グループベースに認証プロバイダーを切り替える」進め方です。これにより、パイロットユーザーだけを Entra MFA に誘導し、残りは従来経路のままにできます。
ステップ：Migration Utility でユーザーの MFA 情報を同期
Migration Utility の全体像としては「オンプレの MFA データファイルをバックアップし、ツールを構成し、グループ単位でユーザーを移行し、テスト→段階ロールアウト→依存関係移行→最終切替→廃止」というフェーズ構成が示されています。
- バックアップ：オンプレ側のデータファイルをバックアップします（ロールバック手段として重要）。
- 更新とスクリプト実行：MFA Server を更新後、Migration Utility 構成スクリプトを管理者 PowerShell で実行します。
- Entra 側の権限/同意：スクリプトは Entra テナントの Application Administrator 資格情報を要求し、アプリ登録を作成してユーザーオブジェクトへ書き込む用途に使います。さらに管理者同意（Admin consent）を求める流れが示されています。
- 同期対象グループの設計：同期用グループ（Migration Utility）と切替用グループ（Staged Rollout）を分離して運用します。
運用上のコツとして、同期の初期段階では「IT 部門の少人数（テスト）」→「問い合わせ対応できる範囲のパイロット」→「部門単位の波状展開」という順で進めると、予期せぬ例外（本人確認・機種変更・海外SMS不可等）を潰しやすくなります。
ステップ：Staged Rollout で “認証経路” を段階的に切り替える
公式では、Staged Rollout を使うことで「ドメインのフェデレーション設定をいきなり変更せず、グループ単位で Entra MFA に迂回させて検証できる」流れが示されています。つまり、切替の本番影響を抑えながらテストできるのが最大の利点です。
Staged Rollout 用グループはクラウド専用で、ネスト/動的は使えない点を前提にしてください（ここを破ると “思ったユーザーが対象にならない” 事故が起きます）。
ステップ：AD FS 配下アプリがある場合の “混在期間” の作り方
AD FS 配下アプリが残る場合、公式手順では「AD FS 2019 の機能を使い、追加認証方法をグループベースで指定する」ことで、移行済みユーザーは Entra MFA、未移行ユーザーは MFA Server、といった混在運用が可能になることが説明されています。
注意点として、AD FS のアクセス制御ポリシーは “グループごとに特定の認証プロバイダーを呼ぶ” 形に向かないため、必要に応じて追加認証ルール（claims rules）ベースへ寄せる検討が必要になります。
ステップ：RADIUS（VPN/RDG 等）が残る場合は NPS 拡張を計画的に
MFA Server を RADIUS で使っている場合、公式では「まずモダン認証へ移行を検討し、無理なら NPS + Entra MFA 拡張でブリッジする」方針が示されています。
NPS 拡張には制約があります。公式の移行概要では、NPS 拡張は Conditional Access を利用しないため、RADIUS のまま運用すると NPS に到達する要求は基本的に MFA が要求される点、また ユーザーは事前に Entra MFA 登録が必要で、未登録だと失敗して問い合わせが増える点が注意として挙げられています。
ネットワーク要件としては、NPS 拡張サーバーから Entra への通信は 443 が中心で、RADIUS ポートはアクセスポイント（VPN 等）と NPS 間で必要になる、という整理が公式に掲載されています。また「NPS は RADIUS 以外の要求でエラーになり得るため、他用途と混載しないサーバーを推奨」という注意もあります。
| 通信 | プロトコル/ポート | 用途 |
|---|---|---|
| NPS → Entra | HTTPS / 443 | 拡張機能のインストール/認証 |
| RADIUS クライアント → NPS | UDP / 1812（他 1645） | 認証 |
| RADIUS クライアント → NPS | UDP / 1813（他 1646） | アカウンティング |
ステップ：最終切替（ドメイン設定変更）と廃止
ユーザー移行が完了したら、最終的に「MFA をオンプレで実行する」挙動をやめさせる必要があります。Migration Utility の手順では、ユーザー移行完了後に federatedIdpMfaBehavior のドメイン フェデレーション設定を変更し、MFA をクラウド側で処理するようにする流れが示されています。
また、依存関係（VPN 等）を移し終えた後は、ユーザーは MFA Server のポータルではなく Entra 側で認証方法を管理する運用に切り替えるべきであり、Entra 側で変更した情報はオンプレへ同期されない（ロールバック時に失われ得る）点が注意されています。
完全に不要になった段階で MFA Server を停止・撤去します。手順上は「通常のサーバー廃止プロセスに沿ってよく、Entra 側で特別な ‘廃止フラグ’ を立てる必要はない」という扱いになっています。
移行中の“現場トラブル”を減らす実践ポイント
パイロットに入れるユーザーの選び方
- 社内に常駐し、端末・スマホを自分で操作できる人（最初の 1 週間はここが大事）
- 海外出張や夜間対応が多い人は後回し（SMS/電話要因の例外が出やすい）
- 特権（管理者）アカウントは “早めにやるが、別波でやる”（一般ユーザーと要件が違う）
ユーザー案内のテンプレ（最低限伝えるべきこと）
- いつから画面/通知が変わるのか（切替日）
- 何を準備するのか（スマホ、Authenticator、予備手段）
- 「通知が来たら承認する」ではなく「自分の操作に一致する時だけ承認する」
- 失敗した時の連絡先と、本人確認の流れ
ロールバック設計（“戻せる” ではなく “戻す条件” を決める）
技術的に戻せるかどうかより、戻す条件（例：特定アプリのサインイン失敗率、ヘルプデスク件数、役員アカウントの失敗など）を事前合意しておくのが重要です。特に、Entra 側で認証方法を変更するとオンプレに同期されず、戻したときに差分が失われ得る点は公式にも注意があるため、戻し運用を “最後の手段” として扱うのが現実的です。
監視・検証：移行が進んでいるかを数字で追う
移行は「設定したら終わり」ではなく、「誰が登録済みで、誰が切り替わっていて、どこで失敗しているか」を可視化して初めて安定します。公式手順では、監査ログで Migration Utility の実行結果を追跡する手順や、登録状況をレポートで監視する考え方が示されています。
- 移行（同期）に成功しているユーザー数の推移
- Staged Rollout 対象ユーザーのサインイン失敗理由
- 認証方法（Authenticator/SMS/音声など）の登録率
- RADIUS（NPS）経由の失敗（未登録、既定方法不一致、端末未所持など）
まとめ：押さえるべき “最重要ポイント” だけ再確認
- 公式移行ガイドは Microsoft Learn に体系化されており、概要→Migration Utility→AD FS/NPS の順に読むと理解が早い。
- AD FS は、アプリを Entra に移しきれていないなら基本的に必要。
- AD FS を使うなら、Windows Server 2019 / FBL 4 が推奨（グループベースで切替でき、ユーザー体験が良い）。
- 必要権限は「AD 側：Enterprise Admin」「Entra 側：Global Admin」が基本線。ただし手順により Application Admin 等も登場するため、作業分担を前提にロールを整理する。
- 移行は段階的に。同期用グループと切替用グループは分ける。Staged Rollout はクラウド専用グループで、ネスト/動的は使わない。
- RADIUS を残すなら NPS 拡張。ただし CA 非対応など制約があるため、可能なら SAML/OIDC へ寄せる。
コメント