NTLM Blocked — STATUS_NTLM_BLOCKED After Restrict NTLM Policies

What the Error Looks Like

A change went in overnight — someone finished the NTLM hardening project and flipped one of the Network security: Restrict NTLM settings from Audit to Deny. By morning, an application that has authenticated the same way for years can’t log on, and there were no password resets, no lockouts, and no network changes to point at.

In the Security log on the affected computer, the failed logon shows up as Event 4625 with a Sub Status of 0xC0000418:

Log Name:      Security
Event ID:      4625
Task Category: Logon
Keywords:      Audit Failure

An account failed to log on.

Status:          0xC000006D
Sub Status:      0xC0000418

What It Actually Means

NTLM and NTLMv2 are vulnerable to relay and brute-force attacks, so Microsoft’s Restrict NTLM policies let you reduce NTLM’s footprint in a domain in stages: first audit what would be blocked without actually blocking it, then flip the matching setting to deny once you know the impact.

Think of the Audit setting as a burglar alarm running in silent-test mode: it logs every door someone opens without ever locking anyone out. Flip the matching policy to Deny and every door without a registered exception locks itself the same instant, including the ones people still walk through every day.

There are five separate Restrict NTLM policy settings, and each has its own audit companion. Mixing them up — or enforcing one before its audit companion has been reviewed — is the single most common cause of this failure:

All five live under Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options in Group Policy. None of them require a restart — a gpupdate /force and a policy refresh interval is enough for a Deny setting to start refusing logons immediately.

How to Diagnose

Work from cheapest check to deepest. The goal is to find which of the three roles — client, member server, or domain controller — logged the block, because that tells you which Restrict NTLM setting is responsible.

# 1. Confirm this is really an NTLM block and not a bad password/lockout
#    Look for Sub Status 0xC0000418 on Event 4625 in the Security log
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625} -MaxEvents 20 |
  Where-Object { $_.Message -match '0xC0000418' }

# 2. Confirm which Restrict NTLM setting is actually in effect on this computer
#    (Group Policy can win a different value than what you think you set)
gpresult /r /scope computer

# 3. Check the NTLM operational log for the matching audit/block event
#    Event 8004 = domain controller, 8003 = member server, 8001 = client
Get-WinEvent -LogName 'Microsoft-Windows-NTLM/Operational' -MaxEvents 50

# 4. If the client is a domain-joined workstation, confirm what package
#    was actually used for a recent successful logon from the same account
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624} -MaxEvents 20 |
  Select-Object -ExpandProperty Message |
  Select-String 'Authentication Package'

NTLM Operational Log Quick Reference

Audit and block events for every Restrict NTLM setting are written to Applications and Services Logs\Microsoft\Windows\NTLM\Operational — never to the Security log’s own audit policies. There is no Security Audit Policy that surfaces this data; you have to look at the NTLM operational log directly.

Common Causes

The Fix

The fastest way to stop active failures is to remember that the audit companion setting for whichever policy is blocking traffic does not block anything — it only logs. Switching back to it immediately restores access while you finish the investigation.

Once the immediate impact is contained, work the log evidence end to end. Set the matching Audit variant on the affected scope — domain controller, member server, or client — and run gpupdate /force so it takes effect right away. Let normal traffic flow for a representative period, then collect Event 8004 on the domain controller, 8003 on the member server named in its Secure Channel name field, and 8001 on the client named in that server’s event.

Build the exception list from what the log actually shows rather than guesswork: Add server exceptions in this domain for the domain-scoped policy, Add remote server exceptions for NTLM authentication for the client-scoped one. Only once that list is in place should the Deny setting go back on — and the follow-up check is the same Event 4625 query from earlier, confirming no further 0xC0000418 Sub Status entries appear for the systems now on the exception list.

How to Prevent It

Every Restrict NTLM policy setting has an audit-only companion for exactly this reason. Treat “Audit first, Deny later” as non-negotiable, and give the audit phase enough time to catch infrequent processes — a monthly batch job or quarterly report that only runs a few times a year needs weeks of audit logging, not days, before you can trust the exception list is complete.

This failure sits next to two other authentication problems worth knowing well: a duplicate or missing SPN can silently push an account onto NTLM in the first place, which the Kerberos Authentication Fails — Duplicate SPN post covers, and Kerberos’s own pre-authentication failures are covered in Event 4771 — Kerberos Pre-Authentication Failed. If you haven’t read how Kerberos is meant to work in the first place, the Active Directory — Part 5 — Authentication & Kerberos post is the right starting point before you plan an NTLM reduction project.

Final Thoughts

NTLM restriction is one of the more painless security wins available in an AD environment, right up until it’s rolled out without the audit phase it was designed around. The good news is that the same NTLM operational log that would have warned you in advance is still the fastest way to fix it after the fact — it just means reading the client, server, and domain controller logs together rather than any one of them alone.