Kerberos Constrained Delegation Not Working

Introduction

A web application authenticates a user fine on its own front door, but the moment it tries to query a back-end SQL Server or file share on that user’s behalf, everything the user does comes back as if it were run by the application’s own service account instead. Or worse — the middle tier just throws an authentication exception the instant it tries the second hop. Nothing about the user’s password or group membership is wrong; the double-hop itself is being refused.

This is constrained delegation failing to do the one thing it exists for: letting service A present a specific user’s identity to service B, and only service B. Once you accept that the KDC is enforcing an explicit allow-list rather than something being broken in Active Directory generally, the fix narrows quickly to a short set of account-level settings.

What You’re Seeing

The error surfaces most clearly in a network capture of the TGS-REQ the middle tier sends when it tries to obtain a service ticket to the back-end on the user’s behalf. Microsoft Network Monitor labels the response plainly:

# Network Monitor trace, filtered on KerberosV5
KerberosV5:TGS Request Cname: middletier$  Realm: CORP.EXAMPLE.COM  Sname: http/backend01.corp.example.com
KerberosV5:KRB_ERROR  KDC_ERR_BADOPTION

Above the protocol layer, the symptom is usually plainer and less specific: the middle-tier application logs a generic Kerberos or “access denied” exception the instant it attempts the second hop, while direct authentication to the front-end works normally. If the back-end is SQL Server, this typically shows up as the connection succeeding but running under the application’s own service identity rather than the calling user’s — or an outright login failure if the back-end has no fallback path.

What It Actually Means

When a client authenticates to a front-end service, that service can request a service ticket to a second, back-end service on the client’s behalf — but only if Active Directory says it is allowed to. Constrained delegation encodes that permission as an explicit list: the msDS-AllowedToDelegateTo attribute on the front-end’s account (its computer account, or a dedicated service account) holds the exact SPNs of the back-end services it may present credentials to. When the front-end asks the KDC for a ticket to a service that is not on that list — or asks at all when no list exists — the KDC returns KDC_ERR_BADOPTION rather than silently degrading to some lesser form of access.

Two further account-level switches change whether the request even gets that far. TrustedForDelegation governs unconstrained delegation and is unrelated to the constrained case. TrustedToAuthForDelegation enables protocol transition — “Use any authentication protocol” in the GUI — which lets the front-end delegate for a user it did not itself authenticate via Kerberos (for example, a user who logged on with forms-based auth). Without it, the front-end must have obtained the user’s own Kerberos ticket first (“Use Kerberos only”). Separately, an account with AccountNotDelegated set, or a member of the Protected Users group, cannot be delegated for under any configuration — that flag exists specifically to make an account immune to delegation, so if it is set on the user (not the service), no amount of front-end configuration will fix the error.

How to Diagnose

Work from the account configuration outward before reaching for a network trace — most delegation failures are visible from PowerShell alone.

# 1. Confirm the front-end and back-end are in the same domain (constrained
# delegation does not work across domains or forests - RBCD is required there)
Get-ADComputer -Identity MIDDLETIER01 -Properties CanonicalName
Get-ADComputer -Identity BACKEND01 -Properties CanonicalName

# 2. Check the front-end account's delegation configuration - computer account case
Get-ADComputer -Identity MIDDLETIER01 -Properties TrustedToAuthForDelegation, msDS-AllowedToDelegateTo |
    Select-Object Name, TrustedToAuthForDelegation, msDS-AllowedToDelegateTo

# 3. Same check for a custom service account running the front-end service
Get-ADUser -Identity svc-middletier -Properties TrustedToAuthForDelegation, msDS-AllowedToDelegateTo, AccountNotDelegated |
    Select-Object Name, TrustedToAuthForDelegation, msDS-AllowedToDelegateTo, AccountNotDelegated

# 4. Confirm the calling user isn't explicitly blocked from being delegated
Get-ADUser -Identity jdoe -Properties AccountNotDelegated, MemberOf |
    Select-Object Name, AccountNotDelegated

# 5. Confirm a KDC is reachable at all before assuming this is a delegation problem
nltest /dsgetdc:corp.example.com /force /kdc

# 6. Inspect the tickets actually held by the process/session hitting the error
klist tickets

Common Causes

Working Through a Fix

Start by establishing which kind of front-end account you have — a computer account running the service under a built-in identity (Network Service, Local System) or a dedicated service account — because the configuration lives on different objects in each case. For a computer account, both the delegation configuration and the SPN list live on the same object:

# View current state before changing anything
Get-ADComputer -Identity MIDDLETIER01 -Properties TrustedToAuthForDelegation, msDS-AllowedToDelegateTo

# Enable constrained delegation with protocol transition to the back-end HOST SPN
Set-ADAccountControl -Identity MIDDLETIER01 -TrustedToAuthForDelegation $true
Set-ADComputer -Identity MIDDLETIER01 -Add @{'msDS-AllowedToDelegateTo'=@('HOST/backend01.corp.example.com')}

For a custom service account, the delegation permission goes on the service account itself, but the front-end server’s own computer account also needs delegation enabled — a step that’s easy to miss because it feels redundant when the service account already has it configured:

# Service account: enable delegation and the allow-list
Set-ADAccountControl -Identity svc-middletier -TrustedToAuthForDelegation $true
Set-ADComputer -Identity MIDDLETIER01 -Add @{'msDS-AllowedToDelegateTo'=@('HOST/backend01.corp.example.com')}

# Front-end computer account: also needs "Trust this computer for delegation
# to specified services only" with "Use any authentication protocol"
Set-ADComputer -Identity MIDDLETIER01 -TrustedForDelegation $false
Set-ADAccountControl -Identity MIDDLETIER01 -TrustedToAuthForDelegation $true

If the front-end and back-end genuinely sit in different domains or forests, none of the above will ever succeed — classic constrained delegation is restricted to a single domain by design. The supported path there is resource-based constrained delegation, configured from the back-end side instead:

# On the back-end account, allow the front-end's computer account to
# delegate to it - this is configured on BACKEND01, not MIDDLETIER01
Set-ADComputer -Identity BACKEND01 -PrincipalsAllowedToDelegateToAccount MIDDLETIER01$

How to Prevent It

Keep the msDS-AllowedToDelegateTo list as narrow as the application actually needs — one or two specific back-end SPNs, never a broad set added “just in case.” A wide delegation list is exactly the kind of lateral-movement path an attacker who compromises the front-end account will look for, so treat it with the same review discipline as a firewall rule change. Document which account holds delegation rights and to what, since this configuration is invisible from the application side and tends to be forgotten until the next migration breaks it.

When standing up a new middle tier, confirm the topology (same domain vs cross-domain) before choosing constrained delegation over RBCD — picking the wrong one early causes exactly this error weeks later when someone finally exercises the double-hop path in production. For the protocol fundamentals this all sits on top of, see the Kerberos authentication post; if the failure turns out to be about ticket decryption rather than delegation permissions, that’s the separate duplicate SPN failure mode.

Quick Reference

Final Thoughts

KDC_ERR_BADOPTION reads as cryptic the first time you hit it, but it is the KDC doing exactly its job: refusing a delegation request that was never explicitly granted. The fix is rarely about Kerberos internals — it’s confirming which account is actually acting as the front-end, and whether its allow-list names the back-end service you expect.

Check the account configuration before reaching for a network trace, keep the allow-list narrow, and remember that an account marked non-delegable is a security control working as intended, not a bug to route around.