Original publish date: July 11, 2025
KB ID: 5064479
In this article:
- Introduction
- Purpose of NTLM auditing changes
- NTLM auditing logs
- Group Policy management
- Audit levels
- Client logs
- Server logs
- Domain controller logs
- Relationship between new and existing NTLM events
- Deployment information
- Change log
Introduction
This article provides an overview of upcoming enhancements to NT LAN Manager (NTLM) auditing in Windows 11, version 24H2 and later, and Windows Server 2019 and later. These enhancements provide greater visibility into NTLM authentication activity, helping administrators identify which users rely on NTLM, why it is used, and where it is used within their environment.
Enhanced NTLM auditing is available in the following Windows versions:
- Windows 11, version 24H2 and later
- Windows Server 2025
- Windows Server 2022 (available in the Windows updates released on and after October 13, 2026 (such as KB5126655)
- Windows Server 2019 (available in the Windows updates released on and after October 13, 2026 (such as KB5126651)
Enhanced auditing supports improved security monitoring and helps organizations identify legacy authentication dependencies as they prepare to reduce their reliance on NTLM.
Purpose of NTLM auditing changes
NTLM authentication continues to be present in various enterprise scenarios, often due to legacy applications and configurations. With the announcement of NTLM deprecation and future disablement (see the Windows IT Blog The evolution of Windows authentication) the updated auditing features are intended to assist administrators in identifying NTLM usage, understanding usage patterns, and detecting potential security risks, including the use of NT LAN Manager version 1 (NTLMv1).
NTLM auditing logs
Windows 11, version 24H2 and later, Windows Server 2025, Windows Server 2022, and Windows Server 2019 support enhanced NTLM audit logging capabilities for clients, servers, and domain controllers. Each component generates logs that provide detailed information regarding NTLM authentication events. These logs can be found in Event Viewer under Applications and Services Logs > Microsoft > Windows > NTLM > Operational.
As compared to existing NTLM auditing logs, the new enhanced auditing changes allow administrators to answer the Who, the Why, and the Where:
- Who is using NTLM, including the account and process on the machine.
- Why NTLM authentication was chosen, instead of modern authentication protocols like Kerberos.
- Where the NTLM authentication is happening, including both the machine name and the machine IP.
The enhanced NTLM auditing also provides information about NTLMv1 usage for clients and servers, as well as NTLMv1 usage domain-wide logged by the domain controller.
Group Policy management
The new NTLM auditing features are configurable through updated Group Policy settings. Administrators can use these policies to specify which NTLM authentication events are audited and to manage auditing behavior across clients, servers, and domain controllers as appropriate for their environment.
By default, the events are enabled.
For client and server logging, the events are controlled through the “NTLM Enhanced Logging” policy under Administrative Templates > System > NTLM.
For domain-wide logging on the domain controller, the events are controlled through the “Log Enhanced Domain-wide NTLM Logs” policy under Administrative Templates > System > Netlogon.
Audit levels
Each NTLM audit log is split into two different Event IDs with the same information that only differ by event level:
- Information: Indicates standard NTLM events, such as NT LAN Manager version 2 (NTLMv2) authentication, where no reduction in security is detected.
Warning: Indicates a downgrade of NTLM security, such as the use of NTLMv1. These events highlight insecure authentication. An event might be marked as a “Warning” for instances such as the following:
- NTLMv1 usage detected by either the client, server, or domain controller.
- Enhanced Protection for Authentication is marked as not supported or insecure (for more information, see KB5021989: Extended Protection for Authentication).
- Certain NTLM security features, such as the message integrity check (MIC), are not used.
Client logs
New audit logs record outgoing NTLM authentication attempts. These logs supply details about the applications or services initiating NTLM connections, along with relevant metadata for each authentication request.
Client logging has a unique field, Usage Id/Reason, which highlights why NTLM authentication was used.
Current "Usage Id/Reason" field descriptions
| ID | Description |
|---|---|
| 0 | Unknown Reason. |
| 1 | NTLM was called directly by the calling application. |
| 2 | Authenticating a Local Account. |
| 3 | RESERVED, currently not in use. |
| 4 | Authenticating a Cloud Account. |
| 5 | The target name was missing or empty. |
| 6 | The target name could not be resolved by Kerberos or other protocols. |
| 7 | The target name contains an IP address. |
| 8 | The target name was found to have been duplicated in Active Directory. |
| 9 | No Line of Sight could be established with a Domain Controller. |
| 10 | NTLM was called via a loopback interface. |
| 11 | NTLM was called with a null session. |
Example client log
| Event Log | Microsoft-Windows-NTLM/Operational |
|---|---|
| Event ID | 4020 (Information), 4021 (Warning) |
| Event Source | NTLM |
| Event Text | This machine attempted to authenticate to a remote resource via NTLM. Process Information: Process Name: <Name> Process PID: <PID> Client Information: Username: <Username> Domain: <Domain Name> Hostname: <Host Name> Sign-On Type: <Single Sign-On / Supplied Creds> Target Information: Target Machine: <Machine Name> Target Domain: <Machine Domain> Target Resource: <Service Principal Name (SPN)> Target IP: <IP Address> Target Network Name: <Network Name> NTLM Usage: Reason ID: <Usage ID> Reason: <Usage Reason> NTLM Security: Negotiated Flags: <Flags> NTLM Version: <NTLMv2 / NTLMv1>; Session Key Status: <Present / Missing> Channel Binding: <Supported / Not Supported> Service Binding: <Service Principal Name (SPN)> MIC Status: <Protected / Unprotected> AvFlags: <NTLM Flags> AvFlags String: <NTLM Flag String> For more information, see aka.ms/ntlmlogandblock. |
Server logs
New audit logs record incoming NTLM authentication attempts. These logs supply similar details about the NTLM authentication as the client logs, as well as report whether the NTLM authentication succeeded or not.
Example server log
| Event Log | Microsoft-Windows-NTLM/Operational |
|---|---|
| Event ID | 4022 (Information), 4023 (Warning) |
| Event Source | NTLM |
| Event Text | A remote client is using NTLM to authenticate to this workstation. Process Information: Process Name: <Name> Process PID: <PID> Remote Client Information: Username: <Client Username> Domain: <Client Domain> Client Machine: <Client Machine Name> Client IP: <Client IP> Client Network Name: <Client Network Name> NTLM Security: Negotiated Flags: <Flags> NTLM Version: <NTLMv2 / NTLMv1> Session Key Status: <Present / Missing> Channel Binding: <Supported / Not Supported> Service Binding: <Service Principal Name (SPN)> MIC Status: <Protected / Unprotected> AvFlags: <NTLM Flags> AvFlags String: <NTLM Flag String> Status: <Status Code> Status Message: <Status String> For more information, see aka.ms/ntlmlogandblock |
Domain controller logs
Domain controllers benefit from enhanced NTLM auditing, with new logs that capture both successful and unsuccessful NTLM authentication attempts for the entire domain. These logs support identification of cross-domain NTLM usage and alert administrators to potential downgrades in authentication security, such as NTLMv1 authentication.
Different domain controller logs are created depending on the following scenarios:
Same-domain log
When both the client account and server machine belong to the same domain, a log similar to the following is created:
| Event Log | Microsoft-Windows-NTLM/Operational |
|---|---|
| Event ID | 4032 (Information), 4033 (Warning) |
| Event Source | Security-Netlogon |
| Event Text | The DC <DC Name> processed a forwarded NTLM authentication request originating from this domain. Client Information: Client Name: <Username> Client Domain: <Domain> Client Machine: <Client workstation> Server Information: Server Name: <Server Machine Name> Server Domain: <Server Domain> Server IP: <Server IP> Server OS: <Server Operating System> NTLM Security: Negotiated Flags: <Flags> NTLM Version: <NTLMv2 / NTLMv1> Session Key Status: <Present / Missing> Channel Binding: <Supported / Not Supported> Service Binding: <Service Principal Name (SPN)> MIC Status: <Protected / Unprotected> AvFlags: <NTLM Flags> AvFlags String: <NTLM Flag String> Status: <Status Code> Status Message: <Status String> For more information, see aka.ms/ntlmlogandblock |
Cross-domain log
If the client account and server belong to different domains, then the domain controller will have different logs depending on if the domain controller belongs to the domain where the client resides (initiating the authentication) or where the server resides (accepting the authentication):
If the server belongs to the same domain as the domain controller that is handling the authentication, a log similar to the “Same-domain log” is created.
If the client account belongs to the same domain as the domain controller that is handling the authentication, a log similar to the following is created:
| Event Log | Microsoft-Windows-NTLM/Operational |
|---|---|
| Event ID | 4030 (Information), 4031 (Warning) |
| Event Source | Security-Netlogon |
| Event Text | The DC <DC Name> processed a forwarded NTLM authentication request originating from this domain. Client Information: Client Name: <Username> Client Domain: <Domain> Client Machine: <Client workstation> Server Information: Server Name: <Server Machine Name> Server Domain: <Server Domain> Forwarded From: Secure Channel Type: <Netlogon Secure Channel Info> Farside Name: <Cross-Domain DC Machine Name> Farside Domain: <Cross-Domain Domain Name> Farside IP: <Cross-Domain DC IP> NTLM Security: Negotiated Flags: <Flags> NTLM Version: <NTLMv2 / NTLMv1> Session Key Status: <Present / Missing> Channel Binding: <Supported / Not Supported> Service Binding: <Service Principal Name (SPN)> MIC Status: <Protected / Unprotected> AvFlags: <NTLM Flags> AvFlags String: <NTLM Flag String> Status: <Status Code> For more information, see aka.ms/ntlmlogandblock |
Relationship between new and existing NTLM events
The new NTLM events are an enhancement over the existing NTLM logs, such as Network security: Restrict NTLM Audit NTLM authentication in this domain. The enhanced NTLM auditing changes do not affect the current NTLM logs; if the current NTLM auditing logs are enabled, they will continue to be logged.
Deployment information
Enhanced NTLM auditing is available on Windows 11, version 24H2 and later and Windows Server 2025.
Starting October 13, 2026, enhanced NTLM auditing is also available for Windows Server 2022 and Windows Server 2019. To use enhanced NTLM auditing on these versions, install the Windows update released on or after October 13, 2026.
After deploying the appropriate Windows update, administrators can use the enhanced NTLM events to identify NTLM usage across clients, servers, and domain controllers and begin investigating dependencies that might prevent authentication from using Kerberos or another more secure authentication protocol.
Change log
| Change date | Change decription |
|---|---|
| October 13, 2026 | Added information about this now applying to Windows Server 2016 and Windows Server 2019 starting with Windows updates released on and after October 13, 2026. |