Before Restricting NTLM: Inventory Who Uses It and Why Kerberos Was Not Used

Direct answer: Do not start with a "deny" policy. First turn on the three "Network security: Restrict NTLM" audit policies (domain controllers, servers receiving NTLM, and clients sending it), collect several weeks of the Microsoft-Windows-NTLM/Operational log plus Security event 4624 entries whose authentication package is NTLM, and turn each caller into a row: who, from where, to which target, and why Kerberos was not used. Most rows trace to a literal IP address, a missing or duplicate service principal name (SPN), hard-coded NTLM in an application, a local account, or a client with no line of sight to a domain controller. Fix those causes, then restrict in rings with an explicit exception list and a written rollback for each ring.

Why it matters

NTLM is deprecated. Microsoft's Windows Server feature list says NTLMv1 is removed, and that LANMAN and NTLMv2 are no longer in active feature development; NTLMv2 continues to work but "will be removed from Windows Server in a future release". Microsoft's September 2026 FAQ says NTLM will be disabled by default, not removed outright, with the current target being "the next major release of Server and Client (subject to change)", and that it can be re-enabled by policy at least initially. In-market Windows Server 2019, 2022 and 2025 and Windows 10/11 continue to support NTLM.

That leaves two practical pressures on an estate today:

1. Security reviews and hardening baselines ask for NTLM to be reduced or restricted now, because NTLM has no mutual authentication and is a common relay and pass-the-hash vector.
2. Default changes already shipped for NTLMv1-derived credentials. Microsoft Support states that from Windows updates released on and after 13 October 2026, on Windows 11 24H2 and later and Windows Server 2025, the internal default for BlockNtlmv1SSO changes from Audit (0) to Enforce (1) where Credential Guard is disabled and the value is not set. That can affect Wi-Fi, Ethernet and VPN connections that use MS-CHAPv2 (including PEAP-MSCHAPv2 and EAP-MSCHAPv2) in domain-joined environments.

Restricting NTLM without an inventory is how a file share mapped by IP, a scanner, a line-of-business application or a VPN profile stops working on a Monday morning. The audit tells you which of those exist before users do.

This article is the estate-wide inventory. For one application's SPNs after a server move, see SQL Kerberos After Migration: Check SPNs and NTLM Use.

How it works

Negotiate, Kerberos and the fallback

Most Windows applications ask for Negotiate. Negotiate tries Kerberos first and uses NTLM only when Kerberos cannot complete. Kerberos needs the client to name the target in a way that maps to exactly one SPN in the directory, and it needs to reach a key distribution centre (a domain controller). When any of that fails, Negotiate silently falls back to NTLM, and the user notices nothing.

Microsoft's FAQ groups the remaining NTLM into four categories:

• Hard-coded NTLM: the application asks for NTLM or NTLMSSP explicitly. The usual code fix is to ask for Negotiate instead.
• Missing Kerberos prerequisites: a missing, duplicate or malformed SPN; a connection to a literal IP address (by default; see the TryIPSPN exception below); or no line of sight to a domain controller.
• Legacy devices or software that support only NTLM end to end; these need vendor updates.
• Local-account or special-identity flows, such as authenticating to a workgroup server with a local account.

The FAQ also notes two scenarios that today require NTLM: cross-domain authentication without a trust, and many non-Windows clients (macOS, Linux, mobile, appliances, third-party SMB clients, Outlook for Mac) connecting to Windows resources when they cannot negotiate Kerberos.

Where the evidence comes from

The legacy NTLM events are useful but thin: they show that NTLM happened and between which machines, while enhanced auditing adds the process and the reason. On an estate with Server 2019/2022, expect to combine the NTLM log with 4624 fields and per-machine follow-up.

The three audit policies

All three are under Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options, default to Not defined, and the policy pages state no restart is required:

The third policy is the same setting you later use to deny outgoing NTLM; "Audit all" is one of its values. "Not defined" for it equals "Allow all". The policy pages warn that the operational log can grow quickly, so monitor its size.

Read-only checks

None of these was run for this article. The audit policies in step 1 are a temporary diagnostic change: they add logging only, but they are a configuration change and need their own approval and rollback. Every other step reads logs or the directory.

Privileges and side effects:

• Reading the Security log needs local administrator rights (or Event Log Readers membership for that log) on each server or DC you query. Remote Get-WinEvent uses RPC to the target and is read-only.
• setspn -Q and setspn -X read the directory; any domain user can run them. setspn -X across a forest can take time on large directories.
• klist with no arguments reads the current user's ticket cache. Do not use klist purge on a production server or a user's session for this audit; it discards tickets and can cause re-authentication prompts.

Step 1: Turn on auditing (temporary change)

Before linking anything, record on one machine of each role the current effective value of each of the three policies and which policy controls it (domain GPO or local policy), with gpresult /h and the Local Security Policy console. Then create a dedicated GPO per role:

• DC GPO, linked to the Domain Controllers OU: "Audit NTLM authentication in this domain" = Enable all.
• Server GPO, linked to a pilot server OU first: "Audit Incoming NTLM traffic" = Enable auditing for all accounts.
• Client GPO, linked to a pilot workstation OU first: "Outgoing NTLM traffic to remote servers" = Audit all.

Increase the maximum size of Microsoft-Windows-NTLM/Operational in the same GPOs (Event Log settings or an Administrative Template you already use) so a busy DC does not overwrite a day of history in an hour.

Rollback: unlinking or deleting the GPOs does not guarantee a reset. Microsoft documents that a security setting no longer defined by policy takes its previous value from the machine's local security database, and if there was no previous value it stays as last applied ("tattooing"). The NTLM policy pages also say local settings apply when the GPO does not configure the policy. So, with approval, set each policy explicitly back to the value you recorded, through the policy that controlled it before (for example the same GPO set to the recorded value, or a local policy), run gpupdate or wait for refresh, check the effective values with gpresult /h and the Local Security Policy console on one machine of each role, and confirm that the users' normal sign-ins and file or application access still work.

Step 2: Count what the NTLM log is recording

On a DC or server:

# Read-only. Summarises the most recent events in the NTLM operational log.
Get-WinEvent -LogName 'Microsoft-Windows-NTLM/Operational' -MaxEvents 5000 |
    Group-Object Id | Sort-Object Count -Descending |
    Select-Object Count, Name

Then read a sample of each event ID in Event Viewer. Event IDs and field names differ between legacy and enhanced auditing; rely on the event text for each ID on your build rather than on a list copied from elsewhere.

Step 3: Find NTLM logons on a server with event 4624

# Read-only. Successful logons on this server that used NTLM, grouped by caller.
$xpath = "*[System[EventID=4624] and EventData[Data[@Name='AuthenticationPackageName']='NTLM']]"
Get-WinEvent -LogName Security -FilterXPath $xpath -MaxEvents 2000 |
    ForEach-Object {
        $x = [xml]$_.ToXml()
        $d = @{}
        $x.Event.EventData.Data | ForEach-Object { $d[$_.Name] = $_.'#text' }
        [pscustomobject]@{
            User        = "$($d.TargetDomainName)\$($d.TargetUserName)"
            Workstation = $d.WorkstationName
            SourceIP    = $d.IpAddress
            Package     = $d.LmPackageName
            LogonType   = $d.LogonType
            Process     = $d.ProcessName
        }
    } |
    Group-Object User, Workstation, SourceIP, Package |
    Sort-Object Count -Descending |
    Select-Object Count, Name -First 50

LmPackageName is populated only when the package is NTLM; a value of NTLM V1 or LM is the first thing to chase. Machine accounts (names ending $) and anonymous logons appear here too; classify them rather than ignoring them.

Step 4: Check the SPN for each target

For a target named app01.corp.example reached over HTTP or SMB:

:: Read-only directory queries.
setspn -Q HTTP/app01.corp.example
setspn -Q HOST/app01.corp.example
setspn -X

setspn -Q shows whether exactly one account holds the SPN. setspn -X reports duplicate SPNs; Microsoft's setspn documentation notes duplicates "can cause authentication issues". These queries search the current domain; add -F to search the forest, which matters when the service account lives in another domain. An empty result for one service class is not proof on its own: the setspn documentation says a HOST SPN on a computer account can substitute for built-in service classes, including http and cifs, unless those are explicitly placed on objects. Before you call an SPN missing, check the service class the client actually requests, whether a HOST SPN covers it, which account the service runs as, and the right domain or forest, and correlate with a real authentication failure for that name (step 5). When an SPN must be added, the documentation recommends setspn -S (which checks for duplicates first) over -A; adding an SPN is a change, covered under decision guidance below.

Step 5: Confirm on the client

First identify the account and logon session that makes the connection: an interactive user, a service account, a scheduled task or an application pool. With no parameters, klist lists the tickets of the currently signed-in user only, so for a service it shows the wrong session. Reproduce a fresh, representative access in that session, then run:

klist

For another session, klist sessions lists logon sessions, and klist -li <logonID> tickets reads one of them (this needs elevated rights). A ticket for the target's service (for example cifs/fileserver.corp.example or HTTP/app01.corp.example) shows Kerberos was used for that name. No ticket is inconclusive on its own: confirm with the 4624 entry for the same attempt on the server (step 3) or the NTLM log. Compare the name in the user's path, shortcut or connection string with the SPNs from step 4. An access by \\10.1.2.30\share or by a short alias that has no SPN normally will not produce a ticket, unless the TryIPSPN exception described below is configured for that IP.

Step 6: For NTLMv1, read events 4024 and 4025

On Windows 11 24H2 and later, and Windows Server 2025, filter the NTLM log for 4024 (audit: an attempt to use NTLMv1-derived credentials for single sign-on) and 4025 (blocked by policy). Both events include the target server and the name and PID of the client process; these usually point at an MS-CHAPv2-based Wi-Fi, wired 802.1X or VPN profile.

Interpreting the results

Two cautions on interpretation:

• Low volume is not low importance. A monthly payroll export or a quarterly backup verification may authenticate once a month. Several weeks is the minimum observation period; a full business cycle is better for systems with monthly or quarterly jobs.
• Absence from the log is not proof. A machine without the client GPO, a DC that overwrote its log, or a server not in the pilot OU will show nothing. State in the inventory which machines were audited and for how long.

Decision guidance

Microsoft's FAQ describes a phased approach that matches the shape below: audit, prioritise by root cause, fix the easy wins, pilot blocking in rings, and engage vendors for hard-coded NTLM.

Fix the causes first

TryIPSPN is an exception, not a default. Microsoft's FAQ describes it as setting the client registry value TryIPSPN under HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters and registering host/<ip.address> with setspn -s. It must be set on each client that needs it, and IP-based SPNs should only be used with static addresses. Follow Microsoft's "Configuring Kerberos for IP Address" procedure if you choose it.

Before registering or removing any SPN, record which account the service actually runs as on the server today. An SPN on the wrong account breaks Kerberos for every client, which then falls back to NTLM or fails outright once NTLM is restricted.

Then restrict in rings

1. Outgoing deny on a pilot ring of clients. Set "Outgoing NTLM traffic to remote servers" to Deny all on a small group, with "Add remote server exceptions for NTLM authentication" listing the documented exceptions (one per line, FQDN or NetBIOS names as the applications use them; a single * wildcard is allowed). Microsoft's FAQ suggests starting with high-value or privileged accounts and non-critical services.
2. Incoming deny on specific servers whose inventory is clean ("Incoming NTLM traffic": Deny all domain accounts or Deny all accounts).
3. Domain-level restriction on DCs ("NTLM authentication in this domain": the narrowest Deny value that matches the cleaned scope, such as Deny for domain accounts to domain servers).

At every ring, keep the matching audit policy on so you can see what is now being blocked.

Verification for each ring: blocked-request events in the NTLM log show only the callers you expected; the application owners in the ring confirm their acceptance tests; help desk tickets for authentication failures in the ring stay at baseline for an agreed period.

Rollback for each ring: before the ring starts, record the effective values of the deny and exception policies and which policy controls them. To roll back, set those policies explicitly to the recorded values through the controlling policy (unlinking alone can leave the deny setting in place, as in step 1), run gpupdate on an affected machine or wait for refresh, check the effective values with gpresult and the Local Security Policy console, and confirm that the blocked application or share now authenticates. Write down who can approve the rollback out of hours.

NTLMv1-derived credentials

If 4024 events exist on Windows 11 24H2 or later or Windows Server 2025 devices without Credential Guard, the default change from 13 October 2026 will (or already did, depending on update installation) turn those into 4025 blocks. To keep those connections working, move the affected network profiles away from MS-CHAPv2 (Microsoft recommends certificate-based methods such as PEAP-TLS or EAP-TLS), or, only as a tightly scoped, temporary exception while migrating, set BlockNtlmv1SSO (HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0, REG_DWORD) explicitly to 0 for Audit on the affected devices. Credential Guard is a separate security recommendation, not a connectivity fix: Microsoft says the new default does not apply where Credential Guard is enabled because Credential Guard already blocks single sign-on with MS-CHAP and NTLMv1, so enabling it does not restore MS-CHAPv2 single sign-on. Microsoft states no restart is required after changing it. Treat an explicit 0 as a dated exception with an owner, not a permanent setting.

What not to do

• Do not deploy "Deny all" estate-wide as the first step, or as an emergency fix after an audit finding.
• Do not purge Kerberos tickets on production servers to "test" Kerberos. Test with a representative user on a pilot machine.
• Do not add SPNs by guesswork or with setspn -A; use -S so duplicates are checked, and confirm the service account first.
• Do not treat TryIPSPN as a general fix for IP-address access; change the paths to names where you can.
• Do not leave the audit GPOs indefinitely without log size planning; the policy pages warn about log growth.
• Do not predict dates to the business beyond what Microsoft states: default disablement is a target for the next major release and "subject to change".

Limitations

• Event field names and IDs vary between legacy and enhanced NTLM auditing. This article names only the fields documented for 4624 and the NTLMv1 events 4024/4025; read the event text on your build for the others.
• Enhanced NTLM auditing, with fallback reasons and process names, is stated by Microsoft as available on Windows 11 24H2/25H2 and Windows Server 2025. Microsoft says it is working to bring it to Server 2019 and 2022; check current Microsoft documentation before relying on it there.
• IAKerb and LocalKDC were in Insider preview builds at the time of writing; Microsoft says they will become generally available for Windows Server 2025 and Windows 11 "in the coming months". Do not plan around them until they are released.
• Cross-domain authentication without a trust, and many non-Windows clients, may remain NTLM-dependent for now. Document them as exceptions with owners.
• Third-party application and device configuration (Kerberos realm, keytabs, SPN conventions) is product-specific and out of scope.
• No command here was run for this article.

Acceptance checklist

• [ ] Audit GPOs deployed per role, with log size increased and a recorded removal plan.
• [ ] Observation period covers at least several weeks and, for systems with monthly jobs, a full business cycle.
• [ ] Inventory lists caller, account, target, package (V1/V2), and classified cause for every row.
• [ ] Machines not covered by the audit are named in the inventory.
• [ ] SPN changes recorded with the service account confirmed, setspn -Q before and after, and the -D rollback.
• [ ] IP paths replaced by names where possible; TryIPSPN uses documented with per-client scope.
• [ ] Exceptions (no-trust domains, non-Windows clients, legacy devices) have owners and review dates.
• [ ] NTLMv1 (4024/4025) checked on Windows 11 24H2+ and Server 2025 devices without Credential Guard.
• [ ] Each restriction ring has its own GPO, acceptance test, verification evidence and rollback approver.

References

All accessed 2 November 2026.

• Microsoft Windows IT Pro Blog, "Retiring NTLM: Frequently asked questions" (9 September 2026): https://techcommunity.microsoft.com/blog/windows-itpro-blog/retiring-ntlm-frequently-asked-questions/4550522
• Microsoft Support, "Upcoming changes to NTLMv1 in Windows 11, version 24H2 and Windows Server 2025": https://support.microsoft.com/en-US/servicing/os/windows/docs/2025/08/upcoming-changes-to-ntlmv1-in-windows-11-version-24h2-and-windows-server-2025
• Microsoft Learn, "Features removed or no longer developed in Windows Server" (NTLM entry): https://learn.microsoft.com/en-us/windows-server/get-started/removed-deprecated-features-windows-server
• Microsoft Learn, "Network security: Restrict NTLM: Audit NTLM authentication in this domain": https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/security-policy-settings/network-security-restrict-ntlm-audit-ntlm-authentication-in-this-domain
• Microsoft Learn, "Network security: Restrict NTLM: Audit incoming NTLM traffic": https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/security-policy-settings/network-security-restrict-ntlm-audit-incoming-ntlm-traffic
• Microsoft Learn, "Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers": https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/security-policy-settings/network-security-restrict-ntlm-outgoing-ntlm-traffic-to-remote-servers
• Microsoft Learn, "Network security: Restrict NTLM: Add remote server exceptions for NTLM authentication": https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/security-policy-settings/network-security-restrict-ntlm-add-remote-server-exceptions-for-ntlm-authentication
• Microsoft Learn, "4624(S): An account was successfully logged on": https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4624
• Microsoft Learn, "4776(S, F): The computer attempted to validate the credentials for an account": https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4776
• Microsoft Learn, "Setspn": https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/cc731241(v=ws.11)
• Microsoft Learn, "klist": https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/klist

Related articles

• SQL Kerberos After Migration: Check SPNs and NTLM Use
• Group Policy Not Applying: gpresult, Events and SYSVOL

• DNS Changed but Users Still Reach the Old Application

• Before Enforcing LDAP Signing and Channel Binding: Find Every Unsigned Bind

• Account Keeps Locking Out: Find the Source From Event 4740 to the Process

Learning notes

1. Negotiate falls back to NTLM silently; the inventory exists to make each fallback visible and explain it.
2. The three Restrict NTLM audit policies cover DCs, receiving servers and sending clients; together they show both ends.
3. Event 4624's Authentication Package and Package Name (NTLM only) fields identify NTLM, and NTLMv1 or LM, per logon.
4. Most fixes are names and SPNs, not protocol settings: use DNS names, register SPNs with setspn -S, clear duplicates.
5. Restrict in rings, each with its own GPO, exception list, evidence and rollback; record genuine exceptions with owners.