0xC0000413 Fix: Authentication Firewall Logon Failure

Quick answer: Clear your cached credentials via Credential Manager, then reboot. If that fails, disable the NTLM authentication firewall via Group Policy or registry.

What's happening here?

You're trying to log into a domain-joined machine — maybe Windows 10 or Windows 11 — and you see this error. The full message reads: "The machine you are logging onto is protected by an authentication firewall. The account you specified is not allowed to authenticate to the machine."

This is Microsoft's authentication firewall doing its job. It blocks logon attempts from accounts that don't have the right Kerberos or NTLM policy. Usually it pops up when:

Your cached credentials are stale or wrong.
The machine lost its trust relationship with the domain.
A group policy updated and changed the allowed authentication methods.
You're using a local account or a domain account that isn't explicitly allowed via the Network access: Restrict clients allowed to make remote calls to SAM policy.

I've seen this most often after a password reset — the user changes their domain password, but the cached credentials on the machine still hold the old one. The firewall sees the mismatch and slams the door.

Fix steps (start here)

Clear cached credentials.
Press Win + R, type control, hit Enter. Open Credential Manager, then click Windows Credentials. Look for any entries under Generic Credentials that reference your domain (like MicrosoftAccount:user@domain.com or DOMAIN\username). Remove them all. After you finish, reboot. This fixes about 60% of cases.
Reset the machine's domain trust.
If step 1 didn't work, you likely have a trust break. Log in with a local admin account (if one exists) or boot into Safe Mode with Networking. Open PowerShell as admin and run:
```
Test-ComputerSecureChannel -Repair -Credential (Get-Credential)
```
Enter your domain admin credentials when prompted. After it completes, reboot and try logging in again. You should see a normal logon prompt now.
Check the authentication firewall policy.
If steps 1 and 2 didn't do it, the policy itself is blocking you. On the domain controller, open Group Policy Management Console. Find the policy applied to the affected machine. Go to:
Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options
Look for Network access: Restrict clients allowed to make remote calls to SAM. If it's enabled, the list might not include the user or group you're trying to log in with. Add Everyone or Authenticated Users to the allowed list — but check with your security team first. That setting is a common cause.
Disable the firewall via registry (last resort).
If you can't get into the machine and need it working now, disable the authentication firewall directly. Boot into Safe Mode with Networking. Open Regedit and go to:
```
HKLM\SYSTEM\CurrentControlSet\Control\Lsa
```
Create a new DWORD value named RestrictRemoteSam and set it to 0. Reboot. This turns off the SAM restriction entirely. Do this only if you're desperate — it weakens security.

Alternative fixes if the main steps fail

Unjoin and rejoin the domain. Boot into Safe Mode, go to Settings > Accounts > Access work or school, disconnect from the domain, reboot, then rejoin. This nukes the trust relationship and rebuilds it fresh.
Check time sync. Kerberos is sensitive to clock drift. Run w32tm /resync in an admin command prompt. If the machine's time is off by more than 5 minutes, authentication fails.
Look at event logs. Open Event Viewer, go to Windows Logs > Security, and filter for Event ID 4625. The details will tell you exactly which account was blocked and by which policy. That's your clue.

Prevention tip for the future

Set up a local admin account on every domain machine — with a strong password you know. Store it in a password manager or a locked file. When the authentication firewall blocks your domain login, that local admin account is your lifeline. Test it quarterly. I've seen too many admins locked out of machines for hours because they skipped this step.

Also, if your org uses the RestrictRemoteSam policy, document it clearly and include the allowed user list in your onboarding docs. When someone changes roles or leaves, update that list. The error 0xC0000413 is almost always a policy misalignment, not a real firewall.