Removing NTLM from a Windows-heavy IT environment based on Active Directory can be a daunting task. Up until now, traditional guidance suggests that you

• enable NTLM and logon audit logging provided by Windows since Server 2008R2
• collect events from all sources for a period of time
• correlate these events and divine what’s happening from them
• correct issues found and achieve NTLM-free infrastructure.

In practice, this approach results in tons of logs, mostly telling you about the same thing happening throughout the environment with limited guidance to pinpoint exactly what actual confiuguration has ultimately led to the NTLM authentication attempts you observe. This is especially true for SMB access since logging will only tell you which clients access which servers on behalf of which users.

An approach that holds more promise of getting done

You have already waited 25 years to get rid of NTLM, an additional week or so is not going to make a difference if you assume an enginneer’s approach to this instead of trying to heal the wounds by big data analysis. So let’s move the goalposts a bit:

1. First order of business is to ensure that your privileged identities do not use NTLM anymore and can be prevented from doing so in the future without anything breaking.
2. Let’s not concern ourselves with NTLM resulting from local account usage for the time being. First and foremost, we want to protect Active Directory identities. You can still give the question why local accounts have to be used on domain members some thought, but that can wait and may not be something you can do anything about just now.

To achieve these modified but more realistic goals,

1. Find and fix those pesky misconfigurations that can – or indeed do – lead to NTLM being used where Kerberos would also work if everything was configured properly.
2. Collect logs from Domain Controllers – they will already tell you what users, servers and clients are involved. If you are not seeing privileged users in these logs, the first milestone has already been achieved, and you can apply protections like Protected Users group or Authentication Policies to those accounts, banning them from NTLM once and for all.
3. If knowing what servers are being targeted by what clients with NTLM is not enough to determine what exactly is causing it, we can then enable server-side logging surgically, on machines that are actually participating in NTLM. This way, we will not have to process the local account authentication attempts from machines where no domain accounts are using NTLM against.
4. Only if there are situations where you absolutely cannot determine the source of NTLM authentication attempts, you can enable client logging in a super surgical way to get to the bottom of it.

The general idea is to process less data at the right time to achieve faster, better results.

Enter NTLMinator

NTLMinator is a four-step program facilitating the above approach:

• IDENTIFY: look for known misconfiugurations (potentially) leading to NTLM fallback
• RECTIFY: fix the misconfiugurations found in the first step
• INVESTIGATE: use surgical log analysis to pinpoint the remaining NTLM sources
• ELIMINATE: remove or isolate the applications found to cause NTLM fallback, use logs to monitor progress

This website will take you through the process, but it also offers the toolkit to automate most of it.