次の方法で共有

MFA サーバーから Microsoft Entra 多要素認証に移行する

  • [アーティクル]

多要素認証は、インフラストラクチャと資産を不正ユーザーからセキュリティで保護するために重要です。 Azure Multi-Factor Authentication Server (MFA Server) は、新しいデプロイには利用不可であり、かつ非推奨です。 MFA サーバーを使っているお客様は、クラウドベースの Microsoft Entra 多要素認証の使用に移行する必要があります。

この記事は、次のようなハイブリッド環境があることを前提としています。

  • 多要素認証のために MFA Server を使用している。
  • Active Directory フェデレーション サービス (AD FS) または別の ID プロバイダー フェデレーション製品によるフェデレーションを Microsoft Entra ID で使っている。
    • この記事の対象は AD FS ですが、他の ID プロバイダーにも同様の手順が適用されます。
  • MFA Server が AD FS と統合されている。
  • 認証に AD FS を使用しているアプリケーションがある場合がある。

目標に応じて、移行について複数の最終状態が考えられます。


 目標: MFA Server のみの使用を停止する 目標: MFA サーバーの使用を停止し、Microsoft Entra 認証に移行する 目標: MFA Server と AD FS の使用を停止する
MFA プロバイダー MFA プロバイダーを MFA サーバーから Microsoft Entra 多要素認証に変更します。 MFA プロバイダーを MFA サーバーから Microsoft Entra 多要素認証に変更します。 MFA プロバイダーを MFA サーバーから Microsoft Entra 多要素認証に変更します。
ユーザー認証 Microsoft Entra 認証には引き続きフェデレーションを使います。 パスワード ハッシュ同期 (優先) またはパススルー認証およびシームレスなシングル サインオン (SSO) を備えた Microsoft Entra ID に移行します。 パスワード ハッシュ同期 (優先) またはパススルー認証および SSO を備えた Microsoft Entra ID に移行します。
アプリケーション認証 アプリケーション に AD FS 認証を引き続き使用します。 アプリケーション に AD FS 認証を引き続き使用します。 Microsoft Entra 多要素認証に移行する前に、アプリを Microsoft Entra ID に移行します。

可能な場合は、多要素認証とユーザー認証の両方を Azure に移行します。 詳細な手順のガイダンスについては、Microsoft Entra 多要素認証と Microsoft Entra ユーザー認証への移行に関する記事を参照してください。

ユーザー認証を移行できない場合は、フェデレーションを使って Microsoft Entra 多要素認証に移行するための詳細な手順のガイダンスを参照してください。

前提条件

  • AD FS 環境 (MFA Server を移行する前に、すべてのアプリを Microsoft Entra に移行しない場合に必要)
    • AD FS for Windows Server 2019、ファーム動作レベル (FBL) 4 にアップグレードします。 このアップグレードにより、グループ メンバーシップに基づいて認証プロバイダーを選択でき、移行がユーザーに対してよりシームレスになります。 AD FS for Windows Server 2016 FBL 3 でも移行は可能ですが、この移行はユーザーに対してシームレスではありません。 移行中は、移行が完了するまで、認証プロバイダー (MFA サーバーまたは Microsoft Entra 多要素認証) を選ぶように求めるメッセージがユーザーに表示されます。
  • アクセス許可
    • Microsoft Entra 多要素認証の AD FS ファームを構成するための Active Directory のエンタープライズ管理者ロール
    • この機能を管理するには、全体管理者が必要です。

すべての移行パスに関する考慮事項

MFA サーバーから Microsoft Entra 多要素認証に移行するには、登録されている MFA 電話番号を移行するだけでは不十分です。 Microsoft の MFA サーバーは多くのシステムと統合できます。Microsoft Entra 多要素認証と統合するための最適な方法を理解するために、これらのシステムで MFA サーバーがどのように使われているかを評価する必要があります。

MFA ユーザー情報を移行する

ユーザーを一括で移行する場合の一般的な考え方には、リージョン、部署、または管理者などのロールによるユーザーの移行が含まれます。 テストおよびパイロット グループから始めて、ユーザー アカウントを反復的に移動し、必ずロールバック計画を準備してください。

MFA サーバー移行ユーティリティを使用して、オンプレミスの Azure MFA Server 内に格納されている MFA データを Microsoft Entra 多要素認証と同期し、段階的ロールアウトを使用してユーザーを Microsoft Entra 多要素認証に再ルーティングできます。 段階的ロールアウトを使用すると、ドメイン フェデレーション設定を変更せずにテストできます。

MFA Server にリンクされている古いアカウントと新しく追加したアカウントをユーザーが区別できるようにするには、MFA Server 上のモバイル アプリのアカウント名が、2 つのアカウントを区別できる名前になっている必要があります。 たとえば、MFA Server の [モバイル アプリ] の下に表示されるアカウント名がオンプレミス MFA Server に変更されているとします。 Microsoft Authenticator のアカウント名は、次にユーザーにプッシュ通知されると変更されます。

電話番号を移行すると、古い番号が移行される可能性があり、パスワードレス モードの Microsoft Authenticator サインインなど、安全な方法を設定する代わりに、ユーザーが電話ベースの MFA を使用し続ける可能性があります。 したがって、選択した移行パスに関係なく、統合されたセキュリティ情報をすべてのユーザーに登録してもらうことをお勧めします。

ハードウェア セキュリティ キーを移行する

Microsoft Entra ID では、ハードウェア OATH トークンのサポートが提供されています。 MFA サーバー移行ユーティリティを使うと、MFA サーバーと Microsoft Entra 多要素認証の間で MFA 設定を同期し、段階的ロールアウトを使って、ドメイン フェデレーション設定を変更せずにユーザーの移行をテストできます。

ハードウェア OATH トークンのみを移行する場合は、一般に "シード ファイル" と呼ばれる CSV ファイルを使用して Microsoft Entra ID にトークンをアップロードする必要があります。 シード ファイルには、シークレット キー、トークンのシリアル番号、トークンを Microsoft Entra ID にアップロードするために必要なその他の情報が含まれます。

シークレット キーが含まれるシード ファイルがなくなると、MFA Server からシークレット キーをエクスポートできません。 シークレット キーにアクセスできなくなった場合のサポートについては、ハードウェア ベンダーにお問い合せください。

MFA Server Web サービス SDK を使用すると、特定のユーザーに割り当てられた OATH トークンのシリアル番号をエクスポートできます。 この情報とシード ファイルを使って、トークンを Microsoft Entra ID にインポートし、シリアル番号に基づいて、指定されたユーザーに OATH トークンを割り当てることができます。 デバイスから OTP 情報を指定して登録を完了するように、インポート時にユーザーに通知する必要があります。 MFA Server 上のヘルプ ファイルのトピック [GetUserInfo]>[userSettings]>[OathTokenSerialNumber] を参照してください。

その他の移行

MFA サーバーから Microsoft Entra 多要素認証への移行を決定すると、その他の移行も可能になります。 その他の移行を実行できるかどうかは、多くの要因 (特に以下の要因) によって決まります。

  • ユーザーに対して Microsoft Entra 認証を使う意図がある
  • アプリケーションを Microsoft Entra ID に移行する意図がある

MFA Server はアプリケーションとユーザー認証の両方に不可欠であるため、MFA 移行の一環として、これらの機能の両方を Azure に移行し、最終的に AD FS の使用を停止することを検討してください。

推奨事項:

  • 堅牢なセキュリティとガバナンスが可能になるため、Microsoft Entra ID を認証に使う
  • 可能であればアプリケーションを Microsoft Entra ID に移行します

組織に最適なユーザー認証方法を選択するには、「Microsoft Entra ハイブリッド ID ソリューションの適切な認証方法を選ぶ」を参照してください。 パスワード ハッシュ同期 (PHS) を使用することをお勧めします。

パスワードレスの認証

2 つ目の要素として Microsoft Authenticator を使用するユーザーの登録の一環として、パスワードレスの電話でのサインインを有効にすることをお勧めします。 FIDO2 セキュリティ キーや Windows Hello for Business などの他のパスワードレスの方法を含む詳細については、「Microsoft Entra ID でパスワードレス認証のデプロイを計画する」を参照してください。

Microsoft Identity Manager セルフサービス パスワード リセット

Microsoft Identity Manager (MIM) SSPR では、MFA Server を使用して、パスワード リセット フローの一部として SMS ワンタイム パスコードを呼び出すことができます。 MIM は、Microsoft Entra 多要素認証を使うように構成することはできません。 SSPR サービスの Microsoft Entra SSPR への移行を検討することをお勧めします。 ユーザーが Microsoft Entra 多要素認証に登録する機会を利用し、統合された登録エクスペリエンスを使って Microsoft Entra SSPR に登録することができます。

SSPR サービスを移動できない場合、または MFA Server を使用して Privileged Access Management (PAM) シナリオの MFA 要求を呼び出す場合は、代替のサード パーティ MFA オプションに更新することをお勧めします。

RADIUS クライアントと Microsoft Entra 多要素認証

MFA Server は、RADIUS プロトコルをサポートするアプリケーションとネットワーク デバイスに対して多要素認証を呼び出すことができるように、この RADIUS をサポートしています。 RADIUS と MFA サーバーを使っている場合は、クライアント アプリケーションを最新のプロトコル (SAML、OpenID Connect、Microsoft Entra ID の OAuth など) に移行することをお勧めします。 アプリケーションを更新できない場合、ネットワーク ポリシー サーバー (NPS) と Microsoft Entra 多要素認証拡張機能をデプロイできます。 ネットワーク ポリシー サーバー (NPS) 拡張機能は、RADIUS ベースのアプリケーションと Microsoft Entra 多要素認証の間のアダプターとして機能し、認証の 2 番目の要素を提供します。 この "アダプター" により、RADIUS クライアントを Microsoft Entra 多要素認証に移行でき、MFA サーバーの使用を停止できます。

重要な考慮事項

RADIUS クライアントに NPS を使用する場合は制限があるため、RADIUS クライアントを評価して、最新の認証プロトコルにアップグレードできるかどうかを判断することをお勧めします。 サポートされている製品のバージョンとそれらの機能については、サービス プロバイダーに確認してください。

  • NPS 拡張機能では、Microsoft Entra 条件付きアクセス ポリシーは使われません。 RADIUS の使用を継続し、NPS 拡張機能を使用する場合、NPS に送信されるすべての認証要求でユーザーが MFA を実行する必要があります。
  • ユーザーは、NPS 拡張機能を使用する前に、Microsoft Entra 多要素認証に登録する必要があります。 そうしないと、拡張機能はユーザーの認証に失敗し、ヘルプ デスクの呼び出しが生成される場合があります。
  • NPS 拡張機能で MFA が呼び出されると、MFA 要求がユーザーの既定の MFA メソッドに送信されます。
    • サインインは Microsoft 以外のアプリケーションで行われるため、多要素認証が必要であること、および要求がデバイスに送信されたことを知らせる視覚的通知が、多くの場合はユーザーに表示されません。
    • 多要素認証の要件を満たすために、この要件の期間中、ユーザーは既定の認証方法にアクセスできる必要があります。 別の方法を選択することはできません。 既定の認証方法は、テナントの認証方法と多要素認証のポリシーで無効になっている場合でも使用されます。
    • ユーザーは、[セキュリティ情報] ページで既定の多要素認証方法を変更できます (aka.ms/mysecurityinfo)。
  • RADIUS クライアントで使用可能な MFA メソッドは、RADIUS アクセス要求を送信するクライアント システムによって制御されます。
    • パスワードを入力した後にユーザー入力が必要になる MFA メソッドは、RADIUS を使用したアクセス チャレンジ応答をサポートするシステムでのみ使用できます。 入力方式には、OTP、ハードウェア OATH トークン、または Microsoft Authenticator などがあります。
    • 一部のシステムでは、使用可能な多要素認証方法が Microsoft Authenticator プッシュ通知と電話呼び出しに制限される場合があります。

注意

RADIUS クライアントと NPS システムの間で使用されるパスワード暗号化アルゴリズムと、クライアントが使用できる入力方式によって、使用できる認証方法が決まります。 詳細については、ユーザーが使用できる認証方法の決定に関するページを参照してください。

一般的な RADIUS クライアントの統合には、リモート デスクトップ ゲートウェイや VPN サーバーなどのアプリケーションが含まれます。 その他の統合を次に示します。

  • Citrix Gateway
    • Citrix Gateway では、RADIUS と NPS の両方の拡張機能の統合と、SAML 統合がサポートされています。
  • Cisco VPN
    • Cisco VPN では、SSO の RADIUS 認証と SAML 認証の両方がサポートされています。
    • RADIUS 認証から SAML に移行すると、NPS 拡張機能をデプロイすることなく、Cisco VPN を統合できます。
  • すべての VPN

NPS のデプロイに関するリソース

次のステップ