Most Windows estates run Kerberos as their primary protocol and still carry a large, unowned tail of NTLM, because Windows silently falls back to NTLM whenever Kerberos cannot be used. This guide compares the two protocols as a security decision: what each one protects against, how each fails, and why the fallback path from Kerberos to NTLM keeps reappearing after teams believe they have dealt with it. It then sets out an audit-then-block retirement approach and the trade-off you take on when service accounts move to Kerberos and become Kerberoasting targets. It is for AD owners, identity architects and security engineers deciding where NTLM can be blocked. The roadmap and audit event codes are in the NTLM Deprecation and Elimination Guide, and relay controls in the NTLM Relay Guide.
Key takeaways
- Kerberos proves the server too; NTLM does not. Microsoft's Kerberos overview states that NTLM was designed for networks where servers were assumed to be genuine, which is the root of relay and forced authentication risk.
- Fallback is a design feature, not a bug. Negotiate selects Kerberos unless a system involved cannot use it or the application did not supply an SPN, UPN or NetBIOS account name, and otherwise it always selects NTLM.
- Most NTLM is caused by naming, not by old software. IP address targets, missing or duplicate SPNs, workgroup and local accounts and clients with no path to a domain controller account for the bulk of fallback.
- Retire NTLM by direction and by layer. Restrict NTLM policies and SMB client NTLM blocking let you audit and then deny outgoing, incoming and domain NTLM separately, each with an owned exception list.
- Moving to Kerberos shifts the risk, it does not remove it. Service accounts with SPNs become Kerberoasting targets, so the migration must come with managed passwords, AES only encryption and tiering.
The short answer
Use Kerberos for every domain authentication you can, and treat every remaining NTLM flow as an exception that needs an owner, a reason and an end date. NTLM is not a viable "secure alternative" in any scenario where Kerberos works: Microsoft's deprecated features list states that all versions of NTLM, including LANMAN, NTLMv1 and NTLMv2, are no longer under active feature development and are deprecated, and that calls to NTLM should be replaced by calls to Negotiate, which tries Kerberos first. A November 2024 update to the same entry records NTLMv1 as removed starting in Windows 11 version 24H2 and Windows Server 2025.
Side-by-side comparison
| Property | Kerberos (v5, RFC 4120 with MS-KILE extensions) | NTLM (NTLMv2; NTLMv1 removed in current releases) |
|---|---|---|
| Model | Trusted third party: the KDC issues a ticket-granting ticket (TGT) and then service tickets for named services | Challenge-response between client and server; the server passes the response through to a domain controller for domain accounts |
| Server authentication | Yes: the client can verify the service, because only the real service can decrypt its ticket | No: the client cannot verify the server's identity |
| What the client must know | A resolvable service name with a registered SPN | Nothing about the server beyond an address |
| Domain controller load | Low: the server usually validates the ticket itself, except for PAC validation | Higher: the server contacts a domain controller for each new domain authentication |
| Delegation | Constrained and resource-based constrained delegation for multi-hop services | No multi-hop delegation |
| Works without a domain controller | No line of sight to a KDC means no Kerberos today (IAKerb aims to change this) | Yes, and it is the only option for workgroup members and local accounts |
| Main credential theft risk | Kerberoasting, AS-REP roasting, pass-the-ticket, forged tickets | Pass-the-hash, relay, offline cracking of captured responses |
| Network requirements | DNS name resolution, time synchronisation, TCP and UDP 88 to a KDC | Only the application protocol (SMB, HTTP, LDAP and others) |
NTLM threat model
NTLM's weaknesses all stem from two properties: the server is never authenticated, and the secret that proves identity is the NT hash itself rather than something derived per session by a third party.
- Relay (T1557.001): because the client cannot tell a real server from an impostor, an attacker in the path can forward the client's NTLM exchange to a different service and act as the user there. Coercion techniques that force a machine to authenticate (T1187 Forced Authentication) turn this into a reliable path to computer account takeover. Signing and channel binding are the per-protocol answers; see the NTLM Relay Guide.
- Pass-the-hash (T1550.002): the NTLM response is computed from the NT hash, so anyone holding the hash can authenticate without knowing the password. Credential Guard reduces the exposure on the endpoint; see the Pass-the-Hash and Pass-the-Ticket Guide.
- Offline cracking: a captured challenge and response can be attacked offline. NTLMv1 responses are built on DES and are far weaker than NTLMv2, which uses HMAC-MD5 with a client challenge and timestamp, but both versions are keyed from the NT hash, so a weak password stays weak under either.
- Downgrade: where clients and domain controllers still accept older variants, an attacker who can influence negotiation can push a flow to the weakest accepted option. The LAN Manager authentication level (LmCompatibilityLevel) controls what clients send and what domain controllers accept.
NTLMv1 and NTLMv2 in practice
The LAN Manager authentication level policy (Security Options, stored as LmCompatibilityLevel under HKLM\System\CurrentControlSet\Control\Lsa) controls what clients send and what domain controllers accept. Microsoft notes changes apply without a restart and should be tested first.
| Level | Client sends | Domain controller accepts | Use today |
|---|---|---|---|
| 0 to 2 | LM and NTLM (v1), or NTLMv1 only at level 2 | LM, NTLMv1, NTLMv2 | None: treat as a finding |
| 3 | NTLMv2 only | LM, NTLMv1, NTLMv2 | Minimum for clients |
| 4 | NTLMv2 only | NTLMv1, NTLMv2 (refuses LM) | Interim step on domain controllers |
| 5 | NTLMv2 only | NTLMv2 only (refuses LM and NTLMv1) | Target for domain controllers until NTLM is blocked |
Kerberos threat model
Kerberos fixes server authentication and avoids sending a hash-derived response to whoever asks, but it concentrates trust in the KDC and in the long-term keys of accounts that hold SPNs.
- Kerberoasting (T1558.003): any authenticated user can request a service ticket for an account with an SPN, and part of that ticket is encrypted with the service account's key. A human-chosen password on that account can be cracked offline. This is the risk you take on when you move a service from NTLM to Kerberos. See the Kerberoasting and AS-REP Roasting Defence Guide.
- Pass-the-ticket (T1550.003): stolen tickets can be replayed within their lifetime. Short ticket lifetimes for privileged accounts and endpoint credential protection reduce the window.
- Forged tickets and KDC compromise: control of the KRBTGT key or a service key allows forged tickets. This is a domain compromise problem rather than a protocol choice; see the Kerberos Security Guide.
- Weak encryption types: RC4 tickets are easier to crack than AES tickets. Starting with Windows Server 2025, domain controllers do not issue RC4 ticket-granting tickets, and Microsoft recommends the policy "Network security: Configure encryption types allowed for Kerberos", set to AES only, to disable RC4. See the Kerberos RC4 Deprecation guide.
Kerberos removes whole attack classes (relay to arbitrary services, pass-the-hash) and replaces them with risks controlled through account hygiene.
Why NTLM fallback persists
Microsoft's Negotiate documentation is precise about the choice. Negotiate selects Kerberos unless it cannot be used by one of the systems involved, or the calling application did not provide enough information. To use Kerberos the client must supply a service principal name, a user principal name or a NetBIOS account name as the target; otherwise Negotiate always selects NTLM. There is no warning to the user and no error, which is why fallback survives for years.
| Trigger | Why Kerberos cannot be used | Fix route |
|---|---|---|
| Target addressed by IP address | By default Windows does not try Kerberos when the host name is an IP address | Use DNS names; only where impossible, Kerberos with IP SPNs (TryIPSPN on each client and a manually registered IP SPN) |
| Missing SPN | The KDC cannot find an account for the requested service name | Register the SPN on the account that runs the service |
| Duplicate SPN | The KDC cannot decide which account owns the name | Remove the duplicate; review SPN ownership after every service account change |
| Workgroup member or local account | Microsoft's NTLM overview states NTLM must be used for workgroup systems and is used for local logon on non-domain controllers | Domain-join, replace local accounts with managed accounts, or LocalKDC once generally available |
| No line of sight to a KDC | The client cannot reach TCP or UDP 88 on a domain controller | Open KDC paths, a KDC proxy where supported, or IAKerb once generally available |
| Application calls NTLM directly | The application chose the NTLM package rather than Negotiate | Developer or vendor change to Negotiate; replace if no fix exists |
| Non-Windows client without Kerberos configured | No keytab, wrong realm or no AES keys | Configure Kerberos with AES keytabs; see the Linux Service Accounts and Keytab Management Guide |
| Time skew or DNS failure | Kerberos requires accurate time and name resolution | Fix time sources and DNS, then re-check the pattern |
Fallback is per connection, and new fallback is created continuously by every new alias, appliance or IP-addressed script, so retirement needs a standing control (block with exceptions), not only a clean-up project. The client reason codes in the enhanced NTLM events map directly onto this table; the full code list is in the NTLM Deprecation and Elimination Guide.
The service account trade-off
Service accounts are where the protocol decision meets non-human identity governance. A service that authenticates with NTLM exposes its hash to relay and pass-the-hash wherever it logs on. The same service moved to Kerberos needs an SPN, which makes its ticket requestable by any domain user and its password a Kerberoasting target. Neither is acceptable with a human-set password that never changes.
| Service account state | Exposure under NTLM | Exposure under Kerberos | Control |
|---|---|---|---|
| Standard user account, human-set password, never rotated | Hash reusable for pass-the-hash; relay of its sessions | Kerberoastable; offline cracking likely to succeed | Convert to a group managed service account or rotate to a long random password from a vault |
| Group managed service account (gMSA) | Hash still reusable while valid | Password generated and rotated by Windows, impractical to crack offline | Restrict which hosts can retrieve the password; configure AES |
| Privileged service account (tier 0 reach) | Relay to domain controllers or AD CS is a domain compromise path | Cracked or stolen ticket gives tier 0 access | Remove tier 0 rights; deny delegation; restrict logon hosts with authentication policies |
| Service account with RC4 enabled | Not applicable | RC4 tickets are the easiest to crack | AES only encryption types; reset passwords so AES keys exist |
Microsoft's Protected Users documentation is explicit that service and computer accounts should not be added to Protected Users, because the password or certificate is always available on the host. For those accounts, NTLM can only be rejected through the NTLM block policies, a 4 hour TGT needs an authentication policy, and delegation is denied with "Account is sensitive and cannot be delegated". Microsoft's gMSA overview notes that gMSA authentication fails if AES is not configured on a host that does not support RC4. See the Group Managed Service Accounts (gMSA) Guide and How to convert AD service accounts to gMSA.
Audit then block: a retirement sequence
The Restrict NTLM policies under Security Options give three independent levers: outgoing NTLM traffic to remote servers (on clients and servers), incoming NTLM traffic (on servers) and NTLM authentication in this domain (on domain controllers). Each offers an audit setting and a deny setting, and each has an exception list. Microsoft's guidance for the outgoing policy is to select Audit all before Deny all, review the NTLM operational log under Applications and Services Logs, Microsoft, Windows, NTLM, add required servers to "Network security: Restrict NTLM: Add remote server exceptions for NTLM authentication", and only then deny. The settings take effect without a restart, which also makes rollback quick.
- Contain the weakest variants first: set LmCompatibilityLevel 5 on domain controllers and at least 3 on clients after reviewing NTLMv1 audit data. This is low risk on current Windows, where NTLMv1 has already been removed.
- Turn on visibility everywhere: enable Restrict NTLM auditing and enhanced NTLM logging, centralise the log and keep one full business cycle.
- Fix by trigger, not by host: group events by process, account, target and reason, then work the fallback table above. Naming fixes (IP to DNS name, SPN registration, duplicate removal) usually clear most volume.
- Block outgoing NTLM on clients in rings: start with privileged access workstations and IT admin devices, then a pilot ring of standard devices, then the estate. On Windows 11 24H2 and Windows Server 2025, the SMB client policy "Block NTLM (LM, NTLM, NTLMv2)" under Administrative Templates, Network, Lanman Workstation, with its "Block NTLM Server Exception List", is a narrower first step that stops SMB clients sending NTLM to rogue servers.
- Block incoming NTLM on tier 0 and high-value servers: domain controllers, AD CS servers, management servers and file servers that hold sensitive data. Pair with SMB signing and LDAP channel binding for anything still in the exception list.
- Restrict NTLM in the domain: on domain controllers, move "Restrict NTLM: NTLM authentication in this domain" from audit to deny for domain accounts and servers, with server exceptions for the remaining owned cases.
- Run the exception register as a control: every exception carries an owner, the trigger, the compensating controls, and an expiry date reviewed quarterly. New exceptions need security approval.
- Roll back by ring: if a business process breaks, move only the affected ring or server back to audit, add a time-limited exception and log the root cause, rather than lifting the block estate-wide.
Decision guidance
| Situation | Decision | Reasoning |
|---|---|---|
| Domain-joined Windows client and server, DNS name available | Kerberos only; block NTLM | Every fallback trigger here is fixable configuration |
| Third-party appliance with no Kerberos support | Time-limited NTLM exception, isolated network path, signing where the protocol supports it | Replacement or firmware is the real fix; the exception buys time, not safety |
| Workgroup or DMZ server managed with local accounts | Exception now; plan domain-join, a separate management forest or LocalKDC | Microsoft states NTLM must be used for workgroup members today |
| Legacy application hard-coded to NTLM | Vendor or developer change to Negotiate; otherwise replace | No configuration change can make a direct NTLM call use Kerberos |
| Small organisation, single domain, few applications | Go straight from a one-month audit to blocking on clients and domain controllers | Short tail, low exception volume, quick rollback |
| Large organisation, many forests and acquired estates | Block by tier and ring over several quarters; trusts and appliances last | Cross-forest referrals and unowned systems dominate the tail |
Worked scenario: a file share estate with backup and scanning jobs
A mid-sized organisation has blocked NTLMv1 and believes it is "Kerberos everywhere". Turning on outgoing NTLM auditing shows around a third of SMB sessions to file servers still using NTLMv2. Grouping the events reveals three patterns. The backup service connects to shares by IP address from a configuration written years ago. Multi-function printers scan to a share using a local account on the printer. A reporting server reaches the file cluster through a DNS alias that was never registered as an SPN.
Registering the alias SPN and switching the backup job to DNS names removes most of the volume in one change window. The backup account was a standard user with a password unchanged for six years and an SPN added during the fix, which would make it Kerberoastable, so it is converted to a gMSA with AES and restricted to the backup hosts. The printers cannot do Kerberos, so they receive a 12 month exception: scan targets moved to a dedicated share on a separate server, SMB signing required, and an owner in facilities. Outgoing NTLM is then denied on admin workstations, then on a pilot ring, and finally estate-wide, with the printer server in the exception list. Incoming NTLM is denied on the main file cluster.
Detection and measurement
- NTLM operational log: audit and block events from the Restrict NTLM policies and the enhanced events give process, account, target and reason.
- Security log on domain controllers: event 4776 (credential validation, NTLM) and 4624 with an authentication package of NTLM show where NTLM still succeeds; event 4769 shows service ticket requests, where requests for RC4 tickets against service accounts are a Kerberoasting signal. See the Active Directory Security Monitoring and Event IDs Guide.
- Account hygiene: SPN-bearing accounts that are not gMSAs, RC4-enabled service accounts and duplicate SPNs. See How to find and retire Active Directory service accounts with SPNs.
Metrics that show the programme is working:
- Share of domain authentications using NTLM, trended monthly, with NTLMv1 at zero.
- Number of distinct NTLM patterns (process, target, reason) and the share with a named owner.
- Percentage of devices and servers in a deny ring for outgoing and incoming NTLM.
- Open NTLM exceptions, and the number past their expiry date.
- Percentage of SPN-bearing service accounts that are gMSAs or have vault-rotated passwords and AES only encryption.
- Privileged and computer accounts generating NTLM: target zero.
Common failure patterns
- Treating LmCompatibilityLevel 5 as "NTLM disabled": it removes NTLMv1 at the domain controller and leaves NTLMv2 relay and pass-the-hash fully available.
- Blocking before one full business cycle of audit: quarter-end jobs and annual processes appear late and break, which leads to estate-wide rollback.
- Fixing NTLM by adding SPNs to weak accounts: the migration succeeds and creates a fresh set of Kerberoastable accounts with old passwords.
- Exceptions with no owner or expiry: the exception list becomes the new permanent NTLM estate. Unowned service accounts are a governance finding in their own right; see How to assign owners to orphaned service accounts.
- Re-introducing IP addresses: new IP-addressed scripts and mappings recreate fallback; blocking outgoing NTLM makes regressions fail visibly.
Framework mapping
| Framework | Reference | How this guide applies |
|---|---|---|
| MITRE ATT&CK | T1557.001 Name Resolution Poisoning and SMB Relay; T1187 Forced Authentication; T1550.002 Pass the Hash | NTLM risks removed by blocking NTLM and by signing for remaining exceptions |
| MITRE ATT&CK | T1558.003 Kerberoasting; T1550.003 Pass the Ticket | Kerberos risks controlled by managed passwords, AES and ticket lifetime limits |
| NIST SP 800-53 Rev 5 | IA-2 Identification and Authentication (Organizational Users); IA-5 Authenticator Management | Protocol choice and service account password management |
| NIST SP 800-53 Rev 5 | AC-2 Account Management; AC-6(5) Privileged Accounts | Owned exceptions, service account ownership, removing tier 0 rights from service accounts |
| NIST CSF 2.0 | PR.AA-01; PR.AA-03 | Identities and credentials for users and services are managed; users, services and hardware are authenticated |
Practitioner checklist
- Set LmCompatibilityLevel 5 on domain controllers and at least 3 on every client.
- Enable Restrict NTLM auditing and enhanced NTLM logging estate-wide and centralise the NTLM operational log.
- Group NTLM events by process, account, target and reason, and give every pattern an owner.
- Replace IP address targets with DNS names; use TryIPSPN and IP SPNs only as owned exceptions.
- Register missing SPNs and remove duplicates; review SPNs whenever a service account changes.
- Convert SPN-bearing service accounts to gMSAs or vault-rotated passwords, with AES only encryption, before or during the move to Kerberos.
- Deny outgoing NTLM in rings starting with admin workstations; deny incoming NTLM on tier 0 and high-value servers.
- Keep an exception register with owner, trigger, compensating controls and expiry, reviewed quarterly.
- Report NTLM share, owned patterns, deny ring coverage and expired exceptions monthly.
Standards and references
- IETF: RFC 4120 The Kerberos Network Authentication Service (V5)
- Microsoft: [MS-NLMP] NT LAN Manager (NTLM) Authentication Protocol
- Microsoft Learn: Deprecated features in the Windows client
- Microsoft Learn: Microsoft Negotiate
- Microsoft Learn: Kerberos authentication with IP addresses
- Microsoft Learn: Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers
- Microsoft Learn: Block NTLM connections on SMB
- Microsoft Learn: Protected Users security group and protected accounts
Related NHI Mgmt Group resources: NTLM Deprecation and Elimination Guide · NTLM Relay Guide · Kerberos Security Guide · Group Managed Service Accounts (gMSA) Guide · SMB Signing Guide