この記事では、Microsoft Azure のネットワーク ポリシー サーバー (NPS) 拡張機能を使用して、リモート デスクトップ ゲートウェイ インフラストラクチャを Microsoft Entra 多要素認証と統合する方法について詳しく説明します。
Azure のネットワーク ポリシー サーバー (NPS) 拡張機能を使用すると、お客様は Azure のクラウドベース の多要素認証を使用してリモート認証ダイヤルイン ユーザー サービス (RADIUS) クライアント認証を保護できます。 このソリューションは、ユーザーのサインインとトランザクションにセキュリティの第 2 レイヤーを追加するための 2 段階認証を提供します。
この記事では、Azure の NPS 拡張機能を使用して、NPS インフラストラクチャを Microsoft Entra 多要素認証と統合するための詳細な手順について説明します。 これにより、リモート デスクトップ ゲートウェイにサインインしようとするユーザーを確実に検証できるようになります。
注
この記事は、MFA Server のデプロイでは使用しないでください。また、Microsoft Entra 多要素認証 (クラウドベース) のデプロイでのみ使用してください。
ネットワーク ポリシーとアクセス サービス (NPS) により、組織は次のことができるようになります。
- 接続できるユーザー、接続が許可される時間帯、接続の期間、クライアントが接続に使用する必要があるセキュリティのレベルなどを指定して、ネットワーク要求を管理および制御するための集約された場所をそれぞれ定義できます。 これらのポリシーは、VPN またはリモート デスクトップ (RD) ゲートウェイ サーバーごとに指定するのではなく、集約された場所で一度に指定できます。 RADIUS プロトコルは、一元化された認証、承認、アカウンティング (AAA) を提供します。
- デバイスにネットワーク リソースへの無制限のアクセスを許可するか制限付きアクセスを許可するかを決定する、ネットワーク アクセス保護 (NAP) クライアント正常性ポリシーを制定し、強制できます。
- 802.1x 対応ワイヤレス アクセス ポイントとイーサネット スイッチへのアクセスに認証と承認を強制する手段を提供できます。
一般に、組織では NPS (RADIUS) を使用して VPN ポリシーの管理を簡素化し、一元化しています。 にもかかわらず、多くの組織が、NPS を使用してリモート デスクトップの接続承認ポリシー (RD CAP) の管理も簡素化し、一元化しています。
組織は、NPS を Microsoft Entra 多要素認証と統合して、セキュリティを強化し、高度なコンプライアンスを提供することもできます。 このことは、リモート デスクトップ ゲートウェイにサインインする際の 2 段階認証をユーザーが確実に制定するための助けとなります。 ユーザーはアクセスの許可を得るために、ユーザー名/パスワードの組み合わせをユーザーが独自に管理している情報と共に提供する必要があります。 この情報は、信頼性があり、簡単に複製できないもの (携帯電話番号、固定電話番号、モバイル デバイス上のアプリケーションなど) である必要があります。 RDG は現在、2FA の Microsoft 認証アプリ メソッドからの電話呼び出しと 承認/Deny プッシュ通知をサポートしています。 サポートされている認証方法の詳細については、「ユーザーが使用できる認証方法を決定する」セクション
組織でリモート デスクトップ ゲートウェイを使っていて、ユーザーが Authenticator のプッシュ通知と共に TOTP コードを登録している場合、ユーザーは MFA チャレンジを満たすことができず、リモート デスクトップ ゲートウェイでのサインインに失敗します。 その場合は、新しいレジストリ キー (OVERRIDE_NUMBER_MATCHING_WITH_OTP) を作成して、Authenticator で承認/拒否へのプッシュ通知にフォールバックすることで、この動作をオーバーライドできます。 これを実行するには、 NPS 拡張機能のオーバーライド番号の一致 手順に従います。最終的な値が 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) インフラストラクチャが必要です。 作成しない場合は、クイック スタート テンプレート「 リモート デスクトップ セッション コレクションのデプロイを作成する」を使用して、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 役割サービスのインストールの詳細については、「 NAP 正常性ポリシー サーバーのインストール」を参照してください。 ドメイン コントローラーに NPS をインストールするための推奨事項など、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 多要素認証の概要に関する記事の手順に従って、Microsoft Entra ユーザーの MFA を有効にします。
2 段階認証用にアカウントを構成する
アカウントで MFA が有効になったら、2 番目の認証要素に使用するように信頼されたデバイスを正常に構成し、2 段階認証を使用して認証するまで、MFA ポリシーによって管理されるリソースにサインインすることはできません。
ユーザー アカウントで MFA 用のデバイスを理解し、適切に構成するには、「 Microsoft Entra 多要素認証の意味 」の手順に従ってください。
重要
リモート デスクトップ ゲートウェイのサインインでは、Microsoft Entra 多要素認証で確認コードを入力することはできません。 ユーザー アカウントは、電話による確認または 承認/Deny プッシュ通知を使用した Microsoft Authenticator アプリ用に構成する必要があります。
電話による確認も、 承認/Deny プッシュ通知もユーザーに対して構成されていない場合、ユーザーは Microsoft Entra 多要素認証チャレンジを完了してリモート デスクトップ ゲートウェイにサインインできなくなります。
確認コードを入力する手段がないため、SMS テキストはリモート デスクトップ ゲートウェイには使用できません。
NPS 拡張機能のインストールと構成
このセクションでは、リモート デスクトップ ゲートウェイでのクライアント認証に Microsoft Entra 多要素認証を使用するように RDS インフラストラクチャを構成する手順について説明します。
ディレクトリ テナント ID を取得する
NPS 拡張機能の構成の一環として、管理者資格情報と Microsoft Entra テナントの ID を入力する必要があります。 テナント ID を取得するには、次の手順のようにします。
Microsoft Entra 管理センターにサインインします。
Entra ID>Overview>Properties に移動します。
NPS 拡張機能のインストール
ネットワーク ポリシーとアクセス サービス (NPS) の役割がインストールされているサーバーに NPS 拡張機能をインストールします。 これが、設計で RADIUS サーバーとして機能します。
重要
リモート デスクトップ ゲートウェイ (RDG) サーバーには NPS 拡張機能をインストールしないでください。 RDG サーバーはそのクライアントと共に RADIUS プロトコルを使用しないため、この拡張機能では MFA を解釈して実行することができません。
RDG サーバーと、NPS 拡張機能を備えた NPS サーバーが異なるサーバーである場合、RDG は NPS を内部で使用して他の NPS サーバーと通信し、RADIUS をプロトコルとして使用して正しく通信します。
- NPS 拡張機能をダウンロードします。
- セットアップ実行可能ファイル (NpsExtnForAzureMfaInstaller.exe) を NPS サーバーにコピーします。
- NPS サーバーで、 NpsExtnForAzureMfaInstaller.exeをダブルクリックします。 メッセージが表示されたら、[ 実行] を選択します。
- [NPS Extension For Microsoft Entra Multifactor authentication Setup] ダイアログ ボックスで、ソフトウェア ライセンス条項を確認し、[ ライセンス条項に同意する] をオンにして、[ インストール] を選択します。
- [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] を選択します。 この共有シークレットを記録し、記録を安全な場所に保管してください。
注
共有シークレットは、RADIUS サーバーと RADIUS クライアント間の信頼を確立するために使用されます。 長い複雑なシークレットを作成してください。
[ OK] を 選択してダイアログ ボックスを閉じます。
リモート デスクトップ ゲートウェイの NPS で RADIUS のタイムアウト値を構成する
ユーザーの資格情報の検証、2 段階認証の実行、応答の受信、RADIUS メッセージへの応答を行う時間を確保するには、RADIUS タイムアウト値を調整する必要があります。
RD ゲートウェイ サーバーで、サーバー マネージャーを開きます。 メニューの [ ツール] を選択し、[ ネットワーク ポリシー サーバー] を選択します。
NPS (ローカル) コンソールで、[RADIUS クライアントとサーバー] を展開し、[リモート RADIUS サーバー] を選択します。
詳細ウィンドウで、 TS ゲートウェイ サーバー グループをダブルクリックします。
注
この RADIUS サーバー グループは、NPS ポリシーのセントラル サーバーを構成したときに作成されました。 RD ゲートウェイは、このサーバーまたはサーバーのグループ (グループに複数のサーバーが含まれている場合) に RADIUS メッセージを転送します。
[TS ゲートウェイ サーバー グループのプロパティ] ダイアログ ボックスで、RD CAP を格納するように構成した NPS サーバーの IP アドレスまたは名前を選択し、[編集] を選択します。
[ RADIUS サーバーの編集 ] ダイアログ ボックスで、[ 負荷分散 ] タブを選択します。
[ 負荷分散 ] タブ の [要求が破棄されたと見なされるまでの応答がない 秒数] フィールドで、既定値を 3 から 30 ~ 60 秒の値に変更します。
[ サーバーが使用不可と識別されたときの要求間隔の秒数 ] フィールドで、既定値の 30 秒を、前の手順で指定した値以上の値に変更します。
![[負荷分散] タブで Radius Server のタイムアウト設定を編集する](media/howto-mfa-nps-extension-rdg/image14.png)
[ OK] を 2 回選択してダイアログ ボックスを閉じます。
接続要求ポリシーを確認する
既定では、接続承認ポリシーに集約型ポリシー ストアを使用するように RD ゲートウェイを構成すると、CAP 要求を NPS サーバーに転送するように RD ゲートウェイが構成されます。 Microsoft Entra 多要素認証拡張機能がインストールされている NPS サーバーで、RADIUS アクセス要求が処理されます。 次の手順は、既定の接続要求ポリシーを確認する方法を示しています。
RD ゲートウェイの NPS (ローカル) コンソールで、[ ポリシー] を展開し、[ 接続要求ポリシー] を選択します。
[TS GATEWAY AUTHORIZATION POLICY] をダブルクリックします。
[TS ゲートウェイ承認ポリシーのプロパティ] ダイアログ ボックスで、[設定] タブを選択します。
[ 設定] タブの [接続要求の転送] で、[ 認証] を選択します。 認証のために要求を転送するように RADIUS クライアントが構成されています。
[ キャンセル] を選択します。
注
接続要求ポリシーの作成の詳細については、「接続要求ポリシーの構成 ドキュメント」
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 クライアント ] ダイアログ ボックスで、 ゲートウェイなどのフレンドリ名と、リモート デスクトップ ゲートウェイ サーバーの IP アドレスまたは DNS 名を指定します。
[ 共有シークレット ] フィールドと [ 共有シークレットの確認 ] フィールドに、前に使用したのと同じシークレットを入力します。
[ OK] を 選択して [新しい RADIUS クライアント] ダイアログ ボックスを閉じます。
ネットワーク ポリシーを構成する
Microsoft Entra 多要素認証拡張機能がインストールされている NPS サーバーは、接続承認ポリシー (CAP) の指定された集約型ポリシー ストアであることを思い出してください。 そのため、有効な接続要求を承認するために、NPS サーバーに CAP を実装する必要があります。
NPS サーバーで、NPS (ローカル) コンソールを開き、[ ポリシー] を展開し、[ ネットワーク ポリシー] を選択します。
[他のアクセス サーバーへの接続] を右選択し、[ポリシーの複製] を選択します。
[他のアクセス サーバーへの接続のコピー] を右選択し、[プロパティ] を選択します。
[ 他のアクセス サーバーへの接続のコピー ] ダイアログ ボックスの [ ポリシー名] に、適切な名前 ( RDG_CAPなど) を入力します。 ポリシーが有効になっていることを確認し、[アクセス権の付与] を選択します。 必要に応じて、[ ネットワーク アクセス サーバーの種類] で [ リモート デスクトップ ゲートウェイ] を選択するか、[ 未指定] のままにすることができます。
[ 制約 ] タブを選択し、[ 認証方法をネゴシエートせずにクライアントが接続できるようにする] をオンにします。
必要に応じて、[ 条件 ] タブを選択し、接続を承認するために満たす必要がある条件 (特定の Windows グループのメンバーシップなど) を追加します。
[ OK] を選択します。 対応するヘルプ トピックを表示するように求められたら、[ いいえ] を選択します。
新しいポリシーが一覧の一番上に表示されていること、ポリシーが有効になっていること、ポリシーがアクセスを許可していることを確認します。
構成の確認
構成を確認するには、適切な RDP クライアントでリモート デスクトップ ゲートウェイにサインインする必要があります。 必ず、接続承認ポリシーで許可され、Microsoft Entra 多要素認証が有効になっているアカウントを使用してください。
次の図に示すように、 リモート デスクトップ Web アクセス ページを使用できます。
プライマリ認証の資格情報を正常に入力すると、次のセクションに示すように、[リモート デスクトップ接続] ダイアログ ボックスに [リモート接続の開始] の状態が表示されます。
Microsoft Entra 多要素認証で以前に構成したセカンダリ認証方法で正常に認証された場合は、リソースに接続されます。 ただし、セカンダリ認証が成功しなかった場合は、リソースへのアクセスが拒否されます。
次の例では、Windows Phone の Authenticator アプリを使用して、セカンダリ認証を提供します。
セカンダリ認証方法を使用して正常に認証されると、通常どおりリモート デスクトップ ゲートウェイにログインします。 ただし、信頼されたデバイス上のモバイル アプリを使用してセカンダリ認証方法を使用する必要があるため、サインイン プロセスはそれ以外の場合よりも安全です。
成功したログオン イベントのイベント ビューアーのログを表示する
Windows イベント ビューアーのログで成功したサインイン イベントを表示するには、次の PowerShell コマンドを発行して、Windows Terminal サービスのログと Windows のセキュリティ ログを照会します。
ゲートウェイ操作ログ (イベント ビューアー\アプリケーションとサービス ログ\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 ゲートウェイ サーバーで実行できます。
セキュリティ ログまたはネットワーク ポリシーと Access Services のカスタム ビューを表示することもできます。
Microsoft Entra 多要素認証の NPS 拡張機能がインストールされているサーバーで、拡張機能に固有のイベント ビューアーのアプリケーション ログ (アプリケーションとサービス ログ\Microsoft\AzureMfa) を確認できます。
トラブルシューティング ガイド
構成が期待どおりに動作しない場合、トラブルシューティングを開始する最初の場所は、ユーザーが Microsoft Entra 多要素認証を使用するように構成されていることを確認することです。 ユーザーに Microsoft Entra 管理センターにサインインさせます。 ユーザーがセカンダリ検証を求められ、正常に認証できれば、Microsoft Entra 多要素認証の構成の問題はなくなります。
Microsoft Entra 多要素認証がユーザーに対して機能している場合は、関連するイベント ログを確認する必要があります。 これには、前のセクションで説明したセキュリティ イベント ログ、ゲートウェイの操作ログ、Microsoft Entra 多要素認証ログが含まれます。
失敗したログオン イベント (イベント ID 6273) を示すセキュリティ ログの出力例を次に示します。
AzureMFA ログからの関連イベントを次に示します。
高度なトラブルシューティング オプションを実行するには、NPS サービスがインストールされているサーバーで NPS データベース形式のログ ファイルを参照します。 これらのログ ファイルは、\ System32\Logs フォルダー%SystemRoot% コンマ区切りのテキスト ファイルとして作成されます。
これらのログ ファイルの詳細については、「 NPS データベース形式のログ ファイルの解釈」を参照してください。 これらのログ ファイルのエントリは、スプレッドシートやデータベースにインポートしないと解釈するのが難しい可能性があります。 ログ ファイルの解釈に役立つ IAS パーサーがオンラインでいくつか見つかります。
次の図は、このようなダウンロード可能な Shareware アプリケーションの出力を示しています。
次のステップ
RADIUS を使用したリモート デスクトップ ゲートウェイと Azure Multi-Factor Authentication Server