Fix RPC_NT_UNKNOWN_AUTHN_SERVICE (0XC0020030) on Windows

You're trying to run a remote WMI query, PowerShell remoting, or maybe a backup job across the network, and bam — you get RPC_NT_UNKNOWN_AUTHN_SERVICE (0XC0020030). The message says 'The authentication service is unknown'. This usually happens when you're connecting from a newer Windows 10/11 or Server 2016+ box to an older server (Server 2008 R2, sometimes Server 2012) that wasn't updated. Or, it happens when Kerberos can't negotiate the right security package between two machines in different domains or with broken trusts.

What actually causes this?

The RPC runtime uses an authentication service identifier (like Kerberos or NTLM) during the initial handshake. The error means the remote machine has no clue what the requested service is. The culprit here is almost always one of two things:

• Missing update: Old Windows versions (especially Server 2008 R2 with SP1 or unsupported Server 2012 builds) lack the KB4054521 or KB4489882 security updates that added support for newer authentication service identifiers.
• Broken Kerberos config: The remote machine's SPN (Service Principal Name) is missing or malformed, which forces RPC to try NTLM or a non-existent service.
• Firewall or group policy: Rare but possible — a security policy blocked the RPC endpoint mapper from returning the correct authentication service.

Step-by-step fix

Skip the wild goose chase. Follow this order:

Step 1 — Check the remote machine's OS and patch level

Run winver or systeminfo | findstr /B /C:"OS Name" /C:"OS Version" on the target. If it's Server 2008 R2 SP1 or Server 2012 (non-R2), you're likely missing updates. Install at least these:

KB4054521 (for Server 2008 R2 SP1)
KB4489882 (for Server 2012)

Don't bother with the 'compatibility view' or registry hacks — I've seen dozens of cases where those didn't help. Just patch it.

Step 2 — Verify the SPN on the remote machine

On the target server, run this in an elevated command prompt:

setspn -L %computername%

Look for HOST/machinename.domain.com and HOST/machinename. If they're missing, add them:

setspn -A HOST/machinename.domain.com machinename
setspn -A HOST/machinename machinename

If you see duplicates (like two of same SPN), clean them up with setspn -D HOST/machinename machinename and re-add.

Step 3 — Test the RPC connection directly

Use RPCPing from the source machine (download from Microsoft if you don't have it):

rpcping -t ncacn_ip_tcp -s targetmachine.domain.com -e 1234 -a authn -i 0

If it fails with the same error, you've confirmed the issue is on the remote side. If it succeeds, the problem is somewhere else (WMI layer, DCOM permissions).

Step 4 — Check the firewall (but it's rarely the problem)

Make sure dynamic RPC ports (TCP 49152-65535 on modern Windows, TCP 1024-65535 on old builds) are open inbound on the remote machine. Also check TCP 135 (EndPoint Mapper). You can test by temporarily disabling the firewall — if the error disappears, you found it. Add back the rules properly.

Step 5 — Registry workaround (last resort)

If patching isn't possible (unsupported OS, air-gapped system), you can force the client to use NTLM instead. On the source machine, create a registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
DWORD: DisableLoopbackCheck = 1

Also add:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0
DWORD: RestrictRemoteClients = 0

Reboot after. This drops you to NTLM — less secure, but functional.

What to check if it still fails

• Time sync: Kerberos requires clock skew under 5 minutes. Run w32tm /query /status on both machines.
• DNS: The source machine must resolve the target's FQDN to the correct IP. Run nslookup targetmachine.domain.com and verify.
• Event logs: Check System and Security logs on the target for event ID 5719 (failed authentication) or KDC errors.
• Network trace: Use Wireshark on the source with filter rpc_nsp or epm. Look for the returned sec_trailer with an unknown authn service value. If you see 9 (NTLM) where Kerberos (16) was expected, the remote machine is rejecting Kerberos negotiation.

If none of this works, you're looking at a corrupted RPC stack — reinstall the remote machine's network stack or consider a clean OS rebuild. I've seen that maybe twice in 14 years, but it happens.