First published on TechNet on Oct 08, 2009
Ned here again. Windows 7 and Windows Server 2008 R2 introduce a long sought feature known as NTLM blocking. This prevents NTLM from being used for authentication. IT works in both a send or receive mode, and allows you to create exceptions.
There’s currently very little documentation on this new capability, so I am going to get the ball rolling and talk about some techniques you can use to start evaluating if NTLM blocking will work for your network. Through the use of auditing techniques and application analysis, it is possible to correctly outline all NTLM use in an environment. This is a critical phase to complete before attempting to block NTLM – if you just start blocking arbitrarily you will likely have applications that stop working .
Don’t say I didn’t warn you.
Update Oct 11, 2023: We also just announced that a new local KDC is coming to Windows Insider Previews along with a replacement for KDC Proxy called IAKerb. These combined options mean the beginning of the end for NTLM. Read about it at The evolution of Windows authentication.
NTLM auditing and analysis recommendations
The key to rolling out NTLM blocking is that you must be systematic and take your time. I fully expect an NTLM blocking deployment to take at least 6 months of testing and analysis in a complex environment with hundreds of applications and thousands of computers. You may find applications that you had no idea were using NTLM, and they will need to be updated or reconfigured – that can really stretch out the timelines. Some elderly applications may simply use legacy code and will always require NTLM – this may cause you to abandon the blocking effort, or force you to come up with an exception strategy.
Below are some guidelines for your auditing and analysis phase:
- Deploy all three types of NTLM auditing (See Enabling NTLM Auditing below).
- Deploy the auditing in a test environment as long as all applications have been inventoried and there is no reasonable possibility of users running unknown applications in production.
- Deploy auditing in the production environment if not all applications can be inventoried.
- Deploy the incoming and outgoing auditing policies to all servers and computers. Deploy the domain auditing on DC's only; it will have no effect on member computers.
- NTLM blocking in environments that have Vista/2008/XP/2003 or older OS's is not recommended. NTLM cannot be blocked on them directly and auditing/remote exceptions will be very difficult.
- Come up with an audit event collection strategy. This may include third parties, Event Subscriptions , or other methods. The key is to make sure that the events are not lost. Make sure the NTLM audit event logs are increased to a large enough size that they do not constantly wrap.
- It is easier to monitor NTLM auditing on servers than clients - clients can be used for detailed analysis after server behaviors start becoming apparent.
Expect to find a large number of applications using NTLM even if they theoretically support Kerberos:
- Applications that allow various security configurations and providers (such as IIS or OCS)
- Applications that have not been correctly configured with Service Principal Names (such as SQL or SharePoint)
- 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 (i.e. they were originally written to work with Windows NT)
When you find these applications, contact your vendor for further support. If a Microsoft application, contact that support specialty. The Directory Services team does not know your applications!
Enabling NTLM Auditing
There are three security policies introduced in Win7/R2 that support auditing NTLM. When accessed through GPMC.MSC and you edit a policy, they are stored in:
Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\Security Options
To enable the deepest level of auditing, including both workgroup and domain authentication attempts that use NTLM, set:
Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers = Audit All
Network security: Restrict NTLM: Audit NTLM authentication in this domain = Enable all
Network security: Restrict NTLM: Audit Incoming NTLM Traffic = Enable auditing for all accounts
Note : Configure "Audit NTLM authentication in this domain" on DC's only. Configure "Outgoing NTLM traffic to remote servers" and "Audit Incoming NTLM Traffic" on all computers.
NTLM audit events are written out to this event log path:
Event Viewer (Local)\Applications And Services Logs\Microsoft\Windows\NTLM\Operationa
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.
Example walkthrough:
1. Settings "Audit Incoming NTLM Traffic" and "Outgoing NTLM traffic to remote servers" are enabled on all servers and clients. "Audit NTLM authentication in this domain" is enabled on the DC's.
2. Testers and users are evaluating various applications in the environment.
3. 8004 events are being seen on the DC's - examination of DC 2008r2-f-01 shows:
Log Name: Microsoft-Windows-NTLM/Operational
Source: Microsoft-Windows-Security-Netlogon
Date: 9/25/2009 10:47:36 AM
Event ID: 8004
Task Category: Auditing NTLM
Level: Information
Keywords:
User: SYSTEM
Computer: 2008r2-f-01.contoso.com
Description:
Domain Controller Blocked Audit: Audit NTLM authentication to this domain controller.
Secure Channel name: 2008R2-F-04
User name: roberg
Domain name: CONTOSO
Workstation name: 7-X64-01
Secure Channel type: 2
3. Note the important information here - the time, user, domain, transitive logon, and originating workstation are all listed. User RoberG in the Contoso domain used NTLM to connect from his client 7-x64-01 to his server 2008r2-f-04 on Sept 25th at 10:47:36 AM .
Also note that a DC event is not guaranteed - for example a local user account could be connected to a file server and that would require NTLM.
4. 8003 events are being seen on the member servers - examination of server 2008r2-f-04 shows:
Log Name: Microsoft-Windows-NTLM/Operational
Source: Microsoft-Windows-NTLM
Date: 9/25/2009 10:47:36 AM
Event ID: 8003
Task Category: Auditing NTLM
Level: Information
Keywords:
User: SYSTEM
Computer: 2008r2-f-04.contoso.com
Description:
NTLM server blocked in the domain audit: Audit NTLM authentication in this domain
User: roberg
Domain: CONTOSO
Workstation: 7-X64-01
PID: 4
Process:
Logon type: 3
InProc: true
Mechanism: (NULL)
Note how on the member server you have the 8003 event at the same time for the same user from the same client as in Step 3. You cannot see the Process ID though as - in this particular instance - the local processing came in through Kernel mode (PID 4 is SYSTEM). This means you will need to examine the client.
5. 8001 events are logged on the clients that were seen in steps 3 and 4 and show the final important details:
Log Name: Microsoft-Windows-NTLM/Operational
Source: Microsoft-Windows-NTLM
Date: 9/25/2009 10:47:36 AM
Event ID: 8001
Task Category: Auditing NTLM
Level: Information
Keywords:
User: SYSTEM
Computer: 7-x64-01.contoso.com
Description:
NTLM client blocked audit: Audit outgoing NTLM authentication traffic that would be blocked.
Target server: HTTP/10.70.0.106
Supplied user: roberg
Supplied domain: CONTOSO
PID of client process: 3416
Name of client process: C:\Program Files (x86)\Internet Explorer\iexplore.exe
LUID of client process: 0x384a35
User identity of client process: Administrator
Domain name of user identity of client process: CONTOSO
Mechanism OID: (NULL)
Note how the actual problem is now clear - users are connecting to the IP address of web servers, not the NetBIOS name or fully qualified domain name that would have allowed Kerberos to work. Furthermore you can see they were using Internet Explorer, so you know the application. Finally you can see that the user running the application is different from the credentials being supplied to logons from that application. All of this information will be helpful info in identifying behaviors and misconfigurations that will cause NTLM to be used.
Auditing for applications that do communicate over SMB
Applications that use a protocol/transport like SMB (via the redirector) are more difficult to analyze. This is because all communication - often to Named Pipes - is through kernel mode and the SMB client and redirector drivers.
When auditing these types of applications the only process ID (PID) that will appear is 4 - i.e. 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 become visible.
Example walkthrough:
1. Settings "Audit Incoming NTLM Traffic" and "Outgoing NTLM traffic to remote servers" are enabled on all servers and clients. "Audit NTLM authentication in this domain" is enabled on the DC's.
2. Testers and users are evaluating various applications in the environment.
3. 8004 events are being seen on the DC's - examination of DC 2008r2-f-01 shows:
Log Name: Microsoft-Windows-NTLM/Operational
Source: Microsoft-Windows-Security-Netlogon
Date: 9/30/2009 5:13:21 PM
Event ID: 8004
Task Category: Auditing NTLM
Level: Information
Keywords:
User: SYSTEM
Computer: 2008r2-f-01.contoso.com
Description:
Domain Controller Blocked Audit: Audit NTLM authentication to this domain controller.
Secure Channel name: 2008R2-F-04
User name: Administrator
Domain name: CONTOSO
Workstation name: 7-X64-01
Secure Channel type: 2
Note the important information here - the time, user, domain, transitive logon, and originating workstation are all listed. User Administrator in the Contoso domain used NTLM to connect from his client 7-x64-01 to his server 2008r2-f-04 on Sept 30th at 5:13:21 PM .
Also note that a DC event is not guaranteed - for example a local user account could be connected to that would require NTLM.
4. 8003 events are being seen on the member servers - examination of server 2008r2-f-04 shows:
Log Name: Microsoft-Windows-NTLM/Operational
Source: Microsoft-Windows-NTLM
Date: 9/30/2009 5:13:21 PM
Event ID: 8003
Task Category: Auditing NTLM
Level: Information
Keywords:
User: SYSTEM
Computer: 2008r2-f-04.contoso.com
Description:
NTLM server blocked in the domain audit: Audit NTLM authentication in this domain
User: Administrator
Domain: CONTOSO
Workstation: 7-X64-01
PID: 4
Process:
Logon type: 3
InProc: true
Mechanism: (NULL)
Note how on the member server you have the 8003 event at the same time for the same user from the same client as in Step 3. You cannot see the Process ID though as the local processing in this case came in through Kernel mode (PID 4 is SYSTEM). This means you will need to examine the client.
5. 8001 events are logged on the clients that were seen in steps 3 and 4 and show the final important details.
Log Name: Microsoft-Windows-NTLM/Operational
Source: Microsoft-Windows-NTLM
Date: 9/30/2009 5:13:21 PM
Event ID: 8001
Task Category: Auditing NTLM
Level: Information
Keywords:
User: SYSTEM
Computer: 7-X64-01.contoso.com
Description:
NTLM client blocked audit: Audit outgoing NTLM authentication traffic that would be blocked.
Target server: cifs/10.70.0.106
Supplied user: (NULL)
Supplied domain: (NULL)
PID of client process: 4
Name of client process:
LUID of client process: 0x14e5b2
User identity of client process: Administrator
Domain name of user identity of client process: CONTOSO
Mechanism OID: (NULL)
Examining the client shows us that SMB (CFS) is being used, but the process is still 4 for SYSTEM. This is because any application authenticating while using SMB as a transport is going through the client redirector in kernel mode. The actual calling application is opaque to the auditing, because the actual caller for authentication is the redirector, which runs in the kernel. So you will need to dig deeper with Process Monitor.
6. Install Process Monitor on the computer that is sending NTLM credentials through SMB (in this case, 7-X64-01.contoso.com ). Process monitor can be downloaded from https://learn.microsoft.com/sysinternals/downloads/procmon.
7. Set a filter in Process Monitor for the Path to start with the remote server throwing 8003 events. Make sure to set the filter for both the computername and the IP address. This will require giving the user of that computer Admin rights temporarily, during this analysis phase. Alternatively, this could be done through boot logging so that PM is always running silently in the background (note: filtering does not apply with boot logging, so ensure you have plenty of free disk space in that case).
Path \ begins with \ <server name> \ Include
Path \ begins with \ <server IP address> \ Include
Example:
8. Wait for the issue to reproduce through user application use.
9. Examine the Process Monitor log output and compare the time stamps to when the 8003 events occurred. Applications that call into SMB will (hopefully) be easily discernable in the log data.
For example:
Explorer.EXE 2300 FileSystemControl \\10.70.0.106\IPC$
Explorer.EXE 2300 FileSystemControl \\10.70.0.106\IPC$
Explorer.EXE 2300 CloseFile \\10.70.0.106\IPC$
Explorer.EXE 2300 QueryOpen \\10.70.0.106\SharedData\
Explorer.EXE 2300 CreateFile \\10.70.0.106\SharedData\
Explorer.EXE 2300 QueryBasicInformationFile \\10.70.0.106\SharedData\
Explorer.EXE 2300 QueryBasicInformationFile \\10.70.0.106\SharedData\
Explorer.EXE 2300 CloseFile \\10.70.0.106\SharedData\
By modifying the Process Monitor column headers, you can also correlate the time, user, and authentication ID's seen in the 8001 events:
Note how the time, user, path, and authentication ID all line up with the previous NTLM audit events. Explorer is the calling application. Further investigation and interview of the end user determines that they are mapping drives by IP address, forcing the use of NTLM.
More Information and the Big Finish
For the current NTLM restriction information, see Introducing the Restriction of NTLM Authentication | Microsoft Learn
NTLM blocking does not totally turn off NTLM on a computer. After all, a local logon uses NTLM. So if you are at home and log on with your computername\user account, the logon will work even if NTLM is disabled fully through group policy. Your Windows 7 client does not run a local KDC after all…
NTLM blocking is no joke. I didn’t bother to discuss how you actually disable NTLM here because you’re not ready to do it yet. NTLM blocking can be a résumé generating event!
- Ned “seriously, just audit for now” Pyle
Microsoft
