Windows 更新プログラムによって CVE-2022-21857 の新しい NTLM パススルー認証保護が追加される

元の KB 番号: 5010576

CVE-2022-21857 の保護を含む 2022 年 1 月 11 日以降の Windows 更新プログラムをインストールすると、ドメイン コントローラー (DC) は、ドメインまたはフォレストの信頼を介して信頼するドメインによって送信される NTLM パススルー認証要求、またはセキュリティで保護されたチャネル信頼経由で読み取り専用ドメイン コントローラー (RODC) によって送信される NTLM パススルー認証要求に対して新しいセキュリティ チェックを適用します。 新しいセキュリティ チェックでは、認証されるドメインまたはクライアントが、使用されている信頼に適している必要があります。 具体的には、使用されている信頼の種類に適したセキュリティ チェックでは、次の要件が満たされていない場合、NTLM パススルー認証要求が拒否されます。

• ドメイン信頼に対する要求では、信頼するドメインと同じドメイン名を使用する必要があります。
• フォレスト信頼に対する要求では、信頼するフォレストのメンバーであり、他のフォレストからの名前の競合がないドメイン名を使用する必要があります。
• RODC によって転送される要求では、RODC がシークレットのキャッシュを許可されているクライアント名を使用する必要があります。

ドメインとフォレストの信頼の検証をサポートするために、各フォレストのルート ドメインのプライマリ ドメイン コントローラー (PDC) が更新され、ライトウェイト ディレクトリ アクセス プロトコル (LDAP) クエリが定期的に発行されます。 クエリは、信頼するフォレスト ("信頼スキャン" と呼ばれます) 内のすべてのドメイン名に対して 8 時間ごとに発行されます。 これらのドメイン名は、対応する信頼されたドメイン オブジェクト (TDO) の msDS-TrustForestTrustInfo 属性に格納されます。

前提条件

更新プログラムによって新しい信頼スキャン動作が追加されると、信頼されたフォレストの PDC から信頼するフォレストへの LDAP アクティビティ トラフィック、認証、承認をブロックするものはすべて問題を引き起こします。

• ファイアウォールを使用する場合は、信頼された PDC と信頼するドメイン DC の間で TCP ポートと UDP ポート 389 を許可する必要があります。また、信頼を操作するための通信 (名前解決、NTLM の場合は RPC、Kerberos の場合はポート 88) を許可する必要があります。
• 信頼されたフォレストの PDC には、 ネットワークからこのコンピューターにアクセスする 信頼するドメイン DC に対して認証するユーザー権限も必要です。 既定では、"認証済みユーザー" には、信頼されたドメイン PDC を含むユーザー権限があります。
• 信頼されたドメインの PDC には、構成 NC と子オブジェクトの信頼するフォレスト パーティション コンテナーに対する十分な読み取りアクセス許可が必要です。 既定では、"認証済みユーザー" は、呼び出し元の信頼されたドメイン PDC に適用されるアクセス権を持っています。
• 選択的認証が有効になっている場合、信頼されるフォレストの PDC には、信頼するフォレストを保護するために、信頼するフォレスト DC コンピューター アカウントに対する認証アクセス許可を許可する必要があります。

信頼するフォレストで信頼されたフォレストが信頼情報のクエリを実行できない場合、信頼するフォレストが NTLM リレー攻撃のリスクにさらされる可能性があります。

たとえば、フォレスト A はフォレスト B を信頼し、フォレスト C はフォレスト B を信頼します。フォレスト A がフォレスト B のルート ドメインからの認証または LDAP アクティビティの許可を拒否した場合、フォレスト A は、悪意のあるフォレストまたは侵害されたフォレスト C からの NTLM リレー攻撃の危険にさらされます。

新しいイベント

次のイベントは CVE-2022-21857 の保護の一部として追加され、システム イベント ログに記録されます。

Netlogon サービス関連のイベント

既定では、Netlogon サービスは警告とエラー条件のイベントを調整します。つまり、要求ごとの警告またはエラー イベントはログに記録されません。 代わりに、概要イベント (Netlogon イベント ID 5832 と Netlogon イベント ID 5833) は、この更新プログラムで導入された新しいセキュリティ チェックによってブロックされるか、管理者が構成した除外フラグが存在するためブロックされているはずの NTLM パススルー認証に対して 1 日に 1 回ログに記録されます。

Netlogon イベント ID 5832 または Netlogon イベント ID 5833 のいずれかがログに記録され、さらに情報が必要な場合は、次のレジストリ パスで ThrottleNTLMPassThroughAuthEvents REG_DWORD値を 0 に設定してイベント調整を無効にします。

HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters

ローカル セキュリティ機関 (LSA) 関連のイベント

エラー に関連するイベントの一部にエラー コードが含まれている場合は、詳細な調査のためにトレースを有効にする必要があります。

Netlogon ログと LSA ログ記録の機能強化

Netlogon ログ (%windir%\debug\netlogon.log) と LSA ログ (lsp.log) が更新され、更新プログラムの機能強化がサポートされます。

Netlogon ログの有効化と無効化 (netlogon.log)

• Netlogon ログを有効にするには、次のコマンドを実行します。

  nltest /dbflag:2080ffff
  

• 調査後に Netlogon ログを無効にするには、次のコマンドを実行します。

  nltest /dbflag:0
  

PowerShell を使用して LSA ログ記録 (lsp.log) を有効または無効にする

• LSA ログを有効にするには、次のコマンドレットを実行します。

  Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name LspDbgInfoLevel -Value 0x1820000 -Type dword -Force 
  Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name LspDbgTraceOptions -Value 0x1 -Type dword -Force
  
  

• LSA ログを無効にするには、次のコマンドレットを実行します。

  Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name LspDbgInfoLevel -Value 0x0 -Type dword -Force 
  Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name LspDbgTraceOptions -Value 0x0 -Type dword -Force
  
  

reg.exeを使用して LSA ログ (lsp.log) を有効または無効にする (PowerShell を使用しないレガシ オペレーティング システムの場合)

• LSA ログを有効にするには、次の reg コマンドを実行します。

  reg add HKLM\SYSTEM\CurrentControlSet\Control\Lsa /V LspDbgTraceOptions /t REG_DWORD /d 1 /f 
  reg add HKLM\SYSTEM\CurrentControlSet\Control\Lsa /V LspDbgInfoLevel /t REG_DWORD /d 0x1820000 /f
  

• LSA ログを無効にするには、次の reg コマンドを実行します。

  reg add HKLM\SYSTEM\CurrentControlSet\Control\Lsa /V LspDbgTraceOptions /t REG_DWORD /d 0 /f 
  reg add HKLM\SYSTEM\CurrentControlSet\Control\Lsa /V LspDbgInfoLevel /t REG_DWORD /d 0x0 /f
  

nltest.exeツールとnetdom.exe ツールの機能強化

この更新プログラムの機能強化をサポートするために、 nltest.exe ツールと netdom.exe ツールが更新されます。

Nltest.exeの機能強化

nltest.exe ツールは、次のコマンドを使用して、信頼されたドメイン オブジェクトのmsDS-TrustForestTrustInfo属性内のすべてのレコードを照会および表示できます。

nltest.exe /lsaqueryfti:<Trusting Forest Name>

出力の例を次に示します。

C:\Windows\System32>nltest.exe /lsaqueryfti:contoso.com 
TLN: contoso.com 
Dom: contoso.com 
Scan: contoso.com Sid:(null) Flags:0x0 
The command completed successfully

Netdom.exeの機能強化

netdom.exe ツールは、新しい PDC 信頼スキャナー操作を開始し、信頼するフォレスト内の特定の信頼するドメインまたは特定の子ドメインのセキュリティ チェック除外フラグを設定できます。

• PDC 信頼スキャナー操作を開始します。

  • 信頼しているすべてのフォレストに対して、次のコマンドを実行します。

    netdom trust <Local Forest> /Domain:* /InvokeTrustScanner
    

  • 特定の信頼するフォレストの場合は、次のコマンドを実行します。

    netdom trust <Local Forest> /Domain:<Trusting Forest> /InvokeTrustScanner
    

    Note

    このコマンドは、ローカル フォレストの PDC でローカルに実行する必要があります。

  このコマンドは、操作を開始することしかできません。 結果を確認するには、システム イベント ログで新しい LSA イベントを調べて、必要に応じて LSA トレースを有効にします。

失敗した NTLM パススルー認証の調査

基本的な手順は次のとおりです。

1. 関連するすべての DC で Netlogon と LSA のログ記録を有効にします。

2. 問題を再現します。

3. Netlogon と LSA のログ記録を無効にします。

4. netlogon.log ファイルで次の用語を検索し、エラーを説明するログ エントリを確認します。

   • "LsaIFilterInboundNamespace"
   • "NlpValidateNTLMTargetInfo"
   • "NlpVerifyTargetServerRODCCachability"
   • "ResourceDomainNameCollidesWithLocalForest"

5. lsp.log ファイルで "LsaDbpFilterInboundNamespace" という用語を検索し、エラーを説明するログ エントリを確認します。

失敗した PDC 信頼スキャナー操作の調査

基本的な手順は次のとおりです。

1. PDC で LSA ログ記録を有効にします。

   特定の信頼スキャナー操作の場合、このトレースは TRACE_LEVEL_LSP_FOREST_SCANNER フラグに制限される場合があります。

2. 新しい netdom.exe /InvokeTrustScanner 機能を使用して問題を再現します。

3. LSA ログ記録を無効にします。

4. lsp.log ファイルで "fail" または "failed" という用語を検索し、ログ エントリを確認します。

信頼スキャナーは、次の理由で失敗する可能性があります。

• パーティション コンテナーにアクセス許可がありません。

• DC 間、およびメンバーと DC 間で必要なファイアウォール ポートが開いていません。 ファイアウォール ポートを次に示します。

  • UDP+TCP/389
  • TCP/88
  • UDP+TCP/53

問題の軽減策

ドメイン名の競合、構成の誤り、または予期しない状況によって認証が失敗した場合は、問題を軽減するための競合を防ぐために、衝突するドメインの名前を変更します。

RODC セキュリティで保護されたチャネル信頼に対する認証が失敗した場合は、軽減方法がないため、この問題について Microsoft サポートにお問い合わせください。

PDC 信頼スキャナーが失敗した場合、軽減策は特定のコンテキストに依存します。 たとえば、信頼されたフォレスト内の DC には、信頼するフォレストの構成名前付けコンテキスト (NC) に対する LDAP クエリのアクセス許可が付与されません。 軽減策は、アクセス許可を付与することです。

よく寄せられる質問 (FAQ)

• Q1: PDC 信頼スキャナーの頻度は構成できますか。

  A1: いいえ。

• Q2: 新しいフォレスト信頼の作成時に PDC 信頼スキャナーが自動的に呼び出されますか?

  A2: いいえ。 管理者は、必要に応じて手動で呼び出すことができます。それ以外の場合、新しいフォレストは次の定期的な間隔でスキャンされます。

• Q3: 新しいスキャナー レコードはドメイン管理者によって変更できますか?

  A3: はい。ただし、推奨またはサポートされていません。 スキャナー レコードが予期せず作成、変更、または削除された場合、PDC 信頼スキャナーは、次回の実行時に変更を元に戻します。

• Q4: 自分の環境では NTLM が使用されていないことが確認されています。 この動作を無効にする方法を教えてください。

  A4: 一般に、新しい動作をオフにすることはできません。 RODC 固有のセキュリティ検証を無効にすることはできません。 ドメイン信頼ケースまたはフォレスト信頼ケースのセキュリティ チェック除外フラグを設定できます。

• Q5: この更新プログラムをインストールする前に、構成を変更する必要がありますか。

  A5: 多分. Prerequisites セクションの説明に従って、構成が要件を満たしていることを確認します。

• Q6: この更新プログラムを有効にするには、特定の順序で DC にパッチを適用する必要がありますか?

  A6: 修正プログラムの適用順序のすべてのバリエーションがサポートされています。 新しい PDC 信頼スキャナー操作は、PDC にパッチが適用された後にのみ有効になります。 修正プログラムが適用されたすべての DC は、RODC 制限の適用を直ちに開始します。 修正プログラムが適用された PDC 以外では、PDC に修正プログラムが適用され、msDS-TrustForestTrustInfo 属性に新しいスキャナー レコードの作成が開始されるまで、NTLM パススルー制限は適用されません。 修正プログラムが適用されていない DC (PDC 以外) は、新しいスキャナー レコードが存在すると無視されます。

• Q7: フォレストはいつセキュリティで保護されますか?

  A7: すべてのドメインのすべての DC にこの更新プログラムがインストールされると、フォレストはセキュリティで保護されます。 PDC 信頼スキャナーが少なくとも 1 つの正常な操作を完了し、レプリケーションが成功すると、フォレストの信頼はセキュリティで保護されます。

• Q8: 信頼するドメインまたはフォレストを制御しません。 フォレストのセキュリティを確保するにはどうすればよいですか?

  A8: 前の質問を参照してください。 フォレストのセキュリティは、信頼しているドメインまたはフォレストの修正プログラムの適用状態に依存しません。 すべての顧客が DC にパッチを適用することをお勧めします。 さらに、「 Prerequisites 」セクションで説明されている構成を変更します。

関連情報

特定の技術的な詳細の詳細については、次を参照してください。

• [MS-ADTS]: Active Directory 技術仕様
• [MS-LSAD]: ローカル セキュリティ機関 (ドメイン ポリシー) リモート プロトコル
• [MS-NRPC]: Netlogon リモート プロトコル