STATUS_USER2USER_REQUIRED (0XC0000408) — Kerberos User2User explained

You're most likely to hit this error when a service — like Exchange Server, SQL Server, or an RPC-over-HTTP application — tries to request a Kerberos service ticket and gets back 0XC0000408 instead of a valid ticket. The common scenario: a client behind NAT or a load balancer authenticates to a web service, which then needs to authenticate to a backend SQL or mailbox database. The middle-tier service passes the client's ticket, but the backend says "no — I need a User2User ticket, not a regular one."

What's actually happening here

Kerberos User2User (U2U) is a sub-protocol designed for scenarios where the target service doesn't have a machine account — or can't decrypt a regular service ticket because it's running as a virtual account, a highly constrained group Managed Service Account (gMSA), or under a user identity that doesn't have a long-term key in the domain. Instead of relying on the service's long-term key (derived from the computer or service account password), U2U forces the client to encrypt the ticket using the service's session key. That session key is obtained through an initial AS-REQ/AS-REP exchange between the client and the KDC, which requires the service to have already authenticated with the KDC.

The error 0XC0000408 means the KDC decided "this service ticket request requires User2User" — but the client or the service didn't perform the prerequisite step: the TGS-REQ didn't include the service's session key in the PA-DATA field. In plain English: the client didn't first fetch a session key for the target service, so the KDC can't build a U2U ticket. The fix is to either make the service support regular Kerberos (by giving it a proper SPN and a domain-joined machine account) or to properly implement the U2U handshake.

The real fix — configure SPNs and delegation

Skip the half-baked suggestions about disabling Kerberos or forcing NTLM. That's lazy and breaks delegation. Here's what works:

1. Verify the service account has a valid SPN. Run this on a domain controller or from a management machine with RSAT:

   setspn -L DOMAIN\ServiceAccountName

   If the output shows no SPNs, or only a generic HOST/ SPN, that's the problem. Add the proper SPN:

   setspn -S HTTP/webserver.contoso.com DOMAIN\ServiceAccountName

2. Check if the account is a gMSA. gMSAs by default don't have a user principal name in the AD — they rely on U2U because they have no long-term password you can use to encrypt a ticket. If you see the error with a gMSA, you need to configure constrained delegation:

   Set-ADServiceAccount -Identity gMSA_SQL -PrincipalsAllowedToDelegateToAccount "SQLBackend$"

   This tells the backend to trust tickets issued to the gMSA without requiring U2U.
3. Force the application to use delegation instead of U2U. For IIS-hosted services (like Exchange or SharePoint), set the application pool identity to a domain user account with a proper SPN, then enable Kerberos Constrained Delegation (KCD) in Active Directory Users and Computers for that account.
4. If you must keep the gMSA or virtual account, implement the U2U handshake correctly. The client must first request a session key for the target service by sending an AS-REQ with the target's principal name. In .NET, this means setting KerberosRequestorCredential or using the System.Net.Kerberos classes. Most applications don't do this automatically — that's why you see the error.

Still failing? Check these

• Is the time skew between client, KDC, and service within 5 minutes? Kerberos is brutal about clock drift. Use w32tm /query /status on all three.
• Are the service's DNS records correct? The KDC uses DNS to find the target service. If the name resolves to a different server, you'll get a ticket for the wrong machine, and U2U will fail. Run nslookup webserver.contoso.com and verify it points to the machine that actually hosts the service.
• Enable Kerberos logging on the target server. Set this registry value:

  HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters

  Create a DWORD LogLevel = 0x1. Reproduce the error, then check Event Viewer > Windows Logs > System, filtering for source Kerberos. Look for event ID 5 or 6 — they'll tell you exactly which step of the TGS exchange failed.

Don't just disable User2User by hacking the registry — that breaks the security model and can cause silent failures in delegation chains. Fix the SPN and delegation path properly.