I've worked for IT security service providers, and every now and then the job was to turn off NTLM in an Active Directory domain. Windows logs a lot of NTLM activity, so in theory you have everything you need. In practice you have to piece it all together yourself. There was never a quick and easy way to see which user or process still uses NTLMv1 or NTLMv2, or which programs already use Kerberos.
The information is spread over every machine in the domain. Event 8001 on the client tells you which process sent NTLM. Event 8003 on the server tells you which service accepted it. Event 8004 on the domain controller tells you who authenticated against what. And on anything older than Server 2025, the NTLM version is only in the 4624 logon event on the server. Some of these events don't even have named fields, Microsoft ships them as a plain list of values.
So I built a tool for it, for myself and for anyone else who has to do the same job. It's called NTLM-Analyzer.
What it is
It has two parts, and I wanted both of them to be as simple as possible.
The collector runs on Linux and is based on Python. It's one single file without any additional dependencies, so no pip install and no database server, everything goes into SQLite. You just start it and you're done. If you want it to run as a service, there is an installer script that does everything automatically. It even creates its own service account and runs the collector under it. The collector also serves the web dashboard.
On Windows you only need a small agent written in Rust, on every machine you want to see, domain controllers included. It runs as a Windows service, reads the NTLM and logon events and sends them to the collector. It's a single EXE, or an MSI if you want to install it unattended. The agent doesn't listen on any port, it only sends.
If you want to see it before you install anything, there is a live demo with the real dashboard on made-up lab data. Everything works there, including the search, the filters and the detail views.
The first thing you see is the share of logons that still go through NTLM, and whether it's going down. The bar below it is the handover: red is NTLMv1, yellow NTLMv2, green Kerberos. The goal is a bar that's completely green.
What it shows you
Who still uses NTLMv1. That's the first thing I always wanted to know, because NTLMv1 is the urgent part. The dashboard lists every account with how often it used NTLMv1. It also tells you where it can't see NTLMv1, for example on a machine without logon auditing. An empty list there doesn't automatically mean "no NTLMv1".
Which program uses NTLM, and against which server. This is the work list. Every program with its target, how often, the trend and the users behind it. You can set each row to open, in progress or done. If something you marked as done shows up again, it gets an "active again" badge.
Why it wasn't Kerberos. This panel turns the findings into fixes. On Windows 11 24H2 and Server 2025 the new NTLM events contain the reason why Kerberos wasn't used. On older systems the tool takes the failed Kerberos requests instead (event 4769, for example 0x7 for "SPN not found"). Every reason comes with what usually fixes it. The classic is still a script or a drive mapping that uses an IP address instead of a host name.
Since version 2.4 there is also an SPN check. A domain controller with the agent looks up in AD every service name that clients fell back to NTLM for. It tells you if the SPN is missing, registered twice, or only registered for the real server name while the clients use an alias. You get the setspn command to fix it. The lookup is read-only, the tool itself never changes anything in AD.
What already runs over Kerberos. The good side, for contrast. Here you also see which services still get RC4 tickets.
When NTLM happens. A heatmap with weekdays against hours. A batch job that runs once a week at night disappears in the daily numbers. Here it stands out right away, and that's exactly the kind of thing that breaks after you switch NTLM off.
Which machines are ready. A machine counts as ready when auditing is on, it was watched for 30 days and there was no NTLM in that time. Then you can set "Restrict NTLM" to deny there. For the ones that aren't ready, you see what is still using NTLM.
There is a lot more in it: failed NTLM logons with the reason in plain words, password spraying, machines that use NTLM but run no agent, and a CSV export. And there is a status report that you can print or save as PDF, in German or English, for everyone who will never open a dashboard.
Getting started
The short version. The README has the details, and the operations guide has everything else.
1. Turn on auditing by GPO. Without it nothing gets logged, and the events only start from the moment auditing is on, not retroactively.
| Where | Setting | Value |
|---|---|---|
| All machines | Restrict NTLM: Outgoing NTLM traffic to remote servers | Audit all |
| All machines | Restrict NTLM: Audit Incoming NTLM Traffic | Enable auditing for domain accounts |
| Domain controllers | Restrict NTLM: Audit NTLM authentication in this domain | Enable all |
| DCs and member servers | Advanced Audit Policy: Audit Logon | Success and Failure |
Make sure you choose Audit all and not Deny all. Auditing only logs, it doesn't block anything.
2. Install the collector on a Linux server, from the cloned repository:
sudo ./install.sh
The script asks a few questions (port, API key for the agents, how long to keep the data, TLS certificate), creates the service account and the systemd service, and opens the port in the firewall if you want. At the end it prints the exact command for the agent install. If you only want to try it quickly, you can also just run python3 ntlm-collector.py, and --help shows all options.
3. Install the agent on every Windows machine. That's the small Rust agent from above, you find the MSI in the releases:
msiexec /i ntlm-agent.msi /qn COLLECTORURL=https://collector.example.local:8443
By default the agent runs as LocalSystem. If you prefer least privilege, it also runs as a gMSA.
4. Open the dashboard. In the machine list every agent should show up with a green heartbeat, and the audit badges turn green once the GPO has arrived on the machine.
Before you switch NTLM off
The tool tells you what still uses NTLM. It does not switch anything off, and that's on purpose. A few things I would check before you do:
- Let it run for at least two weeks. Weekly tasks and month-end jobs only show up over time. The dashboard warns you as long as there are less than 14 days of data.
- Make the NTLM log bigger. The default size of the NTLM/Operational log is only about 1 MB. Once incoming auditing is on, it can roll over between two collection runs, and those events are gone.
wevtutil sl Microsoft-Windows-NTLM/Operational /ms:20971520sets it to 20 MB. - Set
LmCompatibilityLevelto 5 first. A machine can go months without a single NTLMv1 logon and still allow it. The machine list shows the level for every machine. - Clients and member servers first, domain controllers last. And make sure you have console access to at least one DC (iLO, iDRAC, vSphere) before you enforce anything there.
- Look at October 2026. Microsoft switches NTLMv1-derived SSO credentials to blocking by default this month. Whatever still uses them breaks on its own. Machines with Credential Guard aren't affected, because Credential Guard already prevents NTLMv1. The machine list shows which ones are.
And one warning that I want to repeat, because it's the one that hurts the most: MS-CHAPv2 is invisible. RADIUS, 802.1X and NPS with MS-CHAPv2 don't show up in any NTLM audit event. But they still break as soon as your domain controllers block NTLM. So your Wi-Fi or your network access control can go down while the dashboard looks completely green. If you still use MS-CHAPv2, plan the move to something like EAP-TLS before you restrict NTLM.
Where it stands
The current version is 2.4.0. The collector has 67 tests and the agent 34, and they run on every push. I tested everything in a real AD environment. The only exception is the new SPN check, which so far I could only test against a simulated directory. If it reports a name wrongly, ntlm-agent.exe spn-check <spn> on a DC shows exactly what AD answered. Please open an issue with that output.
To be transparent, like in the README: most of the code was written by Claude in a pair-programming workflow. I defined what it should do, reviewed it and tested it. So please review it before you use it in production, like any code you didn't write yourself.
It's GPLv3 licensed and on GitHub:
github.com/Nobrac/NTLM-Analyzer
If you run it in your domain, I'd like to hear what it found.
Licensed under CC BY-NC-SA 4.0.