Mustafa ERBAY

Posted on Sep 11 Originally published at mustafaerbay.com.tr

NTLM Is Being Switched Off: Find the Fallback Reason First

#activedirectory #kerberos #windowsserver #security

Two days before I started this piece, on September 9, Microsoft's Windows IT Pro team published a Q&A titled "Retiring NTLM". Its opening paragraph thanks a thirty-three-year-old protocol for its service, then says they are, respectfully, showing it the door. The protocol being shown the door is the understudy that still steps in silently, in every Active Directory environment, whenever Kerberos stumbles: NTLM.

I've kept this job in the "someday" box for years. The lid came off in 2026. The roadmap published in January makes NTLM off by default on the network in the next major Windows Server release. Every NTLM session that runs quietly today will, on the day you move to that release, either become a deliberate exception or break.

Let me state the thesis up front: switching NTLM off is not a Group Policy job, it's an inventory job. The off switch has been there since Windows Server 2008 R2 and nobody could press it, because nobody knew what would break when they did. What changed in 2026 isn't the switch — it's the log that tells you what will break.

Why NTLM is still here

Applications on Windows mostly don't ask for NTLM; they ask for Negotiate. Negotiate tries Kerberos first and drops to NTLM if that fails. The design has worked for thirty years, and that is precisely why NTLM never died: every Kerberos failure surfaced to the user not as an error but as a working NTLM session. Black boxes have their worst nights without telling anyone; NTLM fallback is exactly that kind of black box.

The four-way classification in Microsoft's own FAQ is, I think, the most honest summary. Breakage comes from hardcoded NTLM (the app explicitly requests NTLM instead of Negotiate), from missing Kerberos prerequisites (no SPN, the target is an IP address, no line of sight to a DC), from a legacy protocol or device dependency (a device that only speaks NTLM, a third-party SMB client), or from local-account flows. Until you know which of those four boxes is full in your environment, no disablement plan can be written.

Three phases, one goal

The January 2026 roadmap defines three phases and says in the same post that timelines may change; I read it that way too.

Phase 1 — visibility. Enhanced NTLM auditing is already in your hands: it ships on Windows Server 2025 and Windows 11 24H2 and later. This entire phase exists to answer "where, and why".

Phase 2 — the biggest blockers. IAKerb and LocalKDC make Kerberos possible for clients without line of sight to a DC and for local accounts; Windows's own components are being updated to negotiate Kerberos first. The target is the second half of 2026 for Windows Server 2025 and Windows 11 24H2 and later. Both features are in the Canary-channel preview announced in June.

Phase 3 — off by default. In the next major Windows Server release and the client releases that accompany it, network NTLM is disabled by default; anyone who wants it re-enables it explicitly through policy. Built-in handling for the classic NTLM-only cases — targets with unknown SPNs, authentication by IP address, local accounts on domain-joined machines — arrives in the same release.

Microsoft is also explicit about what "off by default" is not: the NTLM code stays in Windows for a while and can be re-enabled via policy. Removal is a longer-term goal; per the FAQ, the ability to re-enable will be narrowed over time. Read that as a temporary licence for the next release, not a permanent exit door.

One note on formal status: NTLM — LANMAN, v1 and v2 included — has been on Windows's deprecated-features list since June 2024. Deprecated means it still works but receives no further development; in 2026 that status evolved into "to be disabled".

NTLMv1 is a separate story, and a closer one

There's no waiting for NTLMv1; that door is already shut. Microsoft removed the NTLMv1 protocol from Windows 11 24H2 and Windows Server 2025 — the November 2024 update on the deprecated-features page calls it "removed". But per the same documentation, remnants of NTLMv1 cryptography remain in some scenarios: MS-CHAPv2 in a domain-joined environment. If you use MS-CHAPv2 single sign-on for Wi-Fi, wired 802.1X or VPN, you are still generating NTLMv1-derived credentials.

There's a dedicated registry value for that: BlockNtlmv1SSO under HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0. At 0 (today's default) it's in "Audit" mode — the request to generate NTLMv1 credentials for a logged-on user is logged but allowed to succeed; event ID 4024, warning level. At 1 it's in "Enforce" mode — the request is blocked and a 4025 error event is written. Auditing was enabled from August 2025 on clients and from November 2025 on Windows Server 2025.

The date that matters: in October 2026 the default flips from 0 to 1, from Audit to Enforce. Today is September 11; close to a month left. If you have an NPS/RADIUS deployment authenticating with MS-CHAPv2, start counting 4024 events today — but in the right place: the event is written not on the NPS server but in the NTLM/Operational log of the 24H2/2025 clients doing MS-CHAPv2 single sign-on. When those turn into 4025s in October, the wireless network won't collapse; single sign-on will. The document says so explicitly: manually entering credentials keeps working even in Enforce mode. Picture a Tuesday when the help desk fills with "Wi-Fi has been asking for my password all morning" calls: what broke was announced a year ago. The advice in Microsoft's AD hardening series is unambiguous: move to EAP-TLS.

Two exceptions from the same document, because they change the plan. First: on devices with Credential Guard enabled, this change doesn't apply at all; Credential Guard already cuts off NTLMv1 cryptography, with far broader protection besides. Second: the default flip to Enforce only takes effect if the BlockNtlmv1SSO key has never been deployed to the device. Deploy it explicitly as 0 and October doesn't wait for you. That is a deferral tool; in my view it should only be used with an end date written on the calendar, otherwise Audit mode stays "temporary" for years.

One nuance, straight from the source, because it gets muddled in the field: Windows Server 2025 can no longer request NTLMv1, but 2025 domain controllers still accept NTLMv1 during credential validation — the same behaviour as LmCompatibilityLevel=4. So upgrading your DCs to 2025 does not, by itself, stop an old device from joining with NTLMv1. Blocking happens through your policy — the "Send NTLMv2 responses only. Refuse LM & NTLM" option of "Network security: LAN Manager authentication level", i.e. LmCompatibilityLevel=5; at that level DCs accept only NTLMv2. And I think the hardening series has the order right: before disabling NTLM wholesale, deal with NTLMv1, SMBv1 and SMB signing. Those are the more easily exploited side.

The new log: event 4020 and its reason codes

In the old world there were three ways to count NTLM and all three gave half an answer. Event 4776 on the DC gives you the account name and the source workstation, not the target. Event 4624 on the accessed server gives you the account, the client and the NTLM version, not the process. The 8001-8006 events that come with the "Restrict NTLM" audit policies add the process name but don't say why NTLM was chosen. Even combining all three, you had little more than "something is using NTLM".

Enhanced auditing fills that gap. Events land under Applications and Services Logs > Microsoft > Windows > NTLM > Operational: on the client 4020 (information) and 4021 (warning), on the server 4022/4023, on the domain controller 4032/4033; for cross-domain authentication, the DC of the account's own domain additionally writes 4030/4031. The level is a signal: information means NTLMv2 and no security downgrade; warning means NTLMv1 or another downgrade. Client/server logging is governed by the "NTLM Enhanced Logging" policy under Administrative Templates > System > NTLM, DC logging by "Log Enhanced Domain-wide NTLM Logs" under System > Netlogon; both default to on. It was announced in July 2025 with KB5064479 and rolled out gradually: 24H2 clients first, then Server 2025 and DCs. If most of your fleet is still Windows Server 2019 and 2022 — and in most environments it is — the FAQ says work is under way to bring enhanced auditing back to those two versions, with no date. On those machines you have the old trio today: 8001-8006, 4776/4624, and for a baseline the Security System-Wide Statistics \ NTLM Authentications counter in Performance Monitor. Non-Windows clients — macOS, Linux, mobile, third-party SMB clients — don't produce 4020; you see them through 4022 on the server and 4032 on the DC.

What interests me most is the Reason field in 4020. On the client side it says, with a structured code, why NTLM was chosen:

Code	Reason
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 be 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

The same event carries the process name and PID, the target SPN, the target IP, the NTLM version, channel-binding and MIC status. The table fills in the four boxes above on its own: code 1 is a hardcoded app, 5-8 are SPN hygiene, 9 is network topology, 2 is local accounts; 10 is the loopback/RPC world I'll get to below, 11 is null sessions, and 4 is cloud accounts. A single query grouping reason code with process name turns the vague "we have some NTLM" into an owned work list.

The first thing I'll do in my own environment is let this query run for a week; the documentation gives the fields only by display label ("Reason ID" as a number, "Reason" as text, "Process Name") and doesn't list the actual Name values in the XML, so compare names like Reason and ProcessName in the query once against the XML view of a 4020 event in your own log and adjust:

Get-WinEvent -FilterHashtable @{
  LogName   = 'Microsoft-Windows-NTLM/Operational'
  Id        = 4020, 4021
  StartTime = (Get-Date).AddDays(-7)
} | ForEach-Object {
  $x = [xml]$_.ToXml()
  $d = @{}
  foreach ($n in $x.Event.EventData.Data) { $d[$n.Name] = $n.'#text' }
  [pscustomobject]@{
    Reason  = $d['Reason']
    Process = $d['ProcessName']
    Target  = $d['TargetResource']
    Version = $d['NTLMVersion']
  }
} | Group-Object Reason, Process | Sort-Object Count -Descending |
  Select-Object Count, Name | Format-Table -AutoSize

I won't tell you what comes out, because I don't know yet; giving numbers for something I haven't measured would betray the subject of this article. But Microsoft's own telemetry offers a hint: per the AD hardening series, slightly more than half of all NTLM use is the result of application configuration. So at the end of week one, the top of the list will most likely be an application, not a network appliance.

One warning: processes running in kernel mode show up in the log as SYSTEM with PID 4. The SMB client and server and HTTP.sys live in that box — and HTTP.sys means not just IIS but WinRM, ADWS, SSRS and Remote Desktop Gateway too. If you see PID 4 at the top of the list, don't close the case with "the system uses NTLM"; you need to find the service behind it.

IAKerb and LocalKDC: what they solve, what they don't

IAKerb — Initial and Pass-through Authentication using Kerberos — is for the case where the client can't reach a domain controller directly but can reach the target service. The target server acts as a proxy, carrying Kerberos messages between the client and the KDC. Segmented networks, DMZ servers that can't see a DC, machine-to-machine SMB — everywhere you see code 9 in 4020. Microsoft's note matters: KDC Proxy was the only native option until now but it was application-dependent; IAKerb will be application-independent.

LocalKDC is a lightweight KDC embedded in Windows that issues Kerberos tickets for local accounts. Workgroups, standalone servers, small peer-to-peer setups — the world of code 2.

There's a paragraph in the FAQ I particularly liked, because it carries an honesty I'm not used to seeing in marketing copy: the NTLM that shows up in your enterprise threat model, your pen-test report and your board deck is domain-account NTLM; LocalKDC does not address it. The enterprise work is IAKerb, the SPN and DFS improvements, and the blocking policies. LocalKDC closes a narrower gap: "local account" will no longer automatically mean "NTLM". Real cleanup, but not the headline.

Preview configuration is in the registry: the DisableIAKerb and DisableLocalKDC values under HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters; 0 enables, 1 disables. In the June 2026 preview IAKerb is enabled by default and LocalKDC disabled by default. Group Policy and MDM surfaces will come as the features mature. General availability is "in the coming months" — no date. At the time of writing both were in the Canary channel; don't count on them in production, try them in a lab.

One limit, from the same source: the two features do not eliminate every NTLM dependency; some scenarios will remain on NTLM because of application behaviour and legacy assumptions. Waiting for Phase 2 as a rescue patch is no excuse for postponing Phase 1's inventory work.

What the platform can't fix for you

The bluntest sentence in the FAQ, in my view: they cannot fix missing, duplicate or malformed SPNs in your directory. If a service account has no SPN, if the same SPN is registered on two accounts, or if the client requests an SPN that doesn't match what's registered, Kerberos fails and NTLM picks up the slack. No platform change makes that go away. This is directory hygiene, and it is work that needs to start now.

For duplicate SPNs the tool is already there: setspn -X scans the whole domain and lists duplicates. Missing SPNs are harder; with Kerberos event logging LogLevel=1 on the DC they show up as 4769 failures, but that setting is noisy — turn it back off when you're done. Load-balancer VIP names and other aliases are the most common source of missing SPNs; if the account is unique per target server, Kerberos was never an option.

For authentication by IP address, Microsoft says "do not wait for a platform fix", and they're right. Kerberos doesn't understand IP addresses; every request that arrives as \\10.1.2.30\share falls to NTLM. Code 7 in 4020 tells you which process connected by IP; the largest bucket is consistently in-house applications with a literal IP in a connection string, a config file or a script. The fix is mostly a switch to a DNS name, not a rewrite. If you genuinely can't change the target, there's the path that has existed since Windows 10 1507 and Server 2016: TryIPSPN (REG_DWORD, 1) under HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters on the client, and setspn -s host/192.168.1.1 server01 on the target account. It's set per client, the IP must be static, and an SPN can be registered to only one account at a time. This is an exception mechanism, not a new default. For the genuinely irreducible cases left after that — targets you don't control, appliances that can't be changed — Microsoft has separate work in flight; in the FAQ's words, "effectively an allow list for Kerberos over IP address", scoped deliberately so it stays an exception. The smaller that list, the calmer the transition.

For hardcoded NTLM the advice is one line: search your source for the strings NTLM and NTLMSSP and replace them with Negotiate. If the code isn't yours, open a case with the vendor; what Microsoft calls Auto-Redirect will catch most of it, but vendor cooperation makes the transition faster.

Let me separate the items the platform will take on, so they don't get mixed into your list: domain-based DFS namespaces (the client's target resolution and the referral path didn't line up with a Kerberos-resolvable SPN), cross-domain authentication without a trust, and safer target resolution in general. Those arrive with the Phase 3 release. Today, external trusts default to NTLM; consider moving to forest trusts before imposing cross-domain restrictions.

The blocking tools, and where to start

The old toolset is still valid and is today's only enforcement mechanism (the FAQ says blocking is being consolidated into a centralized policy engine that considers account type, device state and target characteristics, with details "in the coming weeks"; treat today's "Deny" project as something you'll carry over to that engine): the "Network security: Restrict NTLM" family under Security Options. For auditing, "Audit Incoming NTLM Traffic", "Outgoing NTLM traffic to remote servers: Audit all" and, on DCs, "Audit NTLM authentication in this domain"; for blocking, the "Deny" options of the same policies plus their exception lists. Once blocking is enforced, the 8001-8006 audit events become 4001-4006 block events. The four "Deny" variants of the domain-wide policy block different things; save that one for the end of the project.

The new tool, shipping with Windows Server 2025 and Windows 11 24H2, is SMB client NTLM blocking: Set-SmbClientConfiguration -BlockNTLM $true, or the "Block NTLM (LM, NTLM, NTLMv2)" policy under Lanman Workstation, with "Block NTLM Server Exception List" for exceptions. When mapping drives: NET USE \\server\share /BLOCKNTLM or New-SmbMapping -BlockNTLM $true. It works on the client side only; there is no counterpart in the SMB server service. If you can't block outbound NTLM wholesale but know SMB doesn't need it, this can be the first concrete step.

For sequencing I follow the ring-based approach from the AD hardening series. Put privileged admin accounts in Protected Users — members can't use NTLM and don't even retain the hash in LSASS; don't add service accounts or devices, and add admins incrementally rather than all at once. Go in knowing one side effect: per the AD hardening series, Protected Users membership breaks that user's MS-CHAPv2 Wi-Fi/VPN sign-on, because the weak credential is no longer generated. Then Tier 0 devices: PAWs and management servers. Then new application servers before they go into production. Then a small pilot group of endpoints. Give your support team the signs of breakage too: "Network path not found" on SMB, "The RPC server is unavailable" on RPC, 0xC0000418 in Netlogon.log and in the sub-status of 4625 events, and repeated credential prompts.

One small trap: the "Enable RPC Endpoint Mapper Client Authentication" and "Restrict Unauthenticated RPC clients" policies force RPC EPM to authenticate with NTLM; CIS and STIG baselines still recommend them. If, after blocking inbound NTLM for all accounts, your loopback connections start filling up with 4002 events, this pair is the likely culprit. The explanation for the auditor is in Microsoft's own post: disabling those policies does not open RPC services to anonymous access, because each RPC service has its own security descriptor.

Decision framework

Look at your own environment in this order:

Count NTLMv1 today. BlockNtlmv1SSO flips to Enforce in October. List the 4024 events; if you have NPS profiles using MS-CHAPv2, write the EAP-TLS plan before October.
Verify enhanced auditing. Are 4020s landing in the NTLM/Operational log on your 24H2/2025 machines? If not, the gradual rollout may not have reached you yet; keep 8001-8006 on.
Collect a week of data, group by reason code. Code 1 is a vendor case, 5-8 SPN cleanup, 7 an IP-to-DNS switch, 9 an IAKerb candidate, 2 a LocalKDC candidate. Resolve PID 4 separately.
Do the directory hygiene now. setspn -X, a scan for missing SPNs, SPNs for VIP names. The platform won't do this for you.
Block in rings. Protected Users → Tier 0 → new servers → pilot endpoints. Start with SMB client blocking, leave the domain-wide "Deny" for last.
Try Phase 2 in the lab, don't wait for it in production. IAKerb and LocalKDC are in Canary; prepare test cases for your code 9 and code 2 boxes, but don't postpone the inventory on their account.

Plan this list not as a standalone "NTLM project" but as one item in an identity-hygiene programme alongside krbtgt rotation and moving to the tier model. RC4 and NTLM walked to the door in the same year; they are items on the same programme.

Not a switch, a map

When I think about why switching NTLM off has taken so long, I find the answer has nothing to do with the protocol. The switch has been there for more than fifteen years. It couldn't be pressed because nobody had ever drawn their domain's real dependency map; NTLM was the undrawn part of that map.

Event 4020 is as much a cartography tool as a security feature. That one line, with the reason code and the process name side by side, writes the document nobody has written in years: this application connects to that server, without Kerberos, for this reason. The dates in Microsoft's roadmap may slip; the next Server release doesn't even have a name yet. But once that map is drawn, pressing the switch becomes a matter of decision, not of courage.

The hardest part of turning off something that has run silently for thirty-three years isn't turning it off; it's seeing, for the first time, how much was leaning on it.

DEV Community