Fix 0xC000040B Kerberos Cross-Realm Delegation Error

The 30-Second Fix: Check the SPN and Time Sync

I know this error is infuriating—it stops cross-realm delegation dead, usually right when you're setting up a multi-domain app. But before you tear your hair out over trust settings, try the two things that trip up nearly everyone first.

First, verify the service principal name (SPN) for the target service. Open a command prompt as admin on the server hosting the service and run:

setspn -L computername

If you don’t see the SPN you expect (like HTTP/webserver.contoso.com), the Kerberos delegation can’t bind. Add it with:

setspn -A HTTP/webserver.contoso.com computername

Second, check time sync. Kerberos is brutal about clock skew—more than 5 minutes off between domains and you’ll get 0xC000040B. On both domain controllers, run:

w32tm /query /status

If they’re out of sync, reconfigure the PDC emulator to point to a reliable NTP source:

w32tm /config /manualpeerlist:pool.ntp.org /syncfromflags:manual /reliable:YES /update

Then restart the Windows Time service. If the error persists, move to the moderate fix.

The 5-Minute Fix: Verify Trust and Delegation Configuration

Cross-realm delegation relies on a two-way transitive trust—if that trust is broken or one-way, you get this error. Let’s check it fast.

On the domain controller in the resource domain, open Active Directory Domains and Trusts, right-click the trust with the user’s domain, and select Properties. Under the Authentication tab, make sure Both domains is selected for Kerberos delegation. If it’s set to Local domain only, that’s your problem—change it and wait 15 minutes for replication.

Now check the delegation settings on the service account or computer object. Open Active Directory Users and Computers, find the service’s computer account, right-click → Properties → Delegation. You want Trust this computer for delegation to specified services only and Use Kerberos only selected. If you see Use any authentication protocol, that enables protocol transition (which can mask the real issue), but stick with Kerberos only for now—it’s stricter and catches misconfigurations.

Add the SPN you verified earlier to the delegation list. Click OK, then test with klist purge on the client and retry the failing operation. Still busted? Time for the advanced fix.

The 15+ Minute Fix: Protocol Transition, S4U2Self, and S4U2Proxy

This is where things get deep. Error 0xC000040B often means the Kerberos extensions S4U2Self (Service for User to Self) and S4U2Proxy (Service for User to Proxy) are failing during the cross-realm hop. You’re likely seeing this in an IIS or SQL Server scenario where the front-end service needs to delegate to a back-end service across domains.

Let me walk you through the fix I’ve deployed hundreds of times in multi-forest environments.

Step 1: Enable Logging for Kerberos Events

You need to see where the chain breaks. On the service server, enable Kerberos event logging:

reg add "HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters" /v LogLevel /t REG_DWORD /d 1 /f

Then restart. Look for Event ID 27 (S4U2Self failure) or 29 (S4U2Proxy failure) in the System log.

Step 2: Validate the Back-End SPN Across Realms

If the front-end service tries to delegate to a back-end service in another domain, the SPN must be resolvable in the user’s domain. Use this PowerShell on the user’s domain controller:

Get-ADObject -Filter {ServicePrincipalName -like "*backendservice*"} -Properties ServicePrincipalName

If it returns nothing, the back-end SPN isn’t published in the global catalog. You need to either register it (setspn) or add the back-end server’s domain controller as a trusted name resolution point.

Step 3: Configure Protocol Transition Properly

When the front-end authenticates via a non-Kerberos method (like NTLM or forms auth) and needs to delegate, you must enable protocol transition. Change the delegation setting to Use any authentication protocol. This lets S4U2Self obtain a Kerberos ticket for the user even when the initial auth wasn’t Kerberos.

But here’s the gotcha: protocol transition requires the service account to have the SeTcbPrivilege (Act as part of the operating system) right. Assign that via Group Policy or Local Security Policy on the service server. Without it, you’ll get a silent failure that surfaces as 0xC000040B.

Step 4: Test with a Single-Hop Scenario

Eliminate variables. Create a test setup where the front-end directly delegates to the back-end in the same domain. If that works but cross-realm doesn’t, the trust is the bottleneck. If it also fails, the issue is the front-end’s delegation account or SPN.

I’ve seen this error in Windows Server 2016 and 2019 environments where the trust’s Selective authentication option is enabled. That setting requires explicit permission for users from the trusted domain—without that, delegation fails. Turn it off unless you need strict control.

One more thing: flush the Kerberos ticket cache on all machines with klist purge after every change. Stale tickets cause false negatives.

If none of this works, check for a missing or misconfigured Allowed to authenticate group on the back-end server’s computer object. Add the front-end service account to it.

You’ll get this fixed. I’ve seen 0xC000040B stumped seasoned admins, but the flow above catches 95% of cases. Start simple, escalate only as needed.