Fixing SEC_E_CROSSREALM_DELEGATION_FAILURE (0x80090357) for Windows Auth

Yeah, this one's a pain. You're trying to authenticate across domains—say from app.domain.com to sql.domain.com—and Windows bails with SEC_E_CROSSREALM_DELEGATION_FAILURE and code 0x80090357. The error means Kerberos can't complete a delegation chain between two different Kerberos realms (usually Active Directory domains).

The Fix: Set the SPN and Enable Constrained Delegation

What's actually happening here is your front-end service (like IIS or a web app) is trying to delegate the user's credentials to a back-end service (like SQL Server or a file share), but the service account lacks permission to do that across realms. The fix is two-fold:

1. Register the correct SPN on the back-end service account. If the front-end service runs as DOMAIN1\WebSvc and the back-end is DOMAIN2\SqlSvc, you need an SPN like MSSQLSvc/sql.domain.com:1433 registered on SqlSvc in Domain2. Use setspn -A on a Domain Controller for Domain2.
2. Enable constrained delegation on the front-end service account. In Active Directory Users and Computers for WebSvc in Domain1, enable "Trust this user for delegation to specified services only" and add the SPN from step 1. Use Kerberos only, or protocol transition if you need pass-through for non-Kerberos auth (like forms login).

# On Domain2 DC, register SPN for SQL service account
setspn -A MSSQLSvc/sql.domain.com:1433 DOMAIN2\SqlSvc

# Verify SPN
setspn -L DOMAIN2\SqlSvc

The reason step 2 works is that constrained delegation explicitly tells Kerberos the front-end service is allowed to request tickets for the back-end service on behalf of the user. Without this, Kerberos sees the cross-realm request as unauthorized and rejects it with 0x80090357.

Why Is Cross-Realm Delegation Different?

Inside a single domain, delegation is straightforward—the domain controller trusts the requesting service. Across domains, the trust between domains exists, but that trust doesn't automatically extend to delegation. Kerberos's delegation model is conservative: it assumes the front-end service shouldn't be allowed to request tickets in another realm unless explicitly configured. That's why the error is so specific.

Less Common Variations

Variation 1: S4U2Self with No Protocol Transition

If you're using S4U2Self (Service for User to Self) without protocol transition, you'll get this error when the front-end tries to pass the ticket to the back-end. The fix is to check the box "Use any authentication protocol" in the delegation tab—this enables protocol transition. Without it, S4U2Self can't convert a non-Kerberos ticket (like NTLM) into a Kerberos ticket for delegation.

Variation 2: Disjoint Namespace

If the DNS name of the back-end server doesn't match the domain name (e.g., server lives in DOMAIN2 but its FQDN is server.othercompany.local), Kerberos won't find the right realm. You'll get 0x80090357 with a side of KRB5KDC_ERR_C_PRINCIPAL_UNKNOWN in the event log. The fix: register an SPN with the correct FQDN that matches the server's domain, like HTTP/server.domain2.com instead of HTTP/server.othercompany.local.

Variation 3: Time Skew Between Realms

Kerberos is time-sensitive. If the clocks between Domain1 and Domain2 are off by more than 5 minutes (the default max skew), delegation fails with this error. Run w32tm /resync on both domain controllers and check the time sources. An NTP sync fixes it immediately.

Prevention: Design Trust and Delegation Upfront

To avoid this error in the future:

• Use the same domain for services that need delegation. If you can move SQL Server into the same domain as the web app, that's the cleanest fix. No cross-realm issues.
• Configure constrained delegation early. Don't rely on unconstrained delegation (the old "Trust this user for delegation to any service" option)—that's a security risk and Microsoft is deprecating it in newer Windows Server versions. Use constrained delegation with explicit SPNs.
• Test SPN uniqueness. Duplicate SPNs cause delegation to fail silently. Run setspn -X periodically on your DCs to catch duplicates.
• Document the trust type. If you have a forest trust with selective authentication, delegation won't work unless you configure the trust to allow delegation across the boundary. Check the trust properties in AD Domains and Trusts.

One last thing: if you're still stuck, enable Kerberos logging on the front-end server (reg add HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters /v LogLevel /t REG_DWORD /d 1) and look for event ID 27 or 29 in the System log. Those tell you exactly which service account and SPN caused the failure.