Windows without NTLM:
IAKerb, LocalKDC and what to do now

In short: Microsoft has announced that it will disable NTLM — the old Windows authentication protocol — by default in future versions of the system. Two new features, IAKerb and LocalKDC, bring Kerberos to the scenarios that used to fall back to NTLM. This is not a change to put off: today is the time to discover where your company still uses NTLM and to put the basics in order (DNS, SPNs, clocks).

How NTLM works, explained simply

NTLM serves to prove that you know your password without ever sending it. It works like a surprise test, with three actors: your machine (the client), the server you want to reach and the domain controller (DC), which holds the passwords in Active Directory.

• 1The client knocks on the server: “I’m Mario, let me in”.
• 2The server issues a challenge: a random number, different every time.
• 3The client mixes that number with the fingerprint of the password (the hash) and sends the result back. The password never leaves: it stays on the client.
• 4The server cannot verify on its own (it does not have the hash): it forwards the request to the DC, which holds the fingerprint in AD. The DC redoes the calculation and, if it matches, confirms. For a local account, instead, it is the machine itself that checks against its own database (SAM), with no DC involved.

In short: the client talks only to the server, and it is the server that talks to the DC. NTLM exists in two versions: today you use NTLMv2 (NTLMv1 should be disabled because it is far weaker), but the three-actor mechanism — and the problems we will see — applies to both.

Why NTLM is a problem

It looks solid — the password never travels in clear text — but it has two cracks that weigh heavily today:

• Nobody verifies the server. You prove who you are, but the server does not have to prove anything to you. If someone slips in pretending to be the server, the whole thing falls apart. It is the opposite of zero trust logic.
• The fingerprint is enough — you do not need the real password. The hash lingers in the memory of the machines and servers the user connects to, and — for every user — on the domain controller. Whoever compromises a machine with elevated privileges can steal the hash and reuse it to authenticate as the victim (pass-the-hash), without knowing the password. In a different variant the attacker steals nothing: they intercept and forward the authentication of a victim towards a third-party server (NTLM relay). In both cases a single compromised machine becomes the entry point to the entire network: the typical dynamic of ransomware attacks.

Kerberos: the ticket model

Kerberos changes the approach. Instead of redoing the test at every door, you go just once to a “trust desk” (the KDC, on the domain controller), prove who you are and receive a signed, time-limited ticket. At each service you show the ticket — like a wristband issued at a central counter, instead of showing your documents at every gate. The benefits:

• Mutual authentication — not only do you prove who you are: the server also proves to you that it is genuine. The door shows a seal that only the real venue can produce.
• Single sign-on and efficiency — you authenticate once and reuse the tickets; the services verify them on their own, without phoning the DC at every access as NTLM does.

The same “verify, don’t trust” principle is also at the heart of other recent evolutions of Windows authentication, such as the end of RC4 encryption in Kerberos.

Why NTLM still survives

If Kerberos is better, why is NTLM still everywhere? Because in some scenarios Kerberos, by design, cannot work and Windows automatically falls back to NTLM:

• Local accounts and non-domain machines — without a domain there is no KDC to issue the tickets.
• No line of sight to the domain controller — if the client cannot reach a KDC, Kerberos cannot issue the ticket.
• Access by IP address — Kerberos thinks in terms of name (the SPN, e.g. cifs/server.azienda.local). Whoever connects by IP has no matching SPN and falls back to NTLM.
• Heterogeneous environments — machines in one domain accessing resources in another domain, NAS not joined to Active Directory, macOS workstations outside the domain. This is the real world for a great many SMEs, and that is exactly where NTLM holds on.

What changes: IAKerb and LocalKDC

The two Microsoft features (in preview on Windows 11 and Windows Server 2025) tackle precisely the gaps where NTLM used to be needed:

• 1IAKerb — when the client cannot reach the KDC, the server acts as the courier: it forwards the Kerberos messages to the domain controller and brings back the ticket. It never sees passwords or hashes, it only passes the messages along. The result: no more fallback to NTLM “because I can’t see the DC”.
• 2LocalKDC — a miniature “trust desk” installed on the machine itself, which issues Kerberos tickets for local accounts. This way non-domain systems can use Kerberos in place of NTLM.

Applied to real cases, however, they need to be read honestly:

• A domain machine that cannot see the DC (segmented network or remote site): IAKerb solves it, the server forwards to the KDC.
• Accessing a resource in another domain with that domain’s credentials: if the remote KDC is reachable and resolvable, Kerberos already works today without a trust; if it is not, today it is NTLM and tomorrow it can be done via IAKerb (the server acts as a proxy).
• Non-Windows NAS and macOS workstations: LocalKDC is a Windows feature and IAKerb is on the Windows side — support for third-party clients and devices is not guaranteed and must be checked with the vendor. These often remain the last bastion of NTLM.

What to do today: audit, hygiene and mitigations

1. Find out where you still use NTLM. Before touching anything, run an audit: enable the NTLM operational log and analyse the security events — in particular event 4624 with an NTLM authentication package and event 4776 on the domain controllers — to understand which applications, servers and devices still depend on NTLM. You do not disable it blindly.

2. Get the Kerberos foundations right. In many cases the problem is not “a Microsoft feature is missing” but basic hygiene: resolvable DNS names (including towards different domains, with conditional forwarders), correctly registered SPNs, access to resources by name and not by IP, and synchronised clocks within a few minutes. Once these foundations are sorted, many accesses that today fall back to NTLM return to Kerberos on their own.

3. Reduce the risk while NTLM is still around. You cannot switch it off overnight, but you can mitigate it: enable SMB signing and signing with channel binding (EPA, Extended Protection for Authentication) on LDAP and web services to neutralise most NTLM relay attacks; use the NTLM restriction policies (first in audit, then in selective block mode) to tighten progressively; and have applications invoke the Negotiate package instead of direct NTLM, so that Kerberos is chosen when possible.

NTLM, segmentation and zero trust

The end of NTLM is not just “patch management”: it is a piece of zero trust, the “never trust, always verify” model. Here IAKerb shows its best side: instead of flattening two environments (opening DNS and ports towards the domain controllers of another network), the server acts as a proxy and you do not expose the identity core to external clients. Less implicit connectivity, and — moving from NTLM to Kerberos — mutual verification in place of blind trust.

Be careful not to confuse the layers: IAKerb and LocalKDC are on-premise mechanisms and have nothing to do with Microsoft Entra ID, which is the cloud identity (there is an “Entra Kerberos”, but it serves specific cases such as Azure Files, not an on-premise share or a NAS). For truly heterogeneous environments the answer is not a single feature, but an architectural choice: targeted trusts, segmentation and, where needed, Zero Trust Network Access (ZTNA) that governs access by identity and device, including for non-Windows clients.

How AtWorkStudio helps

We support companies on the path towards modern authentication: auditing NTLM dependencies, cleaning up DNS, SPNs and synchronisation, reducing local accounts, digital identity management and network segmentation. For heterogeneous environments we design access with a zero trust mindset, consistent with the requirements of NIS2 and with ISO/IEC 27001 best practices.

We have been operating from Piacenza since 2000. We hold ISO/IEC 27001, 27017, 27018 and ISO 9001 certifications, with ACN qualification for cloud services, and we are members of Clusit (Italian Association for Information Security) and affiliated with Confindustria Piacenza in the RICT cluster.