Fix SEC_E_DELEGATION_REQUIRED (0x80090345) for real

Quick answer for advanced users

Run klist purge and re-authenticate. If that doesn't work, check the service account's delegation settings in Active Directory Users and Computers — you need either constrained delegation with protocol transition or unconstrained delegation on the front-end server.

What's really going on here

This error pops up when you're trying to access a resource that requires your credentials to be passed from one server to another — a double-hop scenario. Think of it like this: you connect to Server A, and Server A needs to connect to Database B using your identity. If Server A doesn't have permission to delegate your credentials, Kerberos slaps you with SEC_E_DELEGATION_REQUIRED.

I see this most often with web applications running on IIS that connect to SQL Server, or with SSRS reports that need to pull data from a remote database. Had a client last month whose entire payroll system went down because their web server couldn't delegate credentials to the SQL backend. The error message usually reads "The requested operation cannot be completed" with the code 0x80090345.

Step-by-step fix

Step 1: Clear your Kerberos tickets

Before you dive into server config, try the quickest fix — your cached tickets might be stale. Open a command prompt as admin and run:

klist purge

Then log off and back on. This forces a fresh ticket-granting ticket (TGT) from the domain controller. If the error disappears, you had a corrupted ticket. If not, keep going.

Step 2: Check the service's SPN

Kerberos delegation relies on proper Service Principal Names. If the SPN is missing or duplicated, the delegation fails silently. On the domain controller, run:

setspn -L FRONTENDSERVERNAME

Replace with your front-end server's name. You should see an SPN like HTTP/servername.domain.com or MSSQLSvc/servername.domain.com. If it's missing, add it with:

setspn -A HTTP/servername.domain.com DOMAIN\ServerAccount

If you see duplicate SPNs (two entries for the same service), remove one with setspn -D. Duplicates cause Kerberos to pick the wrong account.

Step 3: Enable delegation on the server account

This is the most common fix. Open Active Directory Users and Computers, find the front-end server's computer account (or the service account it runs under). Right-click, go to Properties > Delegation tab.

You have two options:

• Trust this user for delegation to specified services only — safer, you define which backend services the front-end can impersonate you for.
• Trust this user for delegation to any service (Kerberos only) — less secure, but works in a pinch.

For most setups, choose the first option, click "Use Kerberos only," then "Add" the backend service (like MSSQLSvc or HTTP) for the target server. Apply the change. It can take up to 15 minutes to replicate across domain controllers.

Step 4: Reboot the front-end server

Yeah, I know, reboot is cliché. But Kerberos tickets and delegation settings are cached in memory. A reboot forces the server to get a fresh machine account ticket with the delegation flag set. Had a case where the config was perfect but the server wouldn't delegate until a reboot — something about the LSASS process holding stale state.

Alternative fixes if the main one fails

Switch to a service account instead of machine account

If the front-end runs under the machine account (Network Service or Local System), delegation can be tricky. Create a domain service account, assign it the necessary SPNs, and configure delegation on that account. Then change the application pool or service to run as that account. I've seen this fix SSRS delegation issues where the machine account method kept giving 0x80090345.

Temporarily use unconstrained delegation

If you're in a dev environment and need a quick test, enable unconstrained delegation on the front-end server. In the Delegation tab, select "Trust this computer for delegation to any service (Kerberos only)." Don't leave this on in production — it means any service on that server can impersonate you anywhere.

Fall back to NTLM

If Kerberos delegation is a dead end (maybe your domain is 2008-level and doesn't support constrained delegation), you can force NTLM authentication for that specific connection. On the front-end server, edit the registry:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters
Add DWORD: AllowTGTSessionKey = 1

Then restart. This tells Windows to allow NTLM fallback when delegation fails. It's a band-aid, not a cure — NTLM is slower and less secure.

Prevention tip

Plan your delegation model before you build the app. If you know a web app needs to hit a database, set up constrained delegation with protocol transition from day one. Use group managed service accounts (gMSA) where possible — they auto-rotate passwords and make delegation easier to manage. And for heaven's sake, document your SPNs. I've spent hours untangling duplicate SPNs that someone created by accident. A simple PowerShell script that runs weekly to check for duplicates saves headaches.

Also, keep your domain functional level at least Windows Server 2012 R2. Older levels don't support constrained delegation with protocol transition, which is what most modern apps need. If you're still on 2008 R2, that's a bigger problem than this error.