ネットワーク ポリシー サーバー (NPS) 拡張機能と Microsoft Entra ID を使用して、リモート デスクトップ ゲートウェイ インフラストラクチャを統合する
この記事では、Microsoft Azure のネットワーク ポリシー サーバー (NPS) 拡張機能を使用して、リモート デスクトップ ゲートウェイ インフラストラクチャを Microsoft Entra 多要素認証と統合する方法について詳しく説明します。
Azure のネットワーク ポリシー サーバー (NPS) 拡張機能を使用すると、Azure のクラウドベースの 多要素認証 を使用して、リモート認証ダイヤルイン ユーザー サービス (RADIUS) クライアント認証を保護することができます。 このソリューションは、ユーザーのサインインとトランザクションにセキュリティの第 2 レイヤーを追加するための 2 段階認証を提供します。
この記事では、Azure の NPS 拡張機能を使用して、NPS インフラストラクチャを Microsoft Entra 多要素認証と統合する手順について順を追って説明します。 これにより、リモート デスクトップ ゲートウェイにサインインしようとするユーザーを確実に検証できるようになります。
Note
この記事は MFA サーバーのデプロイでは使用せず、Microsoft Entra 多要素認証 (クラウドベース) のデプロイのみで使用してください。
ネットワーク ポリシーとアクセス サービス (NPS) により、組織は次のことができるようになります。
- 接続できるユーザー、接続が許可される時間帯、接続の期間、クライアントが接続に使用する必要があるセキュリティのレベルなどを指定して、ネットワーク要求を管理および制御するための集約された場所をそれぞれ定義できます。 これらのポリシーは、VPN またはリモート デスクトップ (RD) ゲートウェイ サーバーごとに指定するのではなく、集約された場所で一度に指定できます。 RADIUS プロトコルは、一元化された認証、承認、アカウンティング (AAA) を提供します。
- デバイスにネットワーク リソースへの無制限のアクセスを許可するか制限付きアクセスを許可するかを決定する、ネットワーク アクセス保護 (NAP) クライアント正常性ポリシーを制定し、強制できます。
- 802.1x 対応ワイヤレス アクセス ポイントとイーサネット スイッチへのアクセスに認証と承認を強制する手段を提供できます。
一般に、組織では NPS (RADIUS) を使用して VPN ポリシーの管理を簡素化し、一元化しています。 にもかかわらず、多くの組織が、NPS を使用してリモート デスクトップの接続承認ポリシー (RD CAP) の管理も簡素化し、一元化しています。
組織は、NPS を Microsoft Entra 多要素認証と統合して、セキュリティを強化し、高レベルのコンプライアンスを提供することもできます。 このことは、リモート デスクトップ ゲートウェイにサインインする際の 2 段階認証をユーザーが確実に制定するための助けとなります。 ユーザーはアクセスの許可を得るために、ユーザー名/パスワードの組み合わせをユーザーが独自に管理している情報と共に提供する必要があります。 この情報は、信頼性があり、簡単に複製できないもの (携帯電話番号、固定電話番号、モバイル デバイス上のアプリケーションなど) である必要があります。 RDG では現在、2FA のために通話と Microsoft 認証アプリ メソッドからの [承認]/[拒否] プッシュ通知をサポートしています。 サポートされている認証方法の詳細については、ユーザーが使用できる認証方法の決定に関するセクションを参照してください。
組織でリモート デスクトップ ゲートウェイを使っていて、ユーザーが Authenticator のプッシュ通知と共に TOTP コードを登録している場合、ユーザーは MFA チャレンジを満たすことができず、リモート デスクトップ ゲートウェイでのサインインに失敗します。 この場合、OVERRIDE_NUMBER_MATCHING_WITH_TOP = FALSE と設定することで、Authenticator による承認/拒否のプッシュ通知にフォールバックできます。
NPS 拡張機能がリモート デスクトップ ゲートウェイ ユーザーに対して動作し続けるには、NPS サーバー上にこのレジストリ キーを作成する必要があります。 NPS サーバーで、レジストリ エディターを開きます。 次に移動します。
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AzureMfa
以下の文字列と値のペアを作成します。
名前: OVERRIDE_NUMBER_MATCHING_WITH_OTP
値 = FALSE
Azure の NPS 拡張機能を利用できるようになる前は、NPS と Microsoft Entra 多要素認証を統合した環境の 2 段階検証の実装を希望するお客様は、「RADIUS を使用したリモート デスクトップ ゲートウェイと Azure Multi-Factor Authentication Server」に記載されているように、オンプレミス環境に別の MFA サーバーを構成し、保守する必要がありました。
Azure の NPS 拡張機能の登場により、オンプレミス ベースの MFA ソリューションとクラウド ベースの MFA ソリューションのどちらを RADIUS クライアント認証の保護用にデプロイするかを組織が選択できるようになりました。
認証フロー
ユーザーは、リモート デスクトップ ゲートウェイ経由でのネットワーク リソースへのアクセスの許可を得るために、1 つの RD 接続承認ポリシー (RD CAP) と 1 つの RD リソース承認ポリシー (RD RAP) で指定された条件を満たす必要があります。 RD CAP では、RD ゲートウェイへの接続を許可するユーザーを指定します。 RD RAP では、ユーザーに RD ゲートウェイ経由での接続を許可するネットワーク リソース (リモート デスクトップやリモート アプリなど) を指定します。
RD ゲートウェイは、RD CAP に集約型ポリシー ストアを使用するように構成できます。 RD RAP は RD ゲートウェイで処理されるので、集約型ポリシーを使用することはできません。 RD CAP に集約型ポリシー ストアを使用するように構成された RD ゲートウェイの例として、セントラル ポリシー ストアとして機能する別の NPS サーバーの RADIUS クライアントがあります。
Azure の NPS 拡張機能を NPS およびリモート デスクトップ ゲートウェイと統合した場合、正常な認証フローは次のようになります。
- リモート デスクトップ ゲートウェイ サーバーが、リソース (リモート デスクトップ セッションなど) に接続するための認証要求をリモート デスクトップ ユーザーから受信します。 RADIUS クライアントとして機能するリモート デスクトップ ゲートウェイ サーバーは、要求を RADIUS Access-Request メッセージに変換し、NPS 拡張機能がインストールされている RADIUS (NPS) サーバーにメッセージを送信します。
- Active Directory でユーザー名とパスワードの組み合わせが検証され、ユーザーが認証されます。
- NPS 接続要求とネットワーク ポリシーで指定されているすべての条件 (時刻やグループ メンバーシップの制約など) が満たされていれば、NPS 拡張機能によって、Microsoft Entra 多要素認証を使用したセカンダリ認証の要求がトリガーされます。
- Microsoft Entra 多要素認証は、Microsoft Entra ID と通信してユーザーの詳細を取得し、サポートされている方法を使用してセカンダリ認証を実行します。
- MFA チャレンジが成功すると、Microsoft Entra 多要素認証は結果を NPS 拡張機能に送信します。
- 拡張機能がインストールされている NPS サーバーは、RD CAP ポリシーの RADIUS Access-Accept メッセージをリモート デスクトップ ゲートウェイ サーバーに送信します。
- ユーザーは、要求したネットワーク リソースへの RD ゲートウェイ経由でのアクセスを許可されます。
前提条件
このセクションでは、Microsoft Entra 多要素認証をリモート デスクトップ ゲートウェイと統合する前に必要な前提条件について詳しく説明します。 作業を開始する前に、次の前提条件を満たしておく必要があります。
- リモート デスクトップ サービス (RDS) インフラストラクチャ
- Microsoft Entra 多要素認証ライセンス
- Windows Server ソフトウェア
- ネットワーク ポリシーとアクセス サービス (NPS) のロール
- オンプレミスの Active Directory と同期された Microsoft Entra
- Microsoft Entra GUID ID
リモート デスクトップ サービス (RDS) インフラストラクチャ
正常に稼働しているリモート デスクトップ サービス (RDS) インフラストラクチャが必要です。 このインフラストラクチャがない場合は、Create Remote Desktop Session Collection deployment (リモート デスクトップ セッション コレクション デプロイの作成)というクイックスタート テンプレートを使用して、Azure 上に簡単に作成できます。
テストのためにオンプレミスの RDS インフラストラクチャを手動ですばやく作成したい場合は、これをデプロイする手順に従います。 詳細情報: Azure クイックスタートを使用した RDS のデプロイと基本的な RDS インフラストラクチャのデプロイ。
Windows Server ソフトウェア
NPS 拡張機能を使用するには、NPS 役割サービスがインストールされた Windows Server 2008 R2 SP1 以上が必要です。 このセクションの手順はすべて Windows Server 2016 を使用して実行されました。
ネットワーク ポリシーとアクセス サービス (NPS) のロール
NPS 役割サービスは、RADIUS サーバー/クライアントの機能とネットワーク アクセス ポリシー正常性サービスを提供します。 この役割は、インフラストラクチャ内の少なくとも 2 台のコンピューター (リモート デスクトップ ゲートウェイと別のメンバー サーバーまたはドメイン コントローラー) にインストールする必要があります。 既定では、この役割はリモート デスクトップ ゲートウェイとして構成されているコンピューターに既に存在します。 また、ドメイン コントローラーやメンバー サーバーなど、別のコンピューターにも NPS の役割をインストールする必要があります。
Windows Server 2012 以前に NPS 役割サービスをインストールする方法については、「Install a NAP Health Policy Server (NAP 正常性ポリシー サーバーのインストール)」をご覧ください。 NPS をドメイン コントローラーにインストールする際の推奨事項など、NPS のベスト プラクティスについては、「Best Practices for NPS (NPS のベスト プラクティス)」をご覧ください。
オンプレミスの Active Directory と同期された Microsoft Entra
NPS 拡張機能を使用するには、オンプレミスのユーザーを Microsoft Entra ID と同期し、ユーザーの MFA を有効にする必要があります。 このセクションでは、AD Connect を使用してオンプレミスのユーザーが Microsoft Entra ID と同期されていることを前提としています。 Microsoft Entra Connect については、オンプレミスのディレクトリと Microsoft Entra ID の統合に関する記事を参照してください。
Microsoft Entra GUID ID
NPS 拡張機能をインストールするには、Microsoft Entra ID の GUID を知っている必要があります。 Microsoft Entra ID の GUID を確認する手順については後ほど説明します。
多要素認証を構成する
このセクションでは、Microsoft Entra 多要素認証をリモート デスクトップ ゲートウェイと統合する手順について説明します。 管理者は、ユーザーがその多要素認証デバイスまたはアプリケーションを自己登録する前に、Microsoft Entra 多要素認証サービスを構成する必要があります。
クラウドでの Microsoft Entra ID 多要素認証の使用開始に関する記事の手順に従って、Microsoft Entra ユーザーの MFA を有効にします。
2 段階認証用にアカウントを構成する
アカウントの MFA を有効にすると、2 段階認証を使用して認証される 2 つ目の認証要素に使用する信頼済みデバイスの構成を正常に完了するまで、MFA ポリシーによって管理されたリソースにはサインインできません。
Microsoft Entra 多要素認証を使用する理由に関する記事の手順に従って、ユーザー アカウントを使用して MFA 用にデバイスを正しく構成する方法を理解し、構成します。
重要
リモート デスクトップ ゲートウェイのサイン動作では、Microsoft Entra 多要素認証で確認コードを入力するオプションは提供されません。 ユーザー アカウントが電話確認、または [承認]/[拒否] プッシュ通知による Microsoft Authenticator アプリ用に構成されている必要があります。
電話確認と Microsoft Authenticator アプリのどちらでもユーザーに対して 承認/拒否プッシュ通知が構成されていない場合、そのユーザーは、Microsoft Entra 多要素認証チャレンジを完了してリモート デスクトップ ゲートウェイにサインインすることはできません。
確認コードを入力する手段がないため、SMS テキストはリモート デスクトップ ゲートウェイには使用できません。
NPS 拡張機能のインストールと構成
このセクションでは、リモート デスクトップ ゲートウェイでのクライアント認証に Microsoft Entra 多要素認証を使用するように RDS インフラストラクチャを構成する手順について説明します。
ディレクトリ テナント ID を取得する
ヒント
この記事の手順は、開始するポータルによって若干異なる場合があります。
NPS 拡張機能の構成の一環として、管理者資格情報と Microsoft Entra テナントの ID を入力する必要があります。 テナント ID を取得するには、次の手順のようにします。
Microsoft Entra 管理センターにサインインします。
[ID]>[設定] の順に進みます。
NPS 拡張機能のインストール
ネットワーク ポリシーとアクセス サービス (NPS) の役割がインストールされているサーバーに NPS 拡張機能をインストールします。 これが、設計で RADIUS サーバーとして機能します。
重要
リモート デスクトップ ゲートウェイ (RDG) サーバーには NPS 拡張機能をインストールしないでください。 RDG サーバーはそのクライアントと共に RADIUS プロトコルを使用しないため、この拡張機能では MFA を解釈して実行することができません。
RDG サーバーと、NPS 拡張機能を備えた NPS サーバーが異なるサーバーである場合、RDG は NPS を内部で使用して他の NPS サーバーと通信し、RADIUS をプロトコルとして使用して正しく通信します。
- NPS 拡張機能をダウンロードします。
- セットアップ実行可能ファイル (NpsExtnForAzureMfaInstaller.exe) を NPS サーバーにコピーします。
- NPS サーバーで NpsExtnForAzureMfaInstaller.exe をダブルクリックします。 メッセージが表示されたら、 [実行] をクリックします。
- [Microsoft Entra 多要素認証の NPS 拡張機能のセットアップ] ダイアログ ボックスで、[ライセンス条項と条件に同意します。] チェック ボックスをオンにして、[インストール] をクリックします。
- [Microsoft Entra 多要素認証の NPS 拡張機能のセットアップ] ダイアログ ボックスで、[閉じる] をクリックします。
PowerShell スクリプトを使用して NPS 拡張機能で使用する証明書を構成する
次に、セキュリティで保護された通信と保証を確保するために、NPS 拡張機能で使用する証明書を構成する必要があります。 NPS コンポーネントには、NPS で使用する自己署名証明書を構成する PowerShell スクリプトが含まれています。
このスクリプトは、次のアクションを実行します。
- 自己署名証明書を作成する
- 資格情報の公開キーを Microsoft Entra ID のサービス プリンシパルに関連付ける
- ローカル コンピューターのストアに証明書を格納する
- ネットワーク ユーザーに証明書の秘密キーへのアクセスを許可する
- ネットワーク ポリシー サーバー サービスを再起動する
独自の証明書を使用する場合は、証明書の公開キーを Microsoft Entra ID のサービス プリンシパルに関連付けるなどの手順を行う必要があります。
スクリプトを使用するには、Microsoft Entra 管理者の資格情報と、先ほどコピーした Microsoft Entra テナント ID を拡張機能に提供します。 NPS 拡張機能がインストールされている各 NPS サーバーでスクリプトを実行します。 次に、次を実行します。
管理用の Windows PowerShell プロンプトを開きます。
PowerShell プロンプトで「
cd 'c:\Program Files\Microsoft\AzureMfa\Config'
」と入力し、Enter キーを押します。「
.\AzureMfaNpsExtnConfigSetup.ps1
」と入力して Enter キーを押します。 このスクリプトで、PowerShell モジュールがインストールされているかどうかがチェックされます。 インストールされていない場合は、スクリプトによってモジュールがインストールされます。PowerShell モジュールのインストールの確認後、PowerShell モジュールのダイアログ ボックスが表示されます。 ダイアログ ボックスで、Microsoft Entra 管理者の資格情報とパスワードを入力し、[サインイン] をクリックします。
メッセージが表示されたら、先ほどクリップボードにコピーした "テナント ID" を貼り付け、ENTER キーを押します。
スクリプトによって自己署名証明書が作成され、他の構成変更が実行されます。
リモート デスクトップ ゲートウェイでの NPS コンポーネントの構成
このセクションでは、リモート デスクトップ ゲートウェイの接続承認ポリシーと他の RADIUS 設定を構成します。
認証フローでは、リモート デスクトップ ゲートウェイと、NPS 拡張機能がインストールされている NPS サーバー間で RADIUS メッセージを交換する必要があります。 つまり、リモート デスクトップ ゲートウェイと NPS 拡張機能がインストールされている NPS サーバーの両方で RADIUS クライアント設定を構成する必要があります。
セントラル ストアを使用するようにリモート デスクトップ ゲートウェイの接続承認ポリシーを構成する
リモート デスクトップの接続承認ポリシー (RD CAP) では、リモート デスクトップ ゲートウェイ サーバーに接続するための要件を指定します。 RD CAP は、ローカルに保存することも (既定)、NPS を実行している RD CAP のセントラル ストアに保存することもできます。 Microsoft Entra 多要素認証と RDS の統合を構成するには、セントラル ストアの使用を指定する必要があります。
RD ゲートウェイ サーバーでサーバー マネージャーを開きます。
メニューの [ツール] をクリックし、 [リモート デスクトップ サービス] をポイントして、 [リモート デスクトップ ゲートウェイ マネージャー] をクリックします。
RD ゲートウェイ マネージャーで、[<サーバー名> (ローカル)] を右クリックし、[プロパティ] をクリックします。
プロパティ ダイアログ ボックスで、 [RD CAP ストア] タブを選択します。
[RD CAP ストア] タブで、 [NPS を実行するセントラル サーバー] を選択します。
[NPS を実行するサーバーの名前または IP アドレスの入力] フィールドに、NPS 拡張機能がインストールされているサーバーの IP アドレスまたはサーバー名を入力します。
追加をクリックします。
[共有シークレット] ダイアログ ボックスで、共有シークレットを入力し、 [OK] をクリックします。 この共有シークレットを記録し、記録を安全な場所に保管してください。
Note
共有シークレットは、RADIUS サーバーと RADIUS クライアント間の信頼を確立するために使用されます。 長い複雑なシークレットを作成してください。
[OK] をクリックしてダイアログ ボックスを閉じます。
リモート デスクトップ ゲートウェイの NPS で RADIUS のタイムアウト値を構成する
RADIUS のタイムアウト値を調整して、ユーザーの資格情報の検証、2 段階認証の実行、応答の受信、RADIUS メッセージへの応答の実行に必要な時間を確保する必要があります。
RD ゲートウェイ サーバーでサーバー マネージャーを開きます。 メニューで [ツール] をクリックし、 [ネットワーク ポリシー サーバー] をクリックします。
[NPS (ローカル)] コンソールで、 [RADIUS クライアントとサーバー] を展開し、 [Remote RADIUS Server](リモート RADIUS サーバー) を選択します。
詳細ウィンドウで、 [TS GATEWAY SERVER GROUP] をダブルクリックします。
Note
この RADIUS サーバー グループは、NPS ポリシーのセントラル サーバーを構成したときに作成されました。 RD ゲートウェイは、このサーバーまたはサーバーのグループ (グループに複数のサーバーが含まれている場合) に RADIUS メッセージを転送します。
[TS GATEWAY SERVER GROUP のプロパティ] ダイアログ ボックスで、RD CAP を保存するように構成した NPS サーバーの IP アドレスまたは名前を選択し、 [編集] をクリックします。
[RADIUS サーバーの編集] ダイアログ ボックスで、 [負荷分散] タブを選択します。
[負荷分散] タブの [要求が破棄されたとみなされる応答待ち時間 (秒数)] フィールドで、既定値の 3 を 30 ~ 60 秒の値に変更します。
[サーバーが利用不可能とみなされる要求間隔 (秒数)] フィールドで、既定値の 30 秒を、前の手順で指定した値以上の値に変更します。
[OK] を 2 回クリックして、ダイアログ ボックスを閉じます。
接続要求ポリシーを確認する
既定では、接続承認ポリシーに集約型ポリシー ストアを使用するように RD ゲートウェイを構成すると、CAP 要求を NPS サーバーに転送するように RD ゲートウェイが構成されます。 Microsoft Entra 多要素認証拡張機能がインストールされている NPS サーバーで、RADIUS アクセス要求が処理されます。 次の手順は、既定の接続要求ポリシーを確認する方法を示しています。
RD ゲートウェイの [NPS (ローカル)] コンソールで、 [ポリシー] を展開し、 [接続要求ポリシー] を選択します。
[TS GATEWAY AUTHORIZATION POLICY] をダブルクリックします。
[TS GATEWAY AUTHORIZATION POLICY のプロパティ] ダイアログ ボックスで、 [設定] タブをクリックします。
[設定] タブで、[接続要求の転送] の [認証] をクリックします。 認証のために要求を転送するように RADIUS クライアントが構成されています。
[キャンセル] をクリックします。
Note
接続要求ポリシーの作成の詳細については、記事「接続要求ポリシーの構成」のドキュメントを参照してください。
NPS 拡張機能がインストールされているサーバーでの NPS の構成
NPS 拡張機能がインストールされている NPS サーバーは、リモート デスクトップ ゲートウェイの NPS サーバーと RADIUS メッセージを交換できる必要があります。 このメッセージ交換を可能にするには、NPS 拡張サービスがインストールされているサーバーで NPS コンポーネントを構成する必要があります。
Active Directory にサーバーを登録する
このシナリオで正常に機能させるには、NPS サーバーを Active Directory に登録する必要があります。
NPS サーバーで、サーバー マネージャーを開きます。
サーバー マネージャーで [ツール] をクリックし、 [ネットワーク ポリシー サーバー] をクリックします。
[ネットワーク ポリシー サーバー] コンソールで、 [NPS (ローカル)] を右クリックし、 [Active Directory にサーバーを登録] をクリックします。
[OK] を 2 回クリックします。
次の手順で使用するため、コンソールは開いたままにしておきます。
RADIUS クライアントを作成して構成する
リモート デスクトップ ゲートウェイは、NPS サーバーの RADIUS クライアントとして構成する必要があります。
NPS 拡張機能がインストールされている NPS サーバーで、 [NPS (ローカル)] コンソールの [RADIUS クライアント] を右クリックし、 [新規] をクリックします。
[新しい RADIUS クライアント] ダイアログ ボックスで、リモート デスクトップ ゲートウェイ サーバーのフレンドリ名 (例: Gateway) と、IP アドレスまたは DNS 名を指定します。
[共有シークレット] フィールドと [共有シークレットの確認入力] フィールドに、前に使用したシークレットを入力します。
[OK] をクリックして、[新しい RADIUS クライアント] ダイアログ ボックスを閉じます。
ネットワーク ポリシーを構成する
Microsoft Entra 多要素認証拡張機能がインストールされている NPS サーバーは、接続承認ポリシー (CAP) の指定された中央ポリシー ストアであることを思い出してください。 そのため、有効な接続要求を承認するために、NPS サーバーに CAP を実装する必要があります。
NPS サーバーで [NPS (ローカル)] コンソールを開き、 [ポリシー] を展開し、 [ネットワーク ポリシー] をクリックします。
[他のアクセス サーバーへの接続] を右クリックし、 [ポリシーの複製] をクリックします。
[Copy of Connections to other access servers](他のアクセス サーバーへの接続のコピー) を右クリックし、 [プロパティ] をクリックします。
[Copy of Connections to other access servers](他のアクセス サーバーへの接続のコピー) ダイアログ ボックスで、 [ポリシー名] に適切な名前 (例: RDG_CAP) を入力します。 [ポリシーを有効にする] チェック ボックスをオンにし、 [アクセスを許可する] を選択します。 必要に応じて、ネットワーク アクセス サーバーの種類で [リモート デスクトップ ゲートウェイ] を選択します。このフィールドは、 [未指定] のままにしておくこともできます。
[制約] タブで、 [認証方法をネゴシエートせずにクライアントに接続を許可する] をオンにします。
必要に応じて、 [条件] タブをクリックし、接続が承認されるために満たす必要がある条件 (特定の Windows グループのメンバーシップなど) を追加します。
OK をクリックします。 対応するヘルプ トピックの表示を促すメッセージが表示されたら、 [いいえ] をクリックします。
新しいポリシーが一覧の一番上に表示されていること、ポリシーが有効になっていること、ポリシーがアクセスを許可していることを確認します。
構成の確認
構成を確認するには、適切な RDP クライアントでリモート デスクトップ ゲートウェイにサインインする必要があります。 必ず、接続承認ポリシーで許可され、Microsoft Entra 多要素認証が有効になっているアカウントを使用してください。
次の画像に示すように、リモート デスクトップ Web アクセス ページを使用できます。
プライマリ認証の資格情報の入力が正常に完了すると、次に示すように、[リモート デスクトップ接続] ダイアログ ボックスにリモート接続の開始の状態が表示されます。
Microsoft Entra 多要素認証で以前に構成したセカンダリ認証方法で認証に成功すると、リソースに接続されます。 ただし、セカンダリ認証に失敗した場合、リソースへのアクセスは拒否されます。
次の例では、Windows Phone の Authenticator アプリを使用してセカンダリ認証を提供しています。
セカンダリ認証方法を使用した認証に成功すると、リモート デスクトップ ゲートウェイに通常どおりログインします。 ただし、信頼済みデバイスでモバイル アプリを使用したセカンダリ認証方法を使用する必要があるため、他の方法よりもサインイン プロセスの安全性が高まります。
成功したログオン イベントのイベント ビューアーのログを表示する
Windows イベント ビューアーのログで成功したサインイン イベントを表示するには、次の PowerShell コマンドを発行して、Windows ターミナル サービスのログと Windows のセキュリティ ログを照会します。
ゲートウェイの操作ログ (Event Viewer\Applications and Services Logs\Microsoft\Windows\TerminalServices-Gateway\Operational) の成功したサインイン イベントを照会するには、次の PowerShell コマンドを使用します。
Get-WinEvent -Logname Microsoft-Windows-TerminalServices-Gateway/Operational | where {$_.ID -eq '300'} | FL
- このコマンドは、ユーザーがリソース承認ポリシーの要件 (RD RAP) を満たしており、アクセスが許可されたことを示す Windows イベントを表示します。
Get-WinEvent -Logname Microsoft-Windows-TerminalServices-Gateway/Operational | where {$_.ID -eq '200'} | FL
- このコマンドは、ユーザーが接続承認ポリシーの要件を満たしていることを示すイベントを表示します。
このログを表示し、イベント ID 300 と 200 でフィルター処理することもできます。 イベント ビューアーのセキュリティ ログの成功したログオン イベントを照会するには、次のコマンドを使用します。
Get-WinEvent -Logname Security | where {$_.ID -eq '6272'} | FL
- このコマンドは、セントラル NPS サーバーまたは RD ゲートウェイ サーバーで実行できます。
次に示すように、セキュリティ ログや [ネットワーク ポリシーとアクセス サービス] カスタム ビューを表示することもできます。
Microsoft Entra 多要素認証の NPS 拡張機能をインストールしたサーバーで、拡張機能に固有のイベント ビューアーのアプリケーション ログ ("アプリケーションとサービス ログ\Microsoft\AzureMfa") を確認できます。
トラブルシューティング ガイド
構成が期待どおりに機能しない場合、トラブルシューティングを行うには、まず、ユーザーが Microsoft Entra 多要素認証を使用するように構成されていることを確認します。 ユーザーに Microsoft Entra 管理センターにサインインしてもらいます。 ユーザーがセカンダリ検証を求められ、正常に認証できれば、Microsoft Entra 多要素認証の構成の問題はなくなります。
Microsoft Entra 多要素認証がユーザーに対して機能している場合は、関連するイベント ログを確認する必要があります。 これには、前のセクションで説明したセキュリティ イベント ログ、ゲートウェイの操作ログ、Microsoft Entra 多要素認証ログが含まれます。
失敗したログオン イベント (イベント ID 6273) を示すセキュリティ ログの出力例を次に示します。
Azure MFA ログの関連イベントを次に示します。
高度なトラブルシューティング オプションを実行するには、NPS サービスがインストールされているサーバーで NPS データベース形式のログ ファイルを参照します。 これらのログ ファイルは、コンマ区切りのテキスト ファイルとして %SystemRoot%\System32\Logs フォルダーに作成されています。
これらのログ ファイルについては、「Interpret NPS Database Format Log Files (NPS データベース形式のログ ファイルの解釈)」をご覧ください。 これらのログ ファイルのエントリは、スプレッドシートやデータベースにインポートしないと解釈するのが難しい可能性があります。 ログ ファイルの解釈に役立つ IAS パーサーがオンラインでいくつか見つかります。
次の画像は、このようなダウンロード可能なシェアウェア アプリケーションの出力を示しています。
次のステップ
RADIUS を使用したリモート デスクトップ ゲートウェイと Multi-Factor Authentication Server