Windows での NTLM 署名セキュリティの機能強化

元の発行日: 2026 年 11 月 10 日
KB ID: 5135557

概要

2026 年 11 月 10 日以降にリリースされた Windows 更新プログラムには、 CVE-2026-118737 に対処する追加の保護機能が含まれています。 これらの更新プログラムは、NTLM メッセージ署名の機能強化の第 1 段階を表します。 これらの変更により、認証された NTLM セッションが常に暗号化セッション キーを確立し、実際のメッセージ署名をネゴシエートすることが保証され、リレー攻撃にさらされる可能性が減ります。

タイムライン

• フェーズ 1 (2026 年 11 月 10 日): Windows クライアント デバイスは、既定ですべての接続で NTLM 署名の提供を開始します。 サーバーは、署名付きクライアントと署名されていないクライアントの両方を受け入れます。 監査イベントにより、署名を使用していないクライアントが識別されます。

• フェーズ 2 (2027 年 5 月): Windows サーバーでは、既定で NTLM 署名が要求され始めます。 署名を提供しないクライアントは、セキュリティで保護されたサーバーによって拒否されます。

背景

NTLM では、2 つの署名モードがサポートされています。

モード	フラグ	保護
NTLMSSP_NEGOTIATE_SIGN	0x00000010	実際の HMAC-MD5 署名。 セッション キーが確立されました。 偽造できない。
NTLMSSP_NEGOTIATE_ALWAYS_SIGN	0x00008000	従来の 16 バイトのゼロ プレースホルダー。 暗号化保護はありません。

この変更以前は、 ISC_REQ_INTEGRITY 、 ISC_REQ_RELAY_DETECT 、または ISC_REQ_SEQUENCE_DETECT (コンテキスト要件 - Win32 アプリ) を要求しなかったアプリケーションは、ALWAYS_SIGN プレースホルダーを使用してコンテキストを受け取りました。 サポートされているすべての Windows サーバーは既に署名をサポートしています。 この変更により、一貫して使用できるようになります。

NTLM 監査: NTLM が SIGN を使用しているかどうかを確認する操作方法

1. まず、すべての NTLM 認証のネゴシエートされたフラグを確認します。 これらは、Microsoft-Windows-NTLM/Operational の [イベント ID: 4023 (サーバー側)] および [イベント ID: 4022 (クライアント側)] に表示されます。
   
   これらのイベントは、Windows Server 2019 以降の NTLM 拡張監査で利用可能です。

   良い — イベント 4023: 署名交渉済み (フェーズ 2 対応)	⚠️ BAD — イベント 4023: 署名なし (フェーズ 2 で拒否されます)
   レベル: 警告 リモート クライアントは NTLM を使用してこのワークステーションへの認証を行っています。 プロセス情報: プロセス名: svchost リモート クライアント情報: ユーザー名: Administrator ドメイン: corp.contoso.com クライアント マシン: WORKSTATION-01 クライアント IP: 10.1.2.100 NTLM セキュリティ: ネゴシエートされたフラグ: 0xE0888215 NTLM バージョン: NTLMv2 セッション キーの状態: 現在 チャネル バインド: サポートされています	レベル: 警告 リモート クライアントは NTLM を使用してこのワークステーションへの認証を行っています。 プロセス情報: プロセス名: svchost リモート クライアント情報: ユーザー名: Administrator ドメイン: corp.contoso.com クライアント マシン: WORKSTATION-01 クライアント IP: 10.1.2.100 NTLM セキュリティ: ネゴシエートされたフラグ: 0xA0888205 NTLM バージョン: NTLMv2 セッション キーの状態: ありません チャネル バインド: サポートされていません

2. [セッション キーの状態] で主な違いを探します。ビット 0x10 (SIGN) と0x40000000 (KEY_EXCH) を含む現在のフラグとネゴシエートされたフラグ。 両方のビットが設定されている場合、接続はセキュリティで保護されます。 完全なフラグ定義については、 MS-NLMP NegotiateFlags を参照してください。

3. 次の表を使用して、ネゴシエートされたフラグをデコードします。

   ビット値	フラグ名	意味
   0x00000010	NTLMSSP_NEGOTIATE_SIGN	✅ 実際の署名交渉。 セッション キーが存在します。
   0x40000000	NTLMSSP_NEGOTIATE_KEY_EXCH	✅ 交換されたセッション キー。 SIGN に必須です。
   0x00008000	NTLMSSP_NEGOTIATE_ALWAYS_SIGN	⚠️ SIGN が指定されていない場合、保護されません。

4. 接続を次のように診断します。

   • フェーズ 2 対応: 0xE0888215 — 0x10 + 0x40000000 + セッション キーが含まれています: 存在する

   • 要確認: 0xA0888205 — 0x10 (SIGN) ビットなし、セッション キー: ありません

SIGN を送信しないクライアントを見つける

イベント レベルだけでフィルター処理しないでください。署名済み接続と署名されていない接続の両方が同じ警告レベルで表示されます。 SIGN ビットを直接チェックします。

Get-WinEvent -LogName "Microsoft-Windows-NTLM/Operational" -ErrorAction SilentlyContinue |
  Where-Object { $_.Id -in @(4022, 4023) } |
  ForEach-Object {
    $flags   = if ($_.Message -match "Negotiated Flags:\s+(0x[0-9A-Fa-f]+)") { $Matches[1] } else { "?" }
    $flagVal = if ($flags -ne "?") { [long]$flags } else { 0L }
    if (-not ($flagVal -band 0x10)) {   # NTLMSSP_NEGOTIATE_SIGN bit absent
        [PSCustomObject]@{
            Time       = $_.TimeCreated
            Id         = $_.Id
            ClientIP   = if ($_.Message -match "Client IP:\s+(\S+)")          { $Matches[1] } else { "-" }
            ClientHost = if ($_.Message -match "Client Machine:\s+(\S+)")     { $Matches[1] } else { "-" }
            User       = if ($_.Message -match "Username:\s+(\S+)")           { $Matches[1] } else { "-" }
            Flags      = $flags
            KeyStatus  = if ($_.Message -match "Session Key Status:\s+(\S+)") { $Matches[1] } else { "-" }
            Process    = if ($_.Message -match "Process Name:\s+(.+)")        { $Matches[1].Trim() } else { "-" }
        }
    }
  } | Sort-Object ClientIP -Unique | Format-Table -AutoSize

2026 年 11 月 10 日の Windows 更新プログラムによって導入されたレジストリ キー

ClientAllowUnsignedNtlm

項目	詳細
パス	HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0
値の名前	ClientAllowUnsignedNtlm
型	REG_DWORD
値	0 (既定値) - クライアントはすべての非匿名接続にサインオンを提供します。 1 - クライアントはサインを提供しません。 一時的な互換性のためにのみ使用してください。

ServerRequireNtlmSign

項目	詳細
パス	HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0
値の名前	ServerRequireNtlmSign
型	REG_DWORD
値	0 (既定値) - サーバーは、安全な接続のために署名済みクライアントと署名されていないクライアントの両方を受け入れます。 1 - サーバーは署名されていないクライアントを拒否します。 監査で準備が完了したことを確認した後に推奨されます。
メモ	再起動は必要ありません。 一度 ServerRequireNtlmSign=1 を有効にします イベント ID: 4023 監査では、署名されていない接続が表示されません。

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

この変更は Kerberos に影響しますか?

    いいえ。 これらの変更は NTLM 認証にのみ適用されます。

匿名 (null セッション) 接続は引き続き機能しますか?

    はい。 匿名接続 (ISC_REQ_NULL_SESSION) は明示的に除外されます。 設計上セッション キーはありません。 フェーズ 1 とフェーズ 2 の両方で匿名接続が除外されます。

ゲスト アカウント接続は引き続き機能しますか?

    はい。 ゲスト アカウント接続も制限されません。 匿名接続と同様に、本当のセッション キーも意味のある権限もありません。 ゲスト セッションに署名を要求することにはセキュリティ値はありません。

SIGN をサポートしていない古いサーバーにクライアントが接続するとどうなりますか?

    サーバーがチャレンジで SIGN をエコーしない場合、クライアントは自動的にセッションから SIGN を削除し、従来の ALWAYS_SIGN 動作にフォールバックします。 接続の失敗はありません。 すべての Windows サーバーは既定で SIGN をエコーします。

拒否されたクライアントには、フェーズ 2 でどのようなエラーが表示されますか?

    SEC_E_UNSUPPORTED_FUNCTION (0x80090302)。 サーバーは、警告イベント 4023 をこのステータス コードでログに記録します。

環境がフェーズ 2 の準備ができているかどうかを確認する操作方法

    この記事に含まれている PowerShell スクリプトを実行します。 結果が表示されない場合 (署名されていない接続がない場合) は、準備ができています。 事前に ServerRequireNtlmSign=1 を設定して早期に適用します。

レ

ジストリ キーは今後削除されますか?

    Microsoft は将来レジストリ キーを削除する可能性があり、さらに詳しい情報でこのドキュメントを更新します。

その他のリソース

• MS-NLMP: NT LAN Manager 認証プロトコル

• MS-NLMP: NEGOTIATE_MESSAGE NegotiateFlags

• NTLM ログを有効にする方法 (aka.ms/ntlmlogandblock)