Fixing RPC_NT_UNKNOWN_AUTHN_LEVEL (0XC0020031) in Windows Server
This happens when Windows can't negotiate an RPC authentication level with a remote machine. Usually a firewall or security policy blocks it.
What triggers this error
You're trying to run a remote WMI query, manage a server via Server Manager, or use a tool like winrm, and you get hit with 0XC0020031 - The authentication level is unknown. Last month I had a client whose backup software couldn't connect to their domain controller because of this. The error pops up when Windows can't settle on an authentication level for the RPC call — usually between a client machine and a server, or between two servers in different security zones.
Root cause in plain English
RPC authentication levels range from 0 (none) to 6 (packet privacy with encryption). Windows negotiates this automatically, but if something blocks the negotiation — like a firewall that drops certain RPC packets, or a Group Policy that forces a higher level than the remote machine supports — you get this error. The most common cause I've seen is a firewall rule that allows RPC endpoint mapper (port 135) but blocks the dynamic ports RPC uses afterwards. Another one: the remote machine's DCOM settings are locked down too tight.
The fix: step by step
Step 1: Check the firewall on both ends
Open an elevated command prompt on the machine that's failing. Run:
netsh advfirewall firewall show rule name=all | find /i "Remote"Look for rules that block RPC. If you're on a domain, check wf.msc for any custom rules. The key is to allow RPC Endpoint Mapper (TCP 135) and Dynamic RPC ports (TCP 49152-65535 by default on modern Windows). I've seen admins block the dynamic range thinking it's safer — it's not, it breaks everything.
Step 2: Verify DCOM authentication level
On the remote machine, open dcomcnfg. Go to Component Services → Computers → right-click My Computer → Properties → COM Security tab. Under Access Permissions, click Edit Default. Make sure the Everyone or Authenticated Users group has Remote Access allowed. Most people forget this and wonder why remote calls fail.
Step 3: Change authentication level in registry
This step forces a consistent level. On the machine making the call, open regedit and go to:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\OleFind (or create) a DWORD value named DefaultAuthenticationLevel. Set it to 5 (Packet Integrity). This tells Windows to negotiate but not drop below packet integrity. Had a client whose antivirus was overriding this — check that too.
Step 4: Test with a direct RPC call
To confirm the fix, use PowerShell on the client:
Test-WSMan -ComputerName SERVER01 -Authentication DefaultIf you still get the error, the issue is likely on the server side. Repeat steps 1-3 there.
What to check if it still fails
If steps 1-4 don't work, look at Group Policy. Run rsop.msc on both machines and check Computer Configuration → Administrative Templates → System → Remote Procedure Call. Any setting like "RPC Endpoint Mapper Client Authentication" set to Enabled can cause this. Also check if the remote machine is Windows Server Core — it needs the RPC over HTTP Proxy role if you're using that. Finally, wireshark a quick capture on port 135. If you see a reset after the initial bind, the firewall is still the culprit.
Was this solution helpful?