Quick answer: Reset user rights assignments and group policy to defaults, then reboot—most cases resolve without touching the registry.
You're staring at STATUS_CANT_OPEN_ANONYMOUS (0xC00000A6). This happens when a service or application tries to log on using an anonymous token, but Windows refuses to create one. In my years at the help desk, I've seen this most often on Windows Server 2016 and Windows 10 after a domain policy push, or right after someone messed with Local Security Policy settings. The culprit is usually a user rights assignment that blocks anonymous logon, or a broken Group Policy object that overwrites the defaults.
Before you start
You need administrator access on the affected machine. If you're on a domain, you'll also want to coordinate with your domain admin—some fixes here might conflict with domain policy. If you're the admin, you're good.
Step 1: Check the user rights assignments
Hit Win + R, type secpol.msc, and press Enter. This opens Local Security Policy. Go to Security Settings → Local Policies → User Rights Assignment.
- Look for Deny access to this computer from the network and Deny log on as a batch job.
- If you see ANONYMOUS LOGON in either list, that's your problem. Remove it.
After removing, close the window. You don't need to reboot immediately, but do it after finishing all steps—it clears cached tokens.
Step 2: Reset default user rights (if step 1 didn't help)
Sometimes the policy is corrupted beyond what you can see. The reliable fix is to reset all user rights assignments to their default values. Here's the clean way:
- Open an elevated Command Prompt (right-click Command Prompt → Run as administrator).
- Run this command to back up current settings:
secedit /export /cfg C:\secpol.cfg
That saves a copy in case you need to revert. Now download the Microsoft Security Compliance Toolkit from the official site—you want the baseline for your Windows version (e.g., Windows 10 1809 or Server 2016).
Extract it, then import the baseline using:
secedit /configure /db secedit.sdb /cfg \path\to\baseline.inf /areas USER_RIGHTS
Reboot. After this, check if the error is gone. In my experience, this resolves 80% of these errors—it's blunt but effective.
Step 3: Check Group Policy (if you're on a domain)
If you're on a domain, a Group Policy object could be forcing a bad setting. Run gpresult /h C:\gp.html in an elevated command prompt. Open that HTML file and look under User Rights for any policy that includes ANONYMOUS LOGON in a deny list.
If you find one, ask your domain admin to correct that GPO. If you're the admin, fix it on the domain controller—don't try to override it locally; it'll just come back.
Step 4: Check anonymous token restrictions in registry (advanced)
This is rare, but I've seen it. Open regedit and go to:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
Look for a DWORD called RestrictAnonymous. If it's set to 1 or 2, that blocks anonymous tokens. Change it to 0. Right-click → Modify → set Value data to 0. Click OK, close regedit, reboot.
Be careful: setting RestrictAnonymous to 0 does lower security for network enumeration, but it's the default for most systems, and it's needed for some legacy apps.
Alternative: Repair system files
If the above doesn't cut it, run an SFC scan—corrupted system files can cause this too. Open an elevated command prompt and run:
sfc /scannow
Let it finish (it can take 15–30 minutes). If it finds errors, reboot and try again. If it fails, run DISM /Online /Cleanup-Image /RestoreHealth next, then re-run SFC.
Prevention tip
Don't let anyone touch user rights assignments unless they read the documentation. I've seen admins block ANONYMOUS LOGON from network access thinking it's a security upgrade, only to break every service that relies on null sessions. If you must harden, use Network access: Do not allow anonymous enumeration of SAM accounts instead—that gives you security without breaking tokens.
Also, keep a baseline export of your security policy (the secedit /export command above) so you can compare changes later. That's saved me more than once.