MFA サーバーの移行

[アーティクル]
03/25/2024

このトピックでは、Microsoft Entra ユーザーの MFA 設定をオンプレミスの Azure MFA サーバーから Microsoft Entra 多要素認証に移行する方法について説明します。

ソリューションの概要

MFA サーバー移行ユーティリティを使用すると、オンプレミスの Azure MFA Server に格納されている多要素認証データを Microsoft Entra 多要素認証に直接同期することができます。認証データが Microsoft Entra ID に移行されると、ユーザーは認証方法の再登録や確認を行うことなく、クラウドベースの MFA をシームレスに実行できます。管理者は、MFA サーバー移行ユーティリティを使用して、テナント全体の変更を行うことなく、テストと制御されたロールアウトのために単一ユーザーまたはユーザーのグループを対象にすることができます。

ビデオ: MFA Server 移行ユーティリティの使用方法

MFA サーバー移行ユーティリティの概要とそのしくみについては、ビデオをご覧ください。

制限事項と要件

MFA サーバー移行ユーティリティを利用するには、プライマリ MFA サーバーに MFA Server ソリューションの新しいビルドをインストールする必要があります。このビルドは、MFA Server データファイルを更新し、新しい MFA サーバー移行ユーティリティを含みます。 WebSDK またはユーザーポータルを更新する必要はありません。この更新をインストールしても、移行は自動的には開始 "されません"。

Note

MFA サーバー移行ユーティリティは、セカンダリ MFA サーバーで実行できます。詳細については、「セカンダリ MFA サーバーを実行する (省略可能) 」を参照してください。
MFA サーバー移行ユーティリティにより、データがデータベースファイルから Microsoft Entra ID のユーザーオブジェクトにコピーされます。移行中、段階的ロールアウトを使用して、テスト目的でユーザーを Microsoft Entra 多要素認証の対象にすることができます。段階的な移行により、ドメインフェデレーション設定を変更せずにテストできます。移行が完了したら、ドメインフェデレーション設定を変更して、移行の最終処理を行う必要があります。
Windows Server 2016 以降を実行している AD FS が、AD FS 証明書利用者 (Microsoft Entra ID と Office 365 は含みません) に対する MFA 認証を提供するために必要です。
AD FS アクセス制御ポリシーを確認し、認証プロセスの一環として MFA をオンプレミスで実行する必要があるものがないことを確認します。
段階的ロールアウトでは、最大 500,000 人のユーザー (それぞれ最大 50,000 人のユーザーを含む 10 グループ) を対象にすることができます。

移行ガイド

段階	手順
準備	Azure Multi-Factor Authentication Server の依存関係を特定する
	Azure Multi-Factor Authentication Server データファイルをバックアップする
	MFA Server の更新プログラムをインストールする
	MFA サーバー移行ユーティリティを構成する
移行	ユーザーデータの移行
	検証とテスト
	段階的ロールアウト
	ユーザーを教育する
	ユーザーの移行を完了する
最終	MFA Server の依存関係を移行する
	ドメインフェデレーション設定を更新する
	MFA Server のユーザーポータルを無効にする
	MFA サーバーの使用を停止する

MFA サーバーの移行には、通常、次のプロセスの手順が含まれます。

MFA サーバーの移行フェーズの図。

重要なポイントをいくつか以下に示します。

フェーズ 1 は、テストユーザーを追加するときに繰り返す必要があります。

移行ツールでは、Microsoft Entra グループを使用して、MFA Server と Microsoft Entra 多要素認証の間で認証データを同期する必要があるユーザーを決定します。ユーザーデータが同期されると、そのユーザーは Microsoft Entra 多要素認証を使用できるようになります。
段階的ロールアウトでは、Microsoft Entra グループも使用して、ユーザーを Microsoft Entra 多要素認証に再ルーティングできます。もちろん両方のツールで同じグループを使用できますが、場合によっては、ツールでデータが同期される前にユーザーが Microsoft Entra 多要素認証にリダイレクトされる可能性があるため、そうしないことをお勧めします。 MFA サーバー移行ユーティリティによって認証データを同期するための Microsoft Entra グループと、対象ユーザーをオンプレミスではなく Microsoft Entra 多要素認証に誘導する段階的ロールアウト用の別のグループセットを設定することをお勧めします。

フェーズ 2 は、ユーザーベースを移行するときに繰り返す必要があります。フェーズ 2 が終了するまでに、ユーザーベース全体が Microsoft Entra ID に対してフェデレーションされたすべてのワークロードに対して Microsoft Entra 多要素認証を使用するようになるはずです。

前のフェーズでは、段階的ロールアウトフォルダーからユーザーを削除して、ユーザーを Microsoft Entra 多要素認証の範囲から外し、Microsoft Entra ID から発信されるすべての MFA 要求に対してオンプレミスの Azure MFA サーバーにルーティングし戻すことができます。

フェーズ 3 では、オンプレミスの MFA Server に対して認証するすべてのクライアント (VPN、パスワードマネージャーなど) を、SAML または OAUTH 経由の Microsoft Entra フェデレーションに移す必要があります。先進認証の標準がサポートされていない場合は、Microsoft Entra 多要素認証の拡張機能がインストールされた NPS サーバーを立ち上げる必要があります。依存関係が移行されたら、ユーザーは MFA Server 上のユーザーポータルを使用しなくなりますが、Microsoft Entra ID (aka.ms/mfasetup) で認証方法を管理する必要があります。ユーザーが Microsoft Entra ID で認証データの管理を開始すると、それらの方法は MFA Server に同期されなくなります。ユーザーが Microsoft Entra ID で認証方法に変更を加えた後にオンプレミスの MFA Server にロールバックすると、それらの変更は失われます。ユーザーの移行が完了したら、federatedIdpMfaBehavior ドメインフェデレーション設定を変更します。この変更により、Microsoft Entra ID に対して、グループメンバーシップに関係なく、今後オンプレミスで MFA を実行せず、Microsoft Entra 多要素認証を使用してすべての MFA 要求を実行するように指示が出されます。

次のセクションでは、移行手順について詳しく説明します。

Azure Multi-Factor Authentication Server の依存関係を特定する

Microsoft は、クラウドベースの Microsoft Entra 多要素認証ソリューションへの移行によってセキュリティ体制が維持され、さらには強化されるように努めてきました。依存関係のグループ化に使用する必要がある 3 つの大きなカテゴリがあります。

MFA 方法
ユーザーポータル
認証サービス

移行を支援するために、カテゴリごとに、広く使用されている MFA Server 機能を、Microsoft Entra 多要素認証の同等機能に対応させています。

MFA 方法

MFA Server を開き、[会社の設定] をクリックします。

[会社の設定] のスクリーンショット。

MFA サーバー	Microsoft Entra 多要素認証
[全般] タブ
[ユーザーの既定値] セクション
電話 (標準)	操作は不要です
テキストメッセージ (OTP)^*	操作は不要です
モバイルアプリ (標準)	操作は不要です
電話 (PIN)^*	音声の OTP を有効にします
テキストメッセージ (OTP + PIN)^**	操作は不要です
モバイルアプリ (PIN)^*	数値の一致を有効にします
電話、テキストメッセージ、モバイルアプリ、または OATH トークンの言語	言語設定は、ブラウザーのロケール設定に基づいてユーザーに自動的に適用されます
[既定の PIN の規則] セクション	該当なし。前のスクリーンショットの更新された方法を参照してください
[ユーザー名の解決] タブ	適用されません。Microsoft Entra 多要素認証にはユーザー名の解決は必要ありません
[テキストメッセージ] タブ	適用されません。Microsoft Entra 多要素認証では、テキストメッセージに既定のメッセージが使用されます
[OATH トークン] タブ	適用されません。Microsoft Entra 多要素認証では、OATH トークンに既定のメッセージが使用されます
レポート	Microsoft Entra 認証方法アクティビティレポート

^*存在証明機能を提供するために PIN が使用される場合は、同等の機能が上記で提供されます。デバイスに暗号化されて関連付けられていない PIN では、デバイスが侵害されたシナリオから十分に保護されません。 SIM スワップ攻撃を含む、これらのシナリオから保護するには、Microsoft の認証方法のベストプラクティスに従って、より安全な方法にユーザーを移します。

^**Microsoft Entra 多要素認証の既定のテキスト MFA エクスペリエンスでは、認証の一環としてログインウィンドウに入力する必要があるコードがユーザーに送信されます。コードをラウンドトリップする要求により、存在証明機能が提供されます。

ユーザーポータル

MFA Server を開き、[ユーザーポータル] をクリックします。

[ユーザーポータル] のスクリーンショット。

MFA サーバー	Microsoft Entra 多要素認証
[設定] タブ
ユーザーポータルの URL	aka.ms/mfasetup
ユーザー登録を許可する	統合されたセキュリティ情報の登録に関する記事を参照してください
- 予備の電話番号の入力を求めるプロンプト	「MFA サービスの設定」を参照してください
- サードパーティ OATH トークンの入力を求めるプロンプト	「MFA サービスの設定」を参照してください
ユーザーにワンタイムバイパスの開始を許可する	「MICROSOFT ENTRA ID TAP 機能」を参照してください
ユーザーに認証方法の選択を許可する	「MFA サービスの設定」を参照してください
- 電話	電話に関するドキュメントを参照してください
- テキストメッセージ	「MFA サービスの設定」を参照してください
- モバイルアプリ	「MFA サービスの設定」を参照してください
- OATH トークン	OATH トークンに関するドキュメントを参照してください
ユーザーに言語の選択を許可する	言語設定は、ブラウザーのロケール設定に基づいてユーザーに自動的に適用されます
ユーザーにモバイルアプリのアクティブ化を許可する	「MFA サービスの設定」を参照してください
- デバイスの上限	Microsoft Entra ID では、ユーザー当たりの累積デバイスを 5 つ (モバイルアプリインスタンス + ハードウェア OATH トークン + ソフトウェア OATH トークン) に制限しています
代替認証にセキュリティの質問を使用する	Microsoft Entra ID で、ユーザーは、認証時に選択した認証方法が失敗した場合のフォールバック方法を選択できます
- 回答する質問数	Microsoft Entra ID のセキュリティの質問は、SSPR にのみ使用できます。 Microsoft Entra でのカスタムのセキュリティに関する質問について詳細を参照してください
ユーザーにサードパーティ製の OATH トークンの関連付けを許可する	OATH トークンに関するドキュメントを参照してください
代替認証に OATH トークンを使用する	OATH トークンに関するドキュメントを参照してください
セッションのタイムアウト
[セキュリティの質問] タブ	MFA Server のセキュリティの質問は、ユーザーポータルにアクセスするために使用されました。 Microsoft Entra多要素認証では、セルフサービスパスワードリセットに関するセキュリティの質問のみがサポートされます。セキュリティの質問に関するドキュメントを参照してください。
[渡されたセッション] タブ	認証方法の登録フローはすべて Microsoft Entra ID によって管理され、構成は必要ありません
信頼できる IP	Microsoft Entra ID の信頼された IP

MFA Server で使用できる MFA 方法は、MFA サービス設定を使用して Microsoft Entra 多要素認証で有効にする必要があります。ユーザーは、新しく移行された MFA 方法を有効にしない限り、試すことはできません。

認証サービス

Azure MFA Server は、認証プロキシとして機能することで、RADIUS または LDAP を使用するサードパーティ製ソリューションに MFA 機能を提供できます。 RADIUS または LDAP の依存関係を検出するには、MFA Server の [RADIUS 認証] および [LDAP 認証] オプションをクリックします。その依存関係ごとに、これらのサードパーティが先進認証をサポートしているかどうかを確認します。その場合は、Microsoft Entra ID を使用して直接フェデレーションすることを検討してください。

アップグレードできない RADIUS デプロイの場合は、NPS サーバーをデプロイし、Microsoft Entra 多要素認証 NPS 拡張機能をインストールする必要があります。

アップグレードも RADIUS への移動もできない LDAP デプロイの場合は、Microsoft Entra ドメインサービスを使用できるかどうかを確認します。ほとんどの場合、LDAP はエンドユーザーのインラインでのパスワード変更をサポートするためにデプロイされました。移行後、エンドユーザーは Microsoft Entra ID のセルフサービスパスワードリセットを使用してパスワードを管理できます。

Office 365 証明書利用者信頼を除く、証明書利用者信頼に対して AD FS 2.0 の MFA Server 認証プロバイダーを有効にした場合は、AD FS 3.0 にアップグレードするか、それらの証明書利用者を Microsoft Entra ID に直接フェデレーションする必要があります (利用者が先進認証方法をサポートしている場合)。各依存関係に最適なアクション計画を決定してください。

Azure Multi-Factor Authentication Server データファイルをバックアップする

プライマリ MFA サーバー上の %programfiles%\Multi-Factor Authentication Server\Data\PhoneFactor.pfdata (既定の場所) にある MFA Server データファイルのバックアップを作成します。ロールバックする必要がある場合に備えて、現在インストールされているバージョンのインストーラーのコピーがあることを確認してください。コピーがなくなった場合は、カスタマーサポートサービスに連絡してください。

ユーザーアクティビティによっては、データファイルがすぐに古くなる可能性があります。 MFA Server に加えられた変更、またはバックアップ後にポータルを通じて行われたエンドユーザーの変更はキャプチャされません。ロールバックした場合、この時点以降に行われた変更は復元されません。

MFA Server の更新プログラムをインストールする

プライマリ MFA サーバーで新しいインストーラーを実行します。サーバーをアップグレードする前に、他の MFA サーバーとの負荷分散やトラフィック共有から削除する必要があります。インストーラーを実行する前に、現在の MFA Server をアンインストールする必要はありません。インストーラーは、現在のインストールパス (例: C:\Program Files\Multi-Factor Authentication Server) を使用してインプレースアップグレードを実行します。 Microsoft Visual C++ 2015 再頒布可能 Update パッケージのインストールを求められた場合は、受け入れます。パッケージの x86 バージョンと x64 バージョンの両方がインストールされます。ユーザーポータル、Web SDK、AD FS アダプターの更新プログラムをインストールする必要はありません。

注意

プライマリサーバーでインストーラーを実行した後、セカンダリサーバーで [Unhandled SB] (ハンドルされない SB) エントリのログが開始される場合があります。これは、セカンダリサーバーによって認識されない、プライマリサーバーで行われたスキーマの変更が原因です。このエラーは想定されています。ユーザー数が 10,000 人を超える環境では、ログエントリの量が大幅に増加する可能性があります。この問題を軽減するには、MFA Server ログのファイルサイズを増やすか、セカンダリサーバーをアップグレードします。

MFA サーバー移行ユーティリティを構成する

MFA Server の更新プログラムをインストールした後、管理者特権の PowerShell コマンドプロンプトを開きます。PowerShell アイコンをポイントし、右クリックして [管理者として実行] をクリックします。 MFA Server のインストールディレクトリ (既定では C:\Program Files\Multi-Factor Authentication Server) にある .\Configure-MultiFactorAuthMigrationUtility.ps1 スクリプトを実行します。

このスクリプトでは、Microsoft Entra テナントのアプリケーション管理者の資格情報を指定する必要があります。その後、スクリプトによって Microsoft Entra ID 内に新しい MFA サーバー移行ユーティリティアプリケーションが作成されます。これは、各 Microsoft Entra ユーザーオブジェクトにユーザー認証方法を書き込むために使用されます。

政府機関向けクラウドのお客様が移行を実行する場合は、スクリプト内の ".com" エントリを ".us" に置き換えてください。その後、このスクリプトは、HKLM:\SOFTWARE\WOW6432Node\Positive Networks\PhoneFactor\ StsUrl および GraphUrl のレジストリエントリの書き込みを行い、移行ユーティリティに適切な GRAPH エンドポイントを使用するように指示します。

また、次の URL へのアクセス権も必要です。

https://graph.microsoft.com/* (または、政府機関向けクラウドのお客様の場合は https://graph.microsoft.us/*)
https://login.microsoftonline.com/* (または、政府機関向けクラウドのお客様の場合は https://login.microsoftonline.us/*)

新しく作成されたアプリケーションに管理者の同意を与えるように、スクリプトから指示があります。指定された URL に移動するか、Microsoft Entra 管理センター内で [アプリケーション登録] をクリックし、[MFA サーバー移行ユーティリティ] アプリを見つけて選択し、[API のアクセス許可] をクリックしてから、適切なアクセス許可を付与します。

アクセス許可のスクリーンショット。

完了したら、Multi-Factor Authentication Server フォルダーに移動し、MultiFactorAuthMigrationUtilityUI アプリケーションを開きます。次の画面が表示されます。

MFA サーバー移行ユーティリティのスクリーンショット。

移行ユーティリティが正常にインストールされました。

注意

MFA サーバーがテナント参照のない MFA プロバイダーに関連付けられている場合、移行中に動作が変更されないようにするために、移行するテナントの既定の MFA 設定 (カスタムあいさつなど) を MFA プロバイダーの設定と一致するように更新する必要があります。これは、ユーザーを移行する前に行うことをお勧めします。

セカンダリ MFA サーバーを実行する (省略可能)

実際の MFA Server で多数のユーザーがいる場合、またはプライマリ MFA サーバーがビジー状態になる場合、MFA Server 移行ユーティリティと移行同期サービスを実行するために専用のセカンダリ MFA サーバーをデプロイすることを検討してください。プライマリ MFA サーバーをアップグレードした後、既存のセカンダリサーバーをアップグレードするか、新しいセカンダリサーバーをデプロイします。選択したセカンダリサーバーが他の MFA トラフィックを処理しないようにする必要があります。

MFA Server 移行ユーティリティのアプリの登録に証明書を登録するために、Configure-MultiFactorAuthMigrationUtility.ps1 スクリプトをセカンダリサーバーで実行する必要があります。証明書は、Microsoft Graph に対する認証に使用されます。セカンダリ MFA サーバーで移行ユーティリティと同期サービスを実行すると、手動と自動の両方のユーザー移行でパフォーマンスが向上します。

ユーザーデータの移行

ユーザーデータを移行しても、Multi-Factor Authentication Server データベース内のデータは削除も変更もされません。同様に、このプロセスでユーザーが MFA を実行する場所は変更されません。このプロセスは、オンプレミスサーバーから Microsoft Entra ID の対応するユーザーオブジェクトへのデータの一方向コピーです。

MFA サーバー移行ユーティリティは、すべての移行アクティビティに対して 1 つの Microsoft Entra グループを対象とします。このグループにユーザーを直接追加することも、他のグループを追加することもできます。移行中にそれらを段階的に追加することもできます。

移行プロセスを開始するには、移行する Microsoft Entra グループの名前または GUID を入力します。完了したら、Tab キーを押すか、ウィンドウの外側をクリックすると、適切なグループの検索が開始されます。グループ内のすべてのユーザーが設定されます。大規模なグループの場合、完了には数分かかることがあります。

ユーザー属性データを表示するには、ユーザーを強調表示して、[表示] を選択します。

ユーザー設定の表示方法を示すスクリーンショット。

このウィンドウには、選択したユーザーの属性が Microsoft Entra ID とオンプレミス MFA Server の両方で表示されます。このウィンドウを使用して、移行後にデータがユーザーにどのように書き込まれたかを表示できます。

[設定] オプションを使用すると、移行プロセスの設定を変更できます。

設定のスクリーンショット。

移行 - ユーザーの既定の認証方法を移行するには、次の 3 つのオプションがあります。
- 常に移行する
- Microsoft Entra ID にまだ設定されていない場合にのみ移行する
- Microsoft Entra ID でまだ設定されていない場合は、使用可能な最も安全な方法に設定する
これらのオプションがあるので、既定の方法を移行するときに柔軟に対応できます。さらに、移行中に認証方法ポリシーが確認されます。移行対象の既定の方法がポリシーで許可されていない場合は、代わりに使用できる最も安全な方法に設定されます。
ユーザー照合 – userPrincipalName に対する既定の照合ではなく、Microsoft Entra UPN を照合するための別の Windows Server Active Directory 属性を指定できます。
- 移行ユーティリティは、オンプレミスの Active Directory 属性を使用する前に UPN への直接照合を試みます。
- 一致するものが見つからない場合は、Windows API を呼び出して Microsoft Entra UPN を検索し、MFA Server ユーザーリストの検索に使用する SID を取得します。
- Windows API でユーザーが見つからない場合、または SID が MFA サーバーで見つからない場合は、構成された Active Directory 属性を使用してオンプレミスの Active Directory 内のユーザーを検索し、SID を使用して MFA サーバーのユーザー一覧を検索します。
自動同期 – オンプレミスの MFA サーバー内のユーザーに対する認証方法の変更を継続的に監視し、定義された指定の時間間隔で Microsoft Entra ID に書き込むバックグラウンドサービスを開始します。
同期サーバー – MFA サーバーの移行同期サービスをプライマリでのみ実行するのではなく、セカンダリ MFA サーバーで実行できるようにします。セカンダリサーバーで実行するように移行同期サービスを構成するには、MFA サーバー移行ユーティリティアプリの登録を使用して証明書を登録するために、Configure-MultiFactorAuthMigrationUtility.ps1 スクリプトをサーバー上で実行する必要があります。証明書は、Microsoft Graph に対する認証に使用されます。

移行プロセスは自動または手動にできます。

手動プロセスの手順は次のとおりです。

1 人のユーザーまたは複数ユーザーの選択の移行プロセスを開始するには、Ctrl キーを押しながら、移行する各ユーザーを選択します。
目的のユーザーを選択したら、[Migrate Users] (ユーザーの移行)>[選択したユーザー]>[OK] をクリックします。
グループ内のすべてのユーザーを移行するには、[Migrate Users] (ユーザーの移行)>[All users in Microsoft Entra group] (Microsoft Entra グループ内のすべてのユーザー)>[OK] をクリックします。
変更されていない場合でも、ユーザーを移行できます。既定では、ユーティリティは [Only migrate users that have changed] (変更されたユーザーのみを移行する) に設定されています。 [Migrate all users] (すべてのユーザーを移行する) をクリックして、変更されていない以前に移行したユーザーを再移行します。変更されていないユーザーの移行は、管理者がユーザーの Azure MFA 設定をリセットする必要があり、それらを再移行する必要がある場合のテスト中に役立ちます。

自動プロセスの場合は、[設定] で [自動同期] をクリックし、すべてのユーザーを同期するか、特定の Microsoft Entra グループのメンバーのみにするかを選択します。

次の表に、さまざまな方法の同期ロジックを示します。

メソッド	ロジック
電話	内線番号がない場合は、MFA 電話を更新します。内線番号がある場合は、会社電話を更新します。例外: 既定の方法がテキストメッセージの場合は、内線番号を除去して MFA 電話を更新します。
予備の電話番号	内線番号がない場合は、代替の電話を更新します。内線番号がある場合は、会社電話を更新します。例外: 電話と予備の電話番号の両方に内線番号がある場合、予備の電話番号をスキップします。
モバイルアプリ	最大 5 台のデバイスが移行されます。ユーザーがハードウェア OATH トークンを持っている場合は 4 つだけです。同じ名前のデバイスが複数ある場合は、最新のものだけを移行します。デバイスは、新しい順に並べ替えられます。デバイスが Microsoft Entra ID に既に存在する場合は、OATH トークン秘密鍵で照合し、更新します。 - OATH トークン秘密鍵に一致するものがない場合は、デバイストークンで照合します -- 見つかった場合は、MFA Server デバイス用のソフトウェア OATH トークンを作成して、OATH トークン方法を機能させることができます。通知は、既存の Microsoft Entra 多要素認証デバイスを使用して引き続き機能します。 -- 見つからない場合は、新しいデバイスを作成します。新しいデバイスの追加が 5 つのデバイスの上限を超える場合、そのデバイスはスキップされます。
OATH トークン	デバイスが Microsoft Entra ID に既に存在する場合は、OATH トークン秘密鍵で照合し、更新します。 - 見つからない場合は、新しいハードウェア OATH トークンデバイスを追加します。新しいデバイスの追加が 5 つのデバイスの上限を超える場合、その OATH トークンはスキップされます。

MFA 方法は、移行された内容に基づいて更新され、既定の方法が設定されます。 MFA Server は、最後の移行タイムスタンプを追跡し、ユーザーの MFA 設定が変更されたか、管理者が [設定] ダイアログで移行する内容を変更した場合にのみ、再度ユーザーを移行します。

テスト中は、最初に手動での移行を行うことをお勧めします。そして、特定の数のユーザーが想定どおりに動作することを確認するためにテストしてください。テストが成功したら、移行する Microsoft Entra グループの自動同期を有効にします。このグループにユーザーを追加すると、その情報は Microsoft Entra ID に自動的に同期されます。 MFA サーバー移行ユーティリティは 1 つの Microsoft Entra グループを対象としますが、そのグループにはユーザーと、入れ子になったユーザーグループの両方を含めることができます。

完了すると、タスク完了の確認メッセージが通知されます。

確認のスクリーンショット。

確認メッセージで言及されているように、移行されたデータが Microsoft Entra ID 内のユーザーオブジェクトに表示されるまで数分かかることがあります。ユーザーは、aka.ms/mfasetup に移動して、移行した方法を表示できます。

ヒント

Microsoft Entra MFA メソッドを表示する必要がない場合は、グループを表示するのに必要な時間を短縮できます。 [表示]>[Azure AD MFA メソッド] をクリックして、[AAD の既定値]、[AAD 電話]、[AAD の代替]、[AAD Office]、[AAD デバイス]、[AAD OATH トークン] の列の表示を切り替えます。列を非表示にすると、Microsoft Graph API 呼び出しの一部がスキップされるため、ユーザーのロード時間が大幅に短縮されます。

移行の詳細

監査ログまたは Log Analytics を使用して、MFA Server から Azure MFA へのユーザー移行の詳細を表示できます。

監査ログを使用する

Microsoft Entra 管理センターで監査ログにアクセスして MFA Server から Azure MFA へのユーザー移行の詳細を表示するには、次の手順に従います:

認証管理者以上の権限で Microsoft Entra 管理センターにサインインします。
[ID]>[監視と正常性]>[監査ログ] の順に移動します。ログをフィルター処理するには、[フィルターの追加] をクリックします。
開始者 (アクター) を選択し、適用をクリックします。
「Azure MFA Management」と入力し、[適用] をクリックします。

このフィルターには、MFA Server 移行ユーティリティログのみが表示されます。ユーザー移行の詳細を表示するには、行をクリックし、[変更されたプロパティ] タブを選択します。このタブには、登録されている MFA 方法と電話番号の変更が表示されます。

ユーザー移行の詳細のスクリーンショット。

次の表に、各コードの認証方法を示します。

コード	方法
0	Voice モバイル
2	Voice オフィス
3	Voice 代替モバイル
5	SMS
6	Microsoft Authenticator プッシュ通知
7	ハードウェアまたはソフトウェアトークン OTP

ユーザーデバイスが移行された場合は、別のログエントリがあります。

Log Analytics の使用

Log Analytics を使用して MFA Server から Azure MFA へのユーザー移行の詳細をクエリすることもできます。

AuditLogs
| where ActivityDateTime > ago(7d)
| extend InitiatedBy = tostring(InitiatedBy["app"]["displayName"])
| where InitiatedBy == "Azure MFA Management"
| extend UserObjectId = tostring(TargetResources[0]["id"])
| extend Upn = tostring(TargetResources[0]["userPrincipalName"])
| extend ModifiedProperties = TargetResources[0]["modifiedProperties"]
| project ActivityDateTime, InitiatedBy, UserObjectId, Upn, ModifiedProperties
| order by ActivityDateTime asc

このスクリーンショットは、ユーザー移行の変更を示しています。

移行したユーザーに対する Log Analytics のスクリーンショット。

このスクリーンショットは、デバイス移行の変更を示しています。

移行したデバイスに対する Log Analytics のスクリーンショット。

Log Analytics を使用して、ユーザー移行アクティビティを集計することもできます。

AuditLogs
| where ActivityDateTime > ago(7d)
| extend InitiatedBy = tostring(InitiatedBy["app"]["displayName"])
| where InitiatedBy == "Azure MFA Management"
| extend UserObjectId = tostring(TargetResources[0]["id"])
| summarize UsersMigrated = dcount(UserObjectId) by InitiatedBy, bin(ActivityDateTime, 1d)

Log Analytics 集計のスクリーンショット。

検証とテスト

ユーザーデータを正常に移行したら、グローバルテナントを変更する前に、段階的ロールアウトを使用してエンドユーザーエクスペリエンスを検証できます。次のプロセスでは、MFA の段階的ロールアウトに対して特定の Microsoft Entra グループを対象にすることができます。段階的ロールアウトは、対象グループ内のユーザーをオンプレミスに送信して MFA を実行するのではなく、それらのユーザーに Microsoft Entra 多要素認証を使用して MFA を実行するように Microsoft Entra ID に指示します。検証とテストには Microsoft Entra 管理センターを使用できます (推奨) が、必要に応じて Microsoft Graph を使用することもできます。

段階的なロールアウトを有効にする

次の URL 段階的ロールアウト機能を有効にする - Microsoft Azure に移動します。
[Azure multifactor authentication] (Azure 多要素認証) を [オン] に変更し、[グループの管理] をクリックします。
[グループの追加] をクリックし、Azure MFA のために有効にするユーザーを含むグループを追加します。選択したグループが、表示されている一覧に入ります。

注意

以下の Microsoft Graph メソッドを使用して対象とするグループも、この一覧に表示されます。

Microsoft Graph を使用して段階的ロールアウトを有効にする

featureRolloutPolicy を作成します
1. aka.ms/ge に移動し、段階的ロールアウトについて設定するテナントのハイブリッド ID 管理者アカウントを使用して Graph Explorer にログインします。
2. 次のエンドポイントをターゲットとして POST が選択されていることを確認します: https://graph.microsoft.com/v1.0/policies/featureRolloutPolicies
3. 要求の本文には、以下が含まれている必要があります (「MFA ロールアウトポリシー」は組織の名前と説明に変更してください)。
```
{
     "displayName": "MFA rollout policy",
     "description": "MFA rollout policy",
     "feature": "multiFactorAuthentication",
     "isEnabled": true,
     "isAppliedToOrganization": false
}
```
4. 同じエンドポイントで GET を実行し、ID 値 (次の図で横線が引かれています) を書き留めます。
テストするユーザーを含む Microsoft Entra ID グループを対象にします
1. 次のエンドポイントで POST 要求を作成します ({ID of policy} は、手順 1d からコピーした ID 値に置き換えてください)。
  
  https://graph.microsoft.com/v1.0/policies/featureRolloutPolicies/{ID of policy}/appliesTo/$ref
2. 要求の本文には、以下が含まれている必要があります ({ID of group} は、段階的ロールアウトの対象にするグループのオブジェクト ID に置き換えてください)。
```
{
"@odata.id": "https://graph.microsoft.com/v1.0/directoryObjects/{ID of group}"
}
```
3. 段階的ロールアウトで対象にする他のグループすべてに対して、手順 a と b を繰り返します。
4. 現在設定されているポリシーを表示するには、次の URL に対して GET を実行します。
  
  https://graph.microsoft.com/v1.0/policies/featureRolloutPolicies/{policyID}?$expand=appliesTo
  
  上記のプロセスでは featureRolloutPolicy リソースを使用します。まだパブリックドキュメントは新しい multifactorAuthentication 機能で更新されていませんが、API を操作する方法に関する詳細な情報が記載されています。
エンドユーザーの MFA エクスペリエンスを確認します。確認できることがいくつかあります。
1. ユーザーには aka.ms/mfasetup で自分の方法が表示されますか?
2. ユーザーは電話またはテキストメッセージを受信しますか?
3. ユーザーは上記の方法を使用して正常に認証できますか?
4. ユーザーは Authenticator 通知を正常に受信しますか? ユーザーはこれらの通知を承認できますか? 認証は成功しますか?
5. ユーザーはハードウェア OATH トークンを使用して正常に認証できますか?

ユーザーを教育する

新しい認証フローを含め、ユーザーが Azure MFA に移動されたときに想定されることを各自が把握するようにします。移行が完了したら、ユーザーポータルではなく、Microsoft Entra ID 統合登録ポータル (aka.ms/mfasetup) を使用して認証方法を管理するようにユーザーに指示することもできます。 Microsoft Entra ID の認証方法に加えられた変更は、オンプレミス環境には反映されません。 MFA Server にロールバックする必要があった状況では、ユーザーが Microsoft Entra ID で行った変更内容は、MFA Server ユーザーポータルで利用できません。

Azure MFA Server に依存するサードパーティ製ソリューションを認証に使用する場合 (「認証サービス」を参照) は、ユーザーがユーザーポータルで自分の MFA 方法を引き続き変更できるようにする必要があります。これらの変更は、Microsoft Entra ID に自動的に同期されます。これらのサードパーティ製ソリューションを移行したら、Microsoft Entra ID 統合登録ページにユーザーを移動できます。

ユーザーの移行を完了する

すべてのユーザーデータが移行されるまで、「ユーザーデータの移行」および「検証とテスト」セクションに記載されている移行手順を繰り返します。

MFA Server の依存関係を移行する

認証サービスで収集したデータポイントを使用して、移行に必要不可欠なさまざまな実行を開始します。これが完了したら、MFA サーバーのユーザーポータルではなく、統合登録ポータルでユーザーに認証方法を管理してもらうことを検討します。

ドメインフェデレーション設定を更新する

ユーザーの移行を完了し、すべての認証サービスを MFA Server から移動したら、ドメインフェデレーション設定を更新します。更新後、Microsoft Entra はオンプレミスのフェデレーションサーバーに MFA 要求を送信しなくなります。

オンプレミスのフェデレーションサーバーへの MFA 要求を無視するように Microsoft Entra ID を構成するには、Microsoft Graph PowerShell SDK をインストールし、次の例に示すように federatedIdpMfaBehavior を rejectMfaByFederatedIdp に設定します。

要求

PATCH https://graph.microsoft.com/beta/domains/contoso.com/federationConfiguration/6601d14b-d113-8f64-fda2-9b5ddda18ecc
Content-Type: application/json
{
  "federatedIdpMfaBehavior": "rejectMfaByFederatedIdp"
}

Response

注: ここに示されている応答オブジェクトは、読みやすくするために短縮されている可能性があります。

HTTP/1.1 200 OK
Content-Type: application/json
{
  "@odata.type": "#microsoft.graph.internalDomainFederation",
  "id": "6601d14b-d113-8f64-fda2-9b5ddda18ecc",
   "issuerUri": "http://contoso.com/adfs/services/trust",
   "metadataExchangeUri": "https://sts.contoso.com/adfs/services/trust/mex",
   "signingCertificate": "MIIE3jCCAsagAwIBAgIQQcyDaZz3MI",
   "passiveSignInUri": "https://sts.contoso.com/adfs/ls",
   "preferredAuthenticationProtocol": "wsFed",
   "activeSignInUri": "https://sts.contoso.com/adfs/services/trust/2005/usernamemixed",
   "signOutUri": "https://sts.contoso.com/adfs/ls",
   "promptLoginBehavior": "nativeSupport",
   "isSignedAuthenticationRequestRequired": true,
   "nextSigningCertificate": "MIIE3jCCAsagAwIBAgIQQcyDaZz3MI",
   "signingCertificateUpdateStatus": {
        "certificateUpdateResult": "Success",
        "lastRunDateTime": "2021-08-25T07:44:46.2616778Z"
    },
   "federatedIdpMfaBehavior": "rejectMfaByFederatedIdp"
}

ユーザーは、段階的ロールアウトツールで対象とされているかどうかに関係なく、MFA のためにオンプレミスフェデレーションサーバーにリダイレクトされなくなります。これが有効になるまでに最大で 24 時間がかかることに注意してください。

注意

ドメインフェデレーション設定の更新が有効になるまでに最大 24 時間かかることがあります。

省略可能: MFA Server ユーザーポータルを無効にする

すべてのユーザーデータの移行が完了したら、エンドユーザーは MFA 方法を管理するために Microsoft Entra ID 統合登録ページの使用を開始できます。ユーザーが MFA Server のユーザーポータルを使用できないようにするには、いくつかの方法があります。

MFA Server ユーザーポータルの URL を aka.ms/mfasetup にリダイレクトする
MFA Server の [ユーザーポータル] セクションにある [設定] タブで [ユーザーにログインを許可する] チェックボックスをオフにして、ポータルにユーザーが全くログインできないようにする。

MFA Server の使用を停止する

Azure MFA サーバーが不要になったら、通常のサーバー廃止手法に従ってください。 Microsoft Entra ID では、MFA Server の廃止を指示するために特別な操作は必要ありません。

ロールバック計画

アップグレードで問題が発生した場合は、次の手順に従ってロールバックします。

MFA Server 8.1 をアンインストールします。
PhoneFactor.pfdata を、アップグレード前に作成したバックアップに置き換えます。

注意

バックアップが行われた後の変更はすべて失われますが、バックアップがアップグレード直前に行われて、アップグレードが失敗した場合は、最小限であるはずです。
以前のバージョン (8.0.x.x など) のインストーラーを実行します。

オンプレミスのフェデレーションサーバーに対する MFA 要求を受け入れるように Microsoft Entra ID を構成します。 Graph PowerShell を使用して、次の例に示すように、federatedIdpMfaBehavior を enforceMfaByFederatedIdp に設定します。

Request

PATCH https://graph.microsoft.com/beta/domains/contoso.com/federationConfiguration/6601d14b-d113-8f64-fda2-9b5ddda18ecc
Content-Type: application/json
{
  "federatedIdpMfaBehavior": "enforceMfaByFederatedIdp"
}

読みやすくするために、次の応答オブジェクトが短縮されます。

Response

HTTP/1.1 200 OK
Content-Type: application/json
{
  "@odata.type": "#microsoft.graph.internalDomainFederation",
  "id": "6601d14b-d113-8f64-fda2-9b5ddda18ecc",
   "issuerUri": "http://contoso.com/adfs/services/trust",
   "metadataExchangeUri": "https://sts.contoso.com/adfs/services/trust/mex",
   "signingCertificate": "MIIE3jCCAsagAwIBAgIQQcyDaZz3MI",
   "passiveSignInUri": "https://sts.contoso.com/adfs/ls",
   "preferredAuthenticationProtocol": "wsFed",
   "activeSignInUri": "https://sts.contoso.com/adfs/services/trust/2005/usernamemixed",
   "signOutUri": "https://sts.contoso.com/adfs/ls",
   "promptLoginBehavior": "nativeSupport",
   "isSignedAuthenticationRequestRequired": true,
   "nextSigningCertificate": "MIIE3jCCAsagAwIBAgIQQcyDaZz3MI",
   "signingCertificateUpdateStatus": {
        "certificateUpdateResult": "Success",
        "lastRunDateTime": "2021-08-25T07:44:46.2616778Z"
    },
   "federatedIdpMfaBehavior": "enforceMfaByFederatedIdp"
}

[Staged Rollout for Azure MFA] (Azure MFA の段階的ロールアウト) を [オフ] に設定します。ユーザーは、MFA のためにオンプレミスのフェデレーションサーバーに再びリダイレクトされるようになります。

MFA サーバーの移行

ソリューションの概要

ビデオ: MFA Server 移行ユーティリティの使用方法

制限事項と要件

移行ガイド

Azure Multi-Factor Authentication Server の依存関係を特定する

MFA 方法

ユーザーポータル

認証サービス

Azure Multi-Factor Authentication Server データファイルをバックアップする

MFA Server の更新プログラムをインストールする

MFA サーバー移行ユーティリティを構成する

セカンダリ MFA サーバーを実行する (省略可能)

ユーザーデータの移行

移行の詳細

監査ログを使用する

Log Analytics の使用

検証とテスト

段階的なロールアウトを有効にする

Microsoft Graph を使用して段階的ロールアウトを有効にする

ユーザーを教育する

ユーザーの移行を完了する

MFA Server の依存関係を移行する

ドメインフェデレーション設定を更新する

要求

Response

省略可能: MFA Server ユーザーポータルを無効にする

MFA Server の使用を停止する

ロールバック計画

次のステップ

その他のリソース

MFA サーバーの移行

ソリューションの概要

ビデオ: MFA Server 移行ユーティリティの使用方法

制限事項と要件

移行ガイド

Azure Multi-Factor Authentication Server の依存関係を特定する

MFA 方法

ユーザー ポータル

認証サービス

Azure Multi-Factor Authentication Server データファイルをバックアップする

MFA Server の更新プログラムをインストールする

MFA サーバー移行ユーティリティを構成する

セカンダリ MFA サーバーを実行する (省略可能)

ユーザー データの移行

移行の詳細

監査ログを使用する

Log Analytics の使用

検証とテスト

段階的なロールアウトを有効にする

Microsoft Graph を使用して段階的ロールアウトを有効にする

ユーザーを教育する

ユーザーの移行を完了する

MFA Server の依存関係を移行する

ドメイン フェデレーション設定を更新する

要求

Response

省略可能: MFA Server ユーザー ポータルを無効にする

MFA Server の使用を停止する

ロールバック計画

次のステップ

その他のリソース

ユーザーポータル

ユーザーデータの移行

ドメインフェデレーション設定を更新する

省略可能: MFA Server ユーザーポータルを無効にする