RPC_S_UNSUPPORTED_AUTHN_LEVEL (0x0000071d) fix

1. COM/DCOM authentication level mismatch

This is the one I see most. The error pops up when two machines running Distributed COM (DCOM) can't agree on authentication. You'll get RPC_S_UNSUPPORTED_AUTHN_LEVEL (0x0000071d) when a client app (like a PowerShell script using New-Object -ComObject) tries to call a COM object on a remote server, and the server expects a higher authentication level than the client sent.

The default in Windows is Connect (level 2). But some apps — especially legacy ones or custom COM components — demand Packet Privacy (level 6) or Packet Integrity (level 5). When they don't match, you get this error.

The fix: Set the DCOM authentication level on the server to match what the client expects. I've seen this work on Windows Server 2019 and Windows 10 22H2.

Open Component Services (run dcomcnfg).
Go to Component Services > Computers > Right-click My Computer > Properties.
Click the Default Properties tab.
Under Default Authentication Level, pick Connect (if clients use Connect) or Packet (if they use Packet).
Click OK and reboot.

If you're still stuck, check the specific COM component's settings. Right-click it in Component Services, go to Properties > Security, and override the default authentication level there.

Side note: I've seen this trip up PowerShell remoting when using Invoke-Command -Session $session { Get-WmiObject ... } with older Windows Management Framework versions. Upgrade to WMF 5.1 if possible.

2. Kerberos delegation misconfiguration

This one's sneaky. The error appears when a service account tries to delegate credentials to a backend service, but Kerberos doesn't support the required authentication level across the delegation chain. You'll see it in multi-hop scenarios — like a web app on IIS that needs to authenticate to SQL Server using the caller's identity.

The real trigger: You set up constrained delegation but forgot to check the Use any authentication protocol option. Or you used protocol transition without proper service principal names (SPNs).

The fix: Update the delegation settings for the service account in Active Directory.

Open Active Directory Users and Computers.
Find the service account (e.g., svc_webfarm).
Right-click > Properties > Delegation tab.
Select Trust this user for delegation to specified services only.
Check Use Kerberos only or Use any authentication protocol — pick the latter if you're using protocol transition.
Add the SPN for the backend service (e.g., MSSQLSvc/sqlserver.contoso.com:1433).
Click OK. Then run klist purge on the client, test again.

I've also had to set the msDS-AllowedToDelegateTo attribute manually using PowerShell when the GUI didn't stick. Try this if it still fails:

Set-ADUser -Identity svc_webfarm -PrincipalsAllowedToDelegateToAccount (Get-ADComputer SQLServer01)

3. Group Policy forcing a higher authentication level than supported

This one's a domain-wide gotcha. You'll see the error across multiple machines — not just one. The culprit is a Group Policy setting that enforces RPC Authentication Level to Packet Privacy on all domain-joined systems. It's meant to harden security, sure. But if you have older apps (think Exchange 2010 or legacy LOB tools), they can't handle that level and throw 0x0000071d.

The fix: Find the policy and either disable it or scope it to exclude the affected machines.

Open Group Policy Management Console (GPMC).
Find the policy that's applying the RPC setting — it's often under Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options.
Look for Network access: Restrict clients allowed to make remote calls to SAM (yes, that's unrelated but often bundled) and Network security: Allow PKU2U authentication requests — but the real one is Microsoft network server: Server SPN target name validation level. Actually, the key setting is Network security: LAN Manager authentication level — if it's set to Send NTLMv2 response only. Refuse LM & NTLM, it can cause issues.
But more directly, check Computer Configuration > Administrative Templates > System > Remote Procedure Call > RPC Authentication Level. If it's enabled and set to Packet Privacy, change it to Not Configured or set it to Connect.
Update the policy on affected machines with gpupdate /force and reboot.

I'd also check the COM+ catalog-level authentication via dcomcnfg — sometimes a script or migration tool flips it to Packet Privacy globally. If you find it there, drop it back to Connect.

Cause	Diagnosis	Fix
DCOM authentication level mismatch	Error on COM calls between specific machines. Check Component Services default properties.	Set default authentication level to Connect (or match client) in dcomcnfg.
Kerberos delegation misconfig	Error in multi-hop scenarios (web to SQL). Check service account delegation tab.	Update constrained delegation, add SPNs, use protocol transition if needed.
Group Policy enforced high auth level	Error across multiple machines in same OU. Check GPO under RPC Authentication Level.	Disable or relax the policy to Connect or Not Configured. gpupdate + reboot.

Quick recap: Start with the DCOM settings — that's the most common. If it's multi-hop, check delegation. If it's widespread, hunt the GPO. I've fixed this error at least a dozen times, and the registry route (setting HKLM\SOFTWARE\Microsoft\Ole\DefaultAuthenticationLevel to 2 for Connect) works in a pinch but I'd prefer the GUI for clarity.