Fix 0XC0000418: NTLM Blocked Authentication Error

1. Group Policy: NTLM Restrictions Are the #1 Culprit

Nine times out of ten, this error shows up because someone—often a well-meaning security admin—tightened NTLM restrictions in Group Policy. The setting lives under Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options.

Look for these two policies:

• Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers
• Network security: Restrict NTLM: NTLM authentication in this domain

If either is set to Deny all, you'll hit 0XC0000418 immediately when any legacy app tries to use NTLM. The quick fix is to change them to Audit all or Deny for domain servers to servers (less aggressive). Then run gpupdate /force.

Real-world scenario: I saw this on a 2019 file server after a security baseline deployment. SharePoint mapped drives started failing with 0XC0000418. Took me 10 minutes to find the policy and switch it to Audit. Logs cleaned up in hours.

If you can't change the policy (because InfoSec says no), you'll need to whitelist the specific server or app. Add the target server's hostname or IP to the Network security: Restrict NTLM: Add remote server exceptions for NTLM authentication policy. That's the surgical fix.

2. Windows Updates That Broke NTLM (KB5004244 and Friends)

Microsoft pushed several updates starting around August 2021 that hardened NTLM by default. The big one was KB5004244 for Windows Server 2019, but later updates for 2016 and 2022 did the same thing.

These updates change the default behavior of the LmCompatibilityLevel registry key. The old default (level 3) allowed NTLMv2 with fallback. The new default (level 5) refuses NTLM if Kerberos is available. Problem is, many apps don't support Kerberos—like older SQL Server instances, IIS with basic auth, or non-Microsoft services.

You've got two options:

1. Uninstall the update—last resort, but it works. Only do this if you can't fix it any other way. Use wusa /uninstall /kb:5004244.
2. Force NTLM fallback via registry—better approach. Set HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\LmCompatibilityLevel to 3 (or 2 for NTLMv1, but don't do that unless you're really stuck). Reboot the server.

Don't bother checking event logs for this one—the error message itself tells you it's blocked. Instead, run nltest /server:<target> /sc_query to see if Kerberos is actually working between the two machines. If it's not, NTLM was your only option, and the update killed it.

reg add "HKLM\SYSTEM\CurrentControlSet\Control\Lsa" /v LmCompatibilityLevel /t REG_DWORD /d 3 /f

Then reboot. That's it.

3. App-Specific NTLM Blocking by Security Software

Sometimes it's not Windows itself—it's the AV, EDR, or firewall that's blocking NTLM authentication. I've seen this with McAfee Endpoint Security, Trend Micro Apex One, and Windows Defender Firewall with advanced rules.

The trigger is usually a process that tries to authenticate via NTLM to a server that's been flagged as suspicious. The security software intercepts the call and returns 0XC0000418 before Windows even gets a chance.

How to confirm: Check the security software's own logs, not just Windows Event Viewer. On the client machine, look at Applications and Services Logs > Microsoft > Windows > NTLM > Operational—if the error has a Caller Process ID that matches your AV, you've found the culprit.

Fix: Add an exception for that process or the target server in the security software. For Windows Defender Firewall, check for outbound rules blocking ports 139 and 445 (SMB) or 3389 (RDP). NTLM can't do its thing if those ports are closed.

Quick check: From the affected client, run Test-NetConnection <target-server> -Port 445 in PowerShell. If it fails, the firewall is the problem, not NTLM directly. But the error code will still be 0XC0000418 because the handshake dies early.

Quick-Reference Summary Table

Start with Group Policy. That's the money shot. If it's not that, check the registry. Security software is the dark horse—don't forget it.