How to Migrate from NTLM to Kerberos in Windows

Migrating from NTLM to Kerberos is a staged change, not a single policy switch. Start by measuring where NTLM is used, identify why Kerberos was not selected, and remediate those dependencies before enforcement.

1. Establish the migration scope

NTLM has been deprecated since June 2024 and is no longer receiving feature development. Unlike Kerberos, it does not provide mutual authentication and relies on older cryptography such as MD4 and MD5, increasing exposure to pass-the-hash and credential-relay risks. Windows 10 and 11 and Windows Server 2019, 2022, and 2025 continue to support NTLM, but a future major release is expected to block network NTLM by default.

2. Enable enhanced auditing

On clients and servers, configure NTLM Enhanced Logging under:

Computer Configuration > Administrative Templates > System > NTLM

On domain controllers, configure Log Enhanced Domain-wide NTLM Logs under the Netlogon policy path.

Client events 4020 and 4021 and server events 4022 and 4023 provide the main audit signals. Client records include the process, fallback reason, and target details; server records include the process and remote client information.

Review the operational log with:

Get-WinEvent -LogName "Microsoft-Windows-NTLM/Operational" | Format-List

Run auditing for several weeks. Group results by root cause and usage volume rather than reviewing computers in isolation.

3. Fix common Kerberos fallback causes

• Connections made with an IP address instead of a DNS name. Kerberos requires an SPN associated with a name.
• Missing, duplicate, or malformed SPNs.
• No network path to a domain controller.
• Network authentication with a local account.
• Applications that hardcode NTLM instead of using negotiation.

Use the following commands when investigating SPN problems:

setspn -Q

setspn -X

Replace IP-based references with DNS names, correct directory SPNs, and update scripts or applications that force NTLM. Inventory third-party applications and appliances that support only NTLM and engage their vendors before enforcement.

4. Roll out blocking in rings

Before enforcing restrictions, configure Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers in audit mode for a test group. Begin enforcement with non-critical workloads, then expand in rings after reviewing logs and completing functional tests.

To block NTLM for SMB on Windows Server 2025, the source documents this command:

Set-SmbClientConfiguration -BlockNTLM $true

The Block NTLM (LM, NTLM, NTLMv2) policy under Lanman Workstation provides another supported configuration path.

5. Validate legacy and exceptional cases

NTLMv1 has been removed from Windows 11 version 24H2 and Windows Server 2025. In audit mode, attempts involving NTLMv1-derived credentials are recorded as event 4024, so identify older dependencies before enforcement.

After each rollout ring, test critical applications, SMB shares, non-Windows clients, and older appliances. Remaining failures commonly involve applications that hardcode NTLM, missing Kerberos prerequisites, NTLM-only devices, or local-account network authentication. IAKerb and LocalKDC are intended to address some fallback scenarios, but auditing and SPN cleanup should begin without waiting for their general availability.

Practical takeaway

Use this sequence: audit for several weeks, group findings by cause, repair DNS and SPNs, pilot blocking with small rings, and then enforce the policy. The staged approach exposes real outage risks before broad NTLM restrictions are applied.