Kerberos is not a setting you switch on. It is a system that quietly works when three boring foundations are right - and silently falls back to NTLM the moment any one of them is wrong. Get these right and half your NTLM traffic disappears by itself.
Microsoft has said its end goal plainly: eliminating the need to use NTLM at all. The replacement is Kerberos - the ticket-based protocol your domain already uses whenever it can. The catch is that Kerberos is strict. NTLM tolerates IP addresses, sloppy names and drifting clocks; Kerberos tolerates none of them, and every failure drops the connection back to NTLM without telling you. That is why so many networks 'still need NTLM': their Kerberos foundations have small cracks. This page is the checklist of what must work before NTLM can honestly go.
The five foundations Kerberos needs. Miss one and Windows quietly uses NTLM instead.
A Kerberos ticket is requested for a name - the service principal name built from the host name you typed. That is the whole reason connections by IP address fall back to NTLM: there is no name to issue a ticket for. So the first foundation is unglamorous: every server must be reachable by a name that DNS resolves correctly, in both directions, for every client.
ping SERVER01 and confirm the reply address is the right machineKerberos tickets carry timestamps, and the default tolerance is five minutes. A PC whose clock has drifted beyond that gets its tickets rejected, and Windows falls back to NTLM - so the machine appears in your NTLM audit log for a reason that has nothing to do with NTLM.
w32tm /query /statusWhen a client asks for a ticket, it asks for a service - file sharing on a server, HTTP on an intranet site, SQL on a database box. That service must be registered as a service principal name (SPN) on the right account, or the ticket request fails and NTLM takes over.
setspn and check for duplicates, which break Kerberos just as surely as missing onesClassic Kerberos needs line of sight to a domain controller to fetch tickets. Laptops off the network, and local accounts, are two of the most common reasons NTLM still gets used at all - and Microsoft knows it. Phase 2 of its published plan (announced for the second half of 2026) adds IAKerb and a local Key Distribution Center precisely to remove those two reasons. Until that ships and you deploy it, some off-network and local-account traffic will keep using NTLM - plan for that honestly instead of pretending the audit log should be empty.
The full process with live demonstration - every setting shown on screen, step by step.
Watch Full VideoBecause a Kerberos ticket is issued for a service principal name, which is built from a host name. An IP address gives the client no name to request a ticket for, so Windows falls back to NTLM by design.
Five minutes by default. Beyond that, tickets are rejected as expired or not yet valid, and Windows falls back to NTLM - which is why a drifting clock shows up as an NTLM problem.
On a healthy domain, no - it is already the first choice for domain accounts. What you configure are the foundations it depends on: DNS, time sync, and SPNs for special services and aliases.