Latest / The Windows Podcast with Fexingo: Microsoft, PC, and Enterprise Windows Conversations / Windows 11 Is Quietly Removing Enterprise NTLM Authentication
Transcript
- Lucas: Microsoft is quietly drawing a line under NTLM authentication in Windows 11, and a lot of enterprise IT teams are going to feel this one. Luna: NTLM — the old Windows authentication protocol that's been around since the 1990s, right? It's still used in a surprising number of legacy scenarios. Lucas: Exactly. And the quiet part is that starting with Windows 11 version 24H2, Microsoft made NTLM disabled by default in certain security contexts, and future releases in 2026 are expected to tighten that further. If your organisation still relies on NTLM for file shares, print servers, or line of business apps, you've got a migration window — not an indefinite one. Luna: Yeah, and the challenge is that a lot of IT admins don't even know they're using NTLM until something breaks. It's that silent fallback. Lucas: Right — because Windows will silently downgrade authentication from Kerberos to NTLM if certain conditions aren't met. The most common one? The server doesn't have a proper Service Principal Name registered in Active Directory. So the client tries Kerberos, fails, and falls back to NTLM without popping up a warning. Luna: And that fallback gets blocked in Windows 11 now? I remember reading about some changes in 24H2 around insecure NTLM being blocked. Lucas: Yes, but it's incremental. In 24H2, Microsoft introduced a new Group Policy setting called 'Restrict NTLM: Add remote server exceptions for NTLM authentication'. They also hardened the default behaviour for outbound NTLM traffic to non-domain-joined servers. The big shift is that in future releases — likely the 2026 feature update — they plan to make NTLMv1 completely non-functional and NTLMv2 disabled by default for most outbound connections. Luna: So the days of just having NTLM as a 'works anyway' fallback are numbered. If you've got old apps that hardcode NTLM, you're looking at a rewrite. Lucas: Or at least a configuration change. But first, you need to know where NTLM is actually used. And that's where a lot of teams get stuck — they don't have visibility. Luna: Before we go deeper into that — and I know this show is ad-free — I just want to say, if you're getting something useful out of these Windows deep dives, the way they stay ad-free is through listener support. A couple of dollars a month genuinely keeps the episodes coming. Buy me a coffee dot com slash fexingo, if you've gotten something out of them. Lucas: Yeah, and it really does make a difference — no pressure, just putting it out there. So, back to discovering NTLM usage: you can enable NTLM auditing via Group Policy. There's a policy under Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options called 'Network security: Restrict NTLM: Audit NTLM authentication in this domain'. Set that to 'Enable auditing', and then check the Security event log for Event ID 8004 — that's the NTLM authentication success audit. Luna: Event ID 8004 — that's the one that tells you the client, the server, and the authentication type. NTLMv1 or v2, inbound or outbound. Lucas: Exactly. Once you've identified the devices and services using NTLM, the next step is to fix the Server Principal Names for those servers. Most of the time, missing SPNs are the root cause. You can use the 'setspn' command from a domain admin prompt to list SPNs for a computer: setspn -L computername. If you see no entries or missing ones for the service name, you add them. For example, for a file server, you'd need HOST/computername and HOST/computername.domain.com. Luna: So adding SPNs lets Kerberos work, and then NTLM becomes unnecessary. But what about those old apps that specifically request NTLM? Like some legacy in-house databases or engineering tools. Luna: And that's where you need to look at the application's authentication settings. Some apps have a config file or registry key to switch from NTLM to Negotiate. For others, you might need to work with the vendor to get a newer version. But in the worst case, you can set up a Group Policy to allow NTLM for just those specific servers using the 'Add remote server exceptions' policy I mentioned earlier. Luna: That creates a per-server exception list. So you can block NTLM everywhere else but keep it for the legacy app server until it's migrated. Lucas: Right. But you don't want to do that long-term, because Microsoft will eventually remove the exception mechanism. The 2026 changes are expected to deprecate the 'Restrict NTLM: Add remote server exceptions' policy entirely. So the clock is ticking. Luna: Let's talk about the timeline. I've seen reports that Windows 11 version 25H2 already made NTLMv1 dead by default, but NTLMv2 is still present for backward compatibility. What's the roadmap look like? Lucas: As of June 2026, the current build is 24H2 — which is still broadly deployed. The next feature update, expected in fall 2026, is rumoured to disable NTLMv2 outbound authentication by default in new Windows 11 installations. Existing upgraded systems will retain the old behaviour unless admins explicitly enable the new policy. That gives IT teams a year or two to migrate, but the window shrinks fast. Luna: So if you're a mid-size enterprise with a lot of legacy, you should start auditing now. What's the first concrete step an IT admin should take this week? Lucas: Enable NTLM auditing in Group Policy for the entire domain. Then review Event ID 8004 across your domain controllers to identify the top NTLM users. Then, pick a pilot group of servers — maybe five file servers — and for each, ensure SPNs are correct. Then try disabling NTLM via Group Policy for that pilot group only, using 'Network security: Restrict NTLM: NTLM authentication in this domain' set to 'Deny all'. Monitor the event logs for failures. Luna: That's a safe rollout approach. And if something breaks, you've only impacted five servers. You can re-enable NTLM for those specific ones via the exceptions list while you fix the underlying issue. Lucas: Exactly. One other thing people overlook: NTLM is still used for some remote desktop gateway scenarios and for authentication to older Linux file servers via SMB. If you have a mixed environment, check that your Linux Samba servers are configured to accept Kerberos tickets. That often requires updating the Samba version and setting the 'server role = member server' with proper 'realm' and 'security = ADS'. Luna: Good point. And what about child domains or cross-forest trusts? NTLM is sometimes the only option when trusts aren't fully set up for Kerberos. Lucas: That's a common pain point. For cross-forest scenarios, you need to establish forest trust relationships and register SPNs across forests. It's complex, but doable. Microsoft has a detailed guide titled 'Kerberos Cross-Forest Authentication using Windows Server'. The main takeaway: if you rely on NTLM for cross-forest, you need to move to claims-based authentication or modern protocols like OAuth for cloud-integrated apps. Luna: So this isn't just an on-premise change — it affects hybrid cloud too, especially if you have line of business apps that authenticate back to on-prem AD via NTLM over VPN. Lucas: Exactly. And that's where Azure AD Application Proxy or Microsoft Entra ID can help, because they use modern authentication protocols. So the NTLM deprecation is actually a forcing function for broader identity modernisation. Luna: It's a lot of moving parts. But if I'm an IT admin listening, the key action items are: audit NTLM usage, fix SPNs, pilot a block, and plan for application compatibility. Lucas: That's the nutshell. And don't wait until the update hits your test lab — the earlier you start, the less painful the transition. A lot of the legacy NTLM dependencies are in apps that nobody remembers who built or supports, and those are the ones that will cause outages. Luna: Outages that could have been avoided with a few months of lead time. So if you're an IT leader, put this on the roadmap now. Lucas: Absolutely. And as always, we'll keep an eye on the Windows 11 preview builds to see if Microsoft releases any new policies for NTLM blocking — we'll cover that in a future episode. Luna: Sounds good. Until next time.