元の発行日: 2025 年 7 月 11 日
KB ID: 5064479
この記事の内容:
概要
この記事では、Windows 11 バージョン 24H2 および Windows Server 2025 の NT LAN Manager (NTLM) 監査機能に対する今後の変更の概要について説明します。 これらの機能強化は、NTLM 認証アクティビティの可視性を高め、管理者がユーザーの ID、NTLM の使用の根拠、および環境内で NTLM が使用されている特定の場所を特定できるように設計されています。 強化された監査では、セキュリティ監視の強化とレガシ認証の依存関係の識別がサポートされます。
NTLM 監査の変更の目的
NTLM 認証は、多くの場合、レガシ アプリケーションと構成が原因で、さまざまなエンタープライズ シナリオで引き続き存在します。 NTLM の非推奨と今後の無効化の発表 (Windows IT ブログ「Windows 認証の進化」を参照) により、更新された監査機能は、管理者が NTLM の使用状況を特定し、使用パターンを理解し、NT LAN Manager バージョン 1 (NTLMv1) の使用を含む潜在的なセキュリティ リスクを検出するのに役立ちます。
NTLM 監査ログ
Windows 11バージョン 24H2 および Windows Server 2025 では、クライアント、サーバー、ドメイン コントローラーに対して新しい NTLM 監査ログ機能が導入されています。 各コンポーネントは、NTLM 認証イベントに関する詳細情報を提供するログを生成します。 これらのログは、Microsoft > Windows > NTLM > Operational > アプリケーションとサービス ログのイベント ビューアーにあります。
既存の NTLM 監査ログと比較して、新しい強化された監査の変更により、管理者は Who、Why、Where に回答できます。
-
マシン上のアカウントとプロセスを含め、NTLM を使用しているユーザー。
-
Kerberos などの最新の認証プロトコルではなく、NTLM 認証が選択された理由。
-
マシン名とマシン IP の両方を含め、NTLM 認証が行われている場所。
強化された NTLM 監査では、クライアントとサーバーの NTLMv1 の使用状況に関する情報と、ドメイン コントローラーによってログに記録されたドメイン全体の NTLMv1 使用状況に関する情報も提供されます。
グループ ポリシーの管理
新しい NTLM 監査機能は、更新されたグループ ポリシー設定で構成できます。 管理者は、これらのポリシーを使用して、監査する NTLM 認証イベントを指定し、環境に応じてクライアント、サーバー、ドメイン コントローラー間の監査動作を管理できます。
既定では、イベントは有効になっています。
-
クライアントとサーバーのログ記録の場合、イベントは、[ 管理用テンプレート ] > [ システム > NTLM] の [ NTLM 拡張ログ] ポリシーを使用して制御されます。
-
ドメイン コントローラーでのドメイン全体のログ記録の場合 、イベントは、[ 管理用テンプレート ] > [システム > Netlogon] の下にある [ログ拡張ドメイン全体の NTLM ログ] ポリシーを使用して制御されます。
監査レベル
各 NTLM 監査ログは、イベント レベルによってのみ異なる同じ情報を持つ 2 つの異なるイベント ID に分割されます。
-
情報: NT LAN Manager バージョン 2 (NTLMv2) 認証など、セキュリティの低下が検出されない標準 NTLM イベントを示します。
-
警告: NTLMv1 の使用など、NTLM セキュリティのダウングレードを示します。 これらのイベントでは、安全でない認証が強調表示されます。 イベントは、次のようなインスタンスの "警告" としてマークされる場合があります。
-
クライアント、サーバー、またはドメイン コントローラーによって NTLMv1 の使用状況が検出されました。
-
認証の拡張保護は、サポートされていないか安全でないとマークされています (詳細については、「 KB5021989: 認証の拡張保護」を参照してください)。
-
メッセージ整合性チェック (MIC) などの特定の NTLM セキュリティ機能は使用されません。
-
クライアント ログ
新しい監査ログには、送信 NTLM 認証の試行が記録されます。 これらのログは、NTLM 接続を開始するアプリケーションまたはサービスに関する詳細と、各認証要求に関連するメタデータを提供します。
クライアント ログには、NTLM 認証が使用された理由を示す一意の [ 使用状況 ID/理由] フィールドがあります。
ID |
説明 |
0 |
不明な理由。 |
1 |
NTLM は、呼び出し元のアプリケーションによって直接呼び出されました。 |
2 |
ローカル アカウントの認証。 |
3 |
RESERVED。現在使用されていません。 |
4 |
クラウド アカウントの認証。 |
5 |
ターゲット名が見つからないか、空でした。 |
6 |
ターゲット名を Kerberos またはその他のプロトコルで解決できませんでした。 |
7 |
ターゲット名には IP アドレスが含まれています。 |
8 |
ターゲット名が Active Directory で重複していることが検出されました。 |
9 |
ドメイン コントローラーを使用して見通し線を確立することはできません。 |
10 |
NTLM はループバック インターフェイスを介して呼び出されました。 |
11 |
NTLM が null セッションで呼び出されました。 |
イベント ログ |
Microsoft-Windows-NTLM/Operational |
イベント ID |
4020 (情報)、4021 (警告) |
イベント ソース |
NTLM |
イベント テキスト |
このマシンは NTLM を介してリモート リソースに対して認証を試行しました。 プロセス情報: プロセス名: <名> プロセス PID: <PID> クライアント情報: ユーザー名: ユーザー名> < ドメイン: ドメイン名> < ホスト名: ホスト名> < Sign-On タイプ: <単一 Sign-On/提供されたCreds> ターゲット情報: ターゲット コンピューター: マシン名 <> ターゲット ドメイン: マシン ドメイン> < ターゲット リソース: <サービス プリンシパル名 (SPN)> ターゲット IP: <IP アドレス> ターゲット ネットワーク名: <ネットワーク名> NTLM 使用法: 理由 ID: <使用状況 ID> 理由: <使用理由> NTLM セキュリティ: ネゴシエートされたフラグ: <フラグ> NTLM バージョン: <NTLMv2/NTLMv1> セッション キーの状態: 現在の </不足している> チャネル バインド: < サポートされている/サポートされていない> サービス バインド: <サービス プリンシパル名 (SPN)> MIC 状態: 保護 < 保護されていない> AvFlags: <NTLM フラグ> AvFlags 文字列: NTLM フラグ文字列> < 詳細については、「aka.ms/ntlmlogandblock」を参照してください。 |
サーバー ログ
新しい監査ログは、着信 NTLM 認証の試行を記録します。 これらのログは、NTLM 認証に関する同様の詳細をクライアント ログと同様に提供し、NTLM 認証が成功したかどうかを報告します。
イベント ログ |
Microsoft-Windows-NTLM/Operational |
イベント ID |
4022 (情報)、4023 (警告) |
イベント ソース |
NTLM |
イベント テキスト |
リモート クライアントは NTLM を使用してこのワークステーションに対する認証を行います。 プロセス情報: プロセス名: <名> プロセス PID: <PID> リモート クライアント情報: ユーザー名: クライアントユーザー名> < ドメイン: クライアント ドメイン> < クライアント コンピューター: <クライアント コンピューター名> クライアント IP: <クライアント IP> クライアント ネットワーク名: クライアント ネットワーク名 <> NTLM セキュリティ: ネゴシエートされたフラグ: <フラグ> NTLM バージョン: <NTLMv2/NTLMv1> セッション キーの状態: 現在の </不足している> チャネル バインド: < サポートされている/サポートされていない> サービス バインド: <サービス プリンシパル名 (SPN)> MIC 状態: 保護 < 保護されていない> AvFlags: <NTLM フラグ> AvFlags 文字列: NTLM フラグ文字列> < 状態: 状態コード> < Status Message: <Status String> 詳細については、「aka.ms/ntlmlogandblock」を参照してください。 |
ドメイン コントローラーのログ
ドメイン コントローラーは、ドメイン全体の NTLM 認証試行の成功と失敗の両方をキャプチャする新しいログを使用して、強化された NTLM 監査の恩恵を受けます。 これらのログは、NTLMv1 認証など、認証セキュリティの潜在的なダウングレードに対するドメイン間 NTLM の使用状況とアラート管理者の識別をサポートします。
次のシナリオに応じて、異なるドメイン コントローラー ログが作成されます。
クライアント アカウントとサーバー コンピューターの両方が同じドメインに属している場合は、次のようなログが作成されます。
イベント ログ |
Microsoft-Windows-NTLM/Operational |
イベント ID |
4032 (情報)、4033 (警告) |
イベント ソース |
Security-Netlogon |
イベント テキスト |
DC <DC 名>、このドメインから送信された転送された NTLM 認証要求を処理しました。 クライアント情報: クライアント名: ユーザー名 <> クライアント ドメイン: <ドメイン> クライアント コンピューター: クライアント ワークステーション> < サーバー情報: サーバー名: サーバー コンピューター名> < サーバー ドメイン: <サーバー ドメイン> サーバー IP: <サーバー IP> サーバー OS: <サーバー オペレーティング システムの> NTLM セキュリティ: ネゴシエートされたフラグ: <フラグ> NTLM バージョン: <NTLMv2/NTLMv1> セッション キーの状態: 現在の </不足している> チャネル バインド: < サポートされている/サポートされていない> サービス バインド: <サービス プリンシパル名 (SPN)> MIC 状態: 保護 < 保護されていない> AvFlags: <NTLM フラグ> AvFlags 文字列: NTLM フラグ文字列> < 状態: 状態コード> < Status Message: <Status String> 詳細については、「aka.ms/ntlmlogandblock」を参照してください。 |
クライアント アカウントとサーバーが異なるドメインに属している場合、ドメイン コントローラーは、ドメイン コントローラーがクライアントが存在するドメインに属しているか (認証を開始する) か、サーバーが存在する場所 (認証を受け入れる) に応じて異なるログを持ちます。
サーバーが認証を処理しているドメイン コントローラーと同じドメインに属している場合は、"同じドメイン ログ" のようなログが作成されます。
クライアント アカウントが認証を処理しているドメイン コントローラーと同じドメインに属している場合は、次のようなログが作成されます。
イベント ログ |
Microsoft-Windows-NTLM/Operational |
イベント ID |
4030 (情報)、4031 (警告) |
イベント ソース |
Security-Netlogon |
イベント テキスト |
DC <DC 名>、このドメインから送信された転送された NTLM 認証要求を処理しました。 クライアント情報: クライアント名: ユーザー名 <> クライアント ドメイン: <ドメイン> クライアント コンピューター: クライアント ワークステーション> < サーバー情報: サーバー名: サーバー コンピューター名> < サーバー ドメイン: <サーバー ドメイン> 転送元: セキュリティで保護されたチャネルの種類: <Netlogon Secure Channel Info> Farside Name: <クロスドメイン DC マシン名 > Farside Domain: <クロスドメイン ドメイン名> Farside IP: <クロスドメイン DC IP> NTLM セキュリティ: ネゴシエートされたフラグ: <フラグ> NTLM バージョン: <NTLMv2/NTLMv1> セッション キーの状態: 現在の </不足している> チャネル バインド: < サポートされている/サポートされていない> サービス バインド: <サービス プリンシパル名 (SPN)> MIC 状態: 保護 < 保護されていない> AvFlags: <NTLM フラグ> AvFlags 文字列: NTLM フラグ文字列> < 状態: 状態コード> < 詳細については、「aka.ms/ntlmlogandblock」を参照してください。 |
新しい NTLM イベントと既存の NTLM イベントの関係
新しい NTLM イベントは、 ネットワーク セキュリティ: このドメインでの NTLM 監査 NTLM 認証の制限など、既存の NTLM ログに対する機能強化です。 拡張 NTLM 監査の変更は、現在の NTLM ログには影響しません。現在の NTLM 監査ログが有効になっている場合、それらは引き続きログに記録されます。
展開方法に関する情報
Microsoft の制御された機能ロールアウト (CFR) に従って、変更は最初にWindows 11バージョン 24H2 マシンに段階的にロールアウトされ、その後、ドメイン コントローラーを含むWindows Server 2025 マシンが続きます。
段階的なロールアウトでは、一度にリリース更新プログラムを配布するのではなく、一定期間にわたって配布します。 つまり、ユーザーは異なる時間に更新プログラムを受け取り、すべてのユーザーがすぐに利用できるわけではありません。