Hello David, thank you for posting in the Microsoft Q&A community.
Microsoft has officially declared NTLM (including NTLMv1 and NTLMv2) as deprecated starting in Windows 11 (version 24H2) and Windows Server 2025. While NTLM remains available for backward compatibility during a transition period, future Windows releases will allow administrators to disable NTLM entirely across domain and local scopes.
To eliminate hard dependencies on NTLM, Microsoft introduced two key architectural enhancements to the Windows authentication stack:
- IAKerb (Initial Authentication Protocol for Kerberos): Solves the scenario where a client computer does not have direct network connectivity (port 88) to an Active Directory Domain Controller (e.g., remote clients behind firewalls or proxies). IAKerb allows the destination server to act as a proxy, passing Kerberos authentication messages between the client and the DC wrapped inside the Negotiate/SPNEGO protocol.
- Local KDC: Introduces a local Kerberos Key Distribution Center built into Windows, enabling local user accounts to authenticate using Kerberos rather than falling back to NTLM for local authentication.
Step-by-Step NTLM Audit & Migration Plan
Phase 1: Enable NTLM Auditing Across Active Directory
Before enforcing NTLM block policies, you must audit all incoming, outgoing, and domain-wide NTLM authentication traffic to identify legacy applications, hardcoded IP-based connections, and un-registered Service Principal Names (SPNs).
- Open Group Policy Management (
gpmc.msc) and edit a GPO applied to Domain Controllers, Member Servers, and Clients. - Navigate to:
Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options - Configure the following policies:
- Network security: Restrict NTLM: Audit NTLM authentication in this domain -> Set to Enable all.
- Network security: Restrict NTLM: Audit Incoming NTLM Traffic -> Set to Enable auditing for all accounts.
- Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers -> Set to Audit all.
Phase 2: Analyze Audit Event Logs
Once auditing is enabled, monitor NTLM event logs to isolate NTLM callers across your infrastructure:
- Domain Controller Event Log Path:
Event Viewer -> Applications and Services Logs -> Microsoft -> Windows -> NTLM -> Operational- Event ID 8001: Audits successful domain NTLM authentications.
- Event ID 8002 / 8003 / 8004: Audits NTLM traffic blocked or allowed by restriction rules.
- Security Log on Servers and Clients:
Windows Logs -> Security -> Event ID 4624 (Filter for Logon Type 3 with Authentication Package: NTLM).
PowerShell command to query NTLM Operational Events on Domain Controllers:
# Query NTLM Operational audit events on a Domain Controller
Get-WinEvent -LogName "Microsoft-Windows-NTLM/Operational" -MaxEvents 100 |
Select-Object TimeCreated, Id, Message |
Format-List
Phase 3: Remediation & Service Migration to Kerberos
- Replace IP Addresses with FQDNs: Kerberos requires Service Principal Names (SPNs), which fail when connections use raw IP addresses (e.g.,
\\192.168.1.50\share). Update applications and scripts to use Fully Qualified Domain Names (e.g.,\\server01.corp.contoso.com\share). - Register Missing SPNs: Ensure custom service accounts have correct SPNs registered:
setspn -S HTTP/webApp.corp.contoso.com contoso\serviceAccount - Use Negotiate SSPI Package: Update custom applications to use the
NegotiateSecurity Support Provider (SPNEGO) instead of hardcodingNTLM. Negotiate automatically attempts Kerberos (and IAKerb) before considering NTLM.
Phase 4: Stage NTLM Restriction & Blocking
Once audit logs show zero unexpected NTLM traffic, enforce NTLM restrictions incrementally using Group Policy:
- Configure Network security: Restrict NTLM: Restrict NTLM in this domain to Audit all.
- Add necessary legacy servers to Network security: Restrict NTLM: Add server exceptions in this domain.
- Gradually shift the policy to Deny for domain accounts to domain servers and finally Deny all.
Official Microsoft References: