Viewing events for assessing NTLM usage
Updated: November 21, 2012
Applies To: Windows 7, Windows 8, Windows Server 2008 R2, Windows Server 2012
This topic describes what events are recorded in the NTLM/Operational log when the Restrict NTLM audit or restrict settings are enforced.
In this topic
Finding NTLM version information
How to analyze the NTLM audit events
Finding NTLM version information
You can determine if the NTLM audit information in the event log pertains to NTLM v1 or NTLM v2, and which computer has preserved or downgraded the strength of the NTLM authentication. The Restrict NTLM audit and blocking policies have the same effect on both versions of NTLM so this investigation is optional.
Tip
For alternate ways to locate NTLM version and LM usage information, see Purging Old NT Security Protocols.
How to find version information
Open Event Viewer on the target computer.
Under Windows Logs, select the Security log.
For the list of security events, visually inspect the log to verify that Logon events are recorded.
To search the list of events in the log, use Find with the phrase “Authentication Package.”
Note
When searching the list of events on non-English versions of the Windows operating systems, adapt search terminology as appropriate.
For each event located, on the General tab, view the Authentication Package information under Detailed Authentication Information. If the package is NTLM, then the Package Name will state the version.
The following example shows the authentication package as “NTLM” and the Package Name as “NTLM V1.”
The events file is security.evtx. The name and path of the log can be found on the properties page of each individual log.
Detailed Authentication Information:Logon Process: NtLmSspAuthentication Package: NTLMTransited Services: -Package Name (NTLM only): NTLM V1Key Length: 128
The authentication information fields provide detailed information about this specific logon request.
The LUID (not shown) is a unique logon identifier that can be used to correlate this event with a KDC event.
Transited services indicate which intermediate services have participated in this logon request.
Package name indicates which sub-protocol was used among the NTLM protocols.
Key length indicates the length of the generated session key. This will be 0 if no session key was requested.
How to analyze the NTLM audit events
The key to implementing an NTLM blocking strategy is that you must be systematic and methodical. Analysis, depending on the complexity of your deployment, could span months. Your goal is to find applications that do not need to use NTLM and either update them or reconfigure them where possible. Some applications will be too costly to reconfigure, and you will need to determine an exception strategy where you allow NTLM on specific servers.
Expect to find the following applications using NTLM even if they theoretically support Kerberos:
Applications that allow various security configurations and providers.
Applications that have not been correctly configured with service principal names (SPNs).
Applications that use IP addresses instead of DNS names, due to misconfiguration or vendor documentation.
Applications with a legacy code base can have NTLM-only portions.
There are two methodologies for auditing applications: those that do not use server message block (SMB) protocol and those that do. You can determine SMB usage during your NTLM usage investigation by noting the PID event element when reviewing events on servers or domain controllers. If SMB is used, the authentication communication originates from kernel mode, which translates to a PID indicating the SYSTEM process. The following sections describe how to analyze both.
Auditing for applications that do not communicate over SMB
Applications that directly implement NTLM and use a protocol/transport other than SMB are generally easy to analyze. By enabling auditing, most NTLM usage will be quickly apparent. A key event element to note is PID. For non-SMB authentication traffic, this element will represent the process of the application that is sending the request. For information about all the available NTLM events, see Using event collection systems for assessing authentication usage.
Configurations
Settings enabled on all servers and clients: Network Security: Restrict NTLM: Audit Incoming NTLM Traffic
Settings enabled on all servers and clients: Network Security: Restrict NTLM: Outgoing NTLM traffic to remote servers set to Audit all.
Setting enabled on the domain controller: Network Security: Restrict NTLM: Audit NTLM authentication in this domain.
Event collection or investigation of Event 8004 (Source: NTLM) on the domain controller.
Analysis
What to look for in Event 8004 on the domain controller:
Logged – The date and time of the event.
Secure Channel name – The name of the member server the client computer connected to for the transitive logon. It is on this server you will investigate Event 8003.
User name – The account name.
Domain name – The domain name.
Workstation name – The computer to which the user name is associated for this event.
A DC event (Event 8004) might not transpire because a local user account could be connected to a file server and that would require NTLM.
What to look for in Event 8003 on the member server identified in the 8004 event as “Secure Channel name”:
Logged – The date and time of the event which should match or be close to that recorded in Event 8004.
User name – The account name.
Domain name – The domain name.
Workstation name – The computer to which the user name is associated for this event.
PID – Process identifier. If the local processing came in through Kernel mode (PID 4 is SYSTEM) you will need to examine Event 8001 on the client computer identified as “Workstation name”.
What to look for in Event 8001 on the client computer identified in the 8004 or 8003 event as “Workstation”:
Logged – The date and time of the event, which should match or be close to that recorded in Event 8004 or Event 8003.
Target server – This element contains the name or IP address of server intended to receive the NTLM request. If not in NetBIOS or FQDN format, then Kerberos will not be used.
Supplied user – This will match the user account name element in Event 8003 or Event 8004.
Supplied domain – This will match the Domain name element in Event 8003 or Event 8004.
Name of client process - The name of the application or service that made the request.
User identity of client process – Lists the user’s credentials that are being supplied to log on from that application (Name of client process). This might be different than the Supplied user name.
Working from the domain controller, you can investigate each usage of NTLM by computer, process, and user. You can identify if users are connecting to the IP address of web servers and not using the NetBIOS name or fully qualified domain name that would have allowed Kerberos to work. You can detect the credential level each application uses and if that is different than the user’s account. All of this information can be used to identify behaviors and misconfigurations that will cause NTLM to be used.
To understand ways to restrict NTLM as discovered from this investigation, see Possible actions in this topic.
Auditing for applications that do communicate over SMB
Applications that use a protocol/transport like SMB (through the redirector that handles connections) are more difficult to analyze. This is because all communication, often to Named Pipes, is through kernel mode. When auditing these types of applications, the only process ID (PID) that will appear is 4, which equates to SYSTEM. By enabling auditing you will be able to locate the computers. Then, by examining those computers under Process Monitor, the actual calling application will be revealed.
Configurations
Settings enabled on all servers and clients: Network Security: Restrict NTLM: Audit Incoming NTLM Traffic. This will allow Event ID 8001 to be logged on client computers.
Settings enabled on all servers: Network Security: Restrict NTLM: Outgoing NTLM traffic to remote servers set to Audit all. This will allow Event ID 8002 and 8003 to be logged on remote and member servers.
Setting enabled on the domain controller: Network Security: Restrict NTLM: Audit NTLM authentication in this domain. This will allow Event ID 8004 to be logged on the domain controller.
Install and configure your process monitoring software required for the following Analysis step.
Analysis
The analysis of the NTLM logs begins on the domain controller (or remote server) to identify the exact NTLM authentication request and the client computer computer making it. However, because some calling applications hide the process identifier (PID) in the SMB package, you will have to use additional evaluation tools to discover the calling applications PID. The Microsoft Process Monitor can be used to filter out superfluous traffic and focus on the client computer’s sending time stamps and the server’s receiving time stamps, and then correlate that to the actual application. For more information, download Process Monitor.
Important
Verify that you have downloaded the latest version of Process Monitor before using it.
For more information about using Process Monitor and restricting NTLM usage, see NTLM Blocking and You: Application Analysis and Auditing Methodologies in Windows 7.
What to look for in Event 8004 on the domain controller:
Logged – The date and time of the event.
Secure Channel name – The name of the member server the client computer connected to for the transitive logon. It is on this server you will investigate Event 8003.
User name – The account name.
Domain name – The domain name.
Workstation name – The computer to which the user name is associated for this event.
A DC event (Event 8004) might not transpire because a local user account could be connected to a file server and that would require NTLM.
What to look for in Event 8003 on the member server identified in the 8004 event as “Secure Channel name”:
Logged – The date and time of the event, which should match or be close to that recorded in Event 8004.
User name – The account name.
Domain name – The domain name.
Workstation name – The computer to which the user name is associated for this event.
PID – Process identifier. If the local processing came in through Kernel mode (PID 4 is SYSTEM), you will need to examine Event 8001 on the client computer identified in Event 8003 as “Workstation name.”
What to look for in Event 8001 on the client computer identified in the 8004 or 8003 event as “Workstation”:
Logged – The date and time of the event, which should match or be close to that recorded in Event 8004 or Event 8003.
Target server – This element contains the name or IP address of the server intended to receive the NTLM request. If not in NetBIOS or FQDN format, then Kerberos will not be used.
Supplied user – This will match the user account name element in Event 8003 or Event 8004.
Supplied domain – This will match the Domain name element in Event 8003 or Event 8004.
Name of client process - The name of the application or service tells you what made the request.
User identity of client process – Lists the user’s credentials that are being supplied to log on from that application (Name of client process). This might be different than the Supplied user name.
The PID of client process indicates that the client’s process is hidden in the SMB protocol because the actual caller for authentication is the redirector, which runs in the kernel. Therefore, to discover the client computer’s calling process, you will need to investigate the process activity using a tool such as Process Monitor. The following steps will guide you through what to look for.
On the computer sending NTLM credentials (Event ID 8001 element “Computer”), install the process monitoring software.
Filter the process scope on the monitor to the path of the remote server logging the 8003 events (which would be the Event ID 8003 element “Computer”) to both the computer name and the IP address. Consider running the monitor in background mode to collect a substantial sampling of data for later analysis.
Note
To allow the process monitor to run, you might need to elevate credentials of the user during this investigation phase.
- When you examine the monitor’s output from the client computer, compare it to the Event ID 8003 event element (which is the time stamp) logged on the server. The user, path, and authentication identifiers will correspond to audit events on the server and, consequently, identify the calling application.
Possible actions
The information from these events shows you the following information:
The NTLM authentication requests within the named domain would be blocked if Network Security: Restrict NTLM: NTLM authentication in this domain is set to any of the Deny options on the domain controller.
The NTLM authentication requests domain accounts managed by a single member server would be blocked if Network security: Restrict NTLM: Incoming NTLM traffic is set to “Deny all domain accounts” on a member server.
If you want to allow NTLM authentication requests in the named domain, set the security policy Network Security: Restrict NTLM: NTLM authentication in this domain to Disabled on the domain controller.
If you want to allow NTLM authentication requests to specific servers in the named domain, set the security policy Network Security: Restrict NTLM: NTLM authentication in this domain to Deny for domain servers or Deny domain accounts to domain servers, and then set the security policy Network Security: Restrict NTLM: Add server exceptions in this domain to define a list of servers in the named domain to which clients are allowed to use NTLM authentication.
If you want to restrict NTLM authentication requests to other servers running Windows Server 2012, Windows Server 2008 R2, Windows 8, or Windows 7, use the policy Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers, and select Deny all.
If you want to restrict specific client computers from using NTLM, use the policy Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers and select the Deny all.