Fix SEC_E_DELEGATION_POLICY (0X8009035E) Fast

What You’re Seeing

The SEC_E_DELEGATION_POLICY (0X8009035E) error pops up when you try to authenticate to a server that requires Kerberos delegation, but the client’s policy says no. It’s common in multi-hop scenarios — like an app on ServerA trying to access SQL Server on ServerB using your credentials.

The Quick Fix

Don’t waste time chasing network issues. The culprit here is almost always the delegation policy on the client machine or the service account.

Step 1: Check the Client’s Group Policy

1. On the client machine, open gpedit.msc (or check the relevant GPO in AD).
2. Go to Computer Configuration > Administrative Templates > System > Kerberos.
3. Find “Set maximum tolerance for computer clock synchronization” — make sure it’s not set too low (default is 5 minutes).
4. Look for “KDC proxy server” settings — leave them default unless you’re using a proxy.
5. The key one: “Allow Delegation to Specific Services” — ensure it’s enabled and includes the target server’s service principal name (SPN).

If that policy is missing or set to “Not Configured”, delegation defaults to restrictive. Enable it and add the SPN for the target service (e.g., MSSQLSvc/sqlserver.domain.com).

Step 2: Verify the Service Account

Open Active Directory Users and Computers. Find the computer account or service account running the target service. Right-click > Properties > Delegation tab.

• If it’s grayed out, you’re on a domain controller or the account is protected (like Protected Users group). Move the account out of that group.
• Select “Trust this computer for delegation to specified services only” — use “Use Kerberos only” unless you need protocol transition.
• Add the SPN for the service.

Step 3: Apply and Test

Run gpupdate /force on the client. Then test authentication again. If it still fails, reboot the client — Kerberos tickets are cached and won’t refresh until a reboot or klist purge.

Why This Works

The error 0X8009035E is Microsoft’s way of saying “I see you want to delegate, but the policy says no.” Kerberos delegation requires explicit permission on both ends — the client’s policy allows it, and the service account is marked as trustworthy for delegation. If either side is missing, the ticket request fails.

Less Common Variations

1. The “Resource-Based Constrained Delegation” Mess

If you’re using resource-based constrained delegation (Windows Server 2012+), the old UI won’t help. Instead, use PowerShell on the target server (the resource) to grant delegation:

Set-ADComputer -Identity TargetServer -PrincipalsAllowedToDelegateToAccount ClientServer

Replace TargetServer with the server you’re accessing, and ClientServer with the machine making the request.

2. The “Protected Users” Group

If the user account or computer account is a member of the Protected Users group (Windows 8.1/Server 2012 R2+), delegation is flat-out blocked. Remove the account from that group in AD UC.

3. The “Domain Controller as a Client” Trap

Domain controllers don’t allow delegation by default. If you’re running an app on a DC that needs to double-hop, don’t — move the app to a member server. If you must, you’ll need to set the DC’s msDS-AllowedToDelegateTo attribute manually via ADSI Edit, but it’s a bad idea.

4. The “Clock Skew” Red Herring

Some forums will tell you to mess with time synchronization. Ignore that unless the client is more than 5 minutes off from the DC. That’s a KDC_ERR_PREAUTH_FAILED error (0x80090328), not this one.

Prevention

Once you’ve fixed it, keep it from breaking again:

• Document SPNs — use setspn -L to list them. A duplicate SPN will cause silent failures.
• Use Group Policy Objects — apply the delegation policy to all client machines in a specific OU, not one at a time.
• Monitor Kerberos authentication — enable Kerberos logging on clients via registry (HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters, add DWORD LogLevel = 0x1). Check Event ID 4768 and 4769.
• Avoid service accounts in Protected Users — unless you want them to never delegate.

That’s it. Fix the policy, adjust the delegation tab, and you’re good. No magic — just AD settings that Microsoft made intentionally obtuse.