Kerberos Delegation Set to 'Use Kerberos Only' Silently Blocks Protocol Transition

Symptom

A front-end web application configured for Kerberos constrained delegation authenticates domain-joined desktop users through their browser without any problem, yet the same application intermittently fails to reach a backend SQL Server or internal API on behalf of a subset of users, returning errors such as ‘Cannot generate SSPI context’ or a generic logon failure at the second hop.

The failure is not constant: administrators testing from a domain-joined workstation using Integrated Windows Authentication see the delegated call succeed every time, which reinforces the assumption that delegation is correctly configured.

False Assumption

The misleading assumption is that the ‘Use Kerberos only’ option on the Delegation tab in Active Directory Users and Computers is simply a more restrictive version of ‘Use any authentication protocol’, limiting which protocols delegation will accept without changing what the service account is actually capable of doing.

Under that assumption, an administrator who wants to apply least-privilege thinking to a new constrained-delegation configuration selects ‘Use Kerberos only’ because it sounds safer, then verifies the change with a Kerberos-authenticated desktop client and signs it off as working.

Root Cause

The root cause is that the two Delegation-tab options configure different capabilities, not just different protocol scopes: ‘Use any authentication protocol’ sets the TRUSTED_TO_AUTH_FOR_DELEGATION bit (commonly abbreviated T2A4D) in the account’s userAccountControl attribute in addition to populating msDS-AllowedToDelegateTo, while ‘Use Kerberos only’ populates msDS-AllowedToDelegateTo without setting that bit.

The T2A4D bit is what permits the service account to perform S4U2Self, the Kerberos extension that lets a service obtain a ticket on behalf of a user who did not authenticate to it using Kerberos in the first place. Without that bit, the account can still use S4U2Proxy to forward an existing Kerberos service ticket to a backend service, but it cannot manufacture a delegatable ticket for a user who arrived over NTLM, forms authentication, or any other non-Kerberos mechanism.

Impact

The operational impact is that authentication paths already carrying a Kerberos ticket keep working, while any client that authenticated to the front-end by a non-Kerberos method fails at the backend hop, and because the two paths are indistinguishable from the application’s own logs, the fault is easy to misattribute to network issues, browser configuration, or user error rather than to the delegation flag itself.

This also means a change that passes every test performed from a domain-joined desktop can still be broken for remote users, third-party integrations, or service accounts that reach the front-end through non-Kerberos authentication, and the gap may not surface until those users are already in production.

Diagnosis

Confirm the configured delegation target and the current userAccountControl value on the service account before changing anything, using read-only queries against Active Directory.

Get-ADUser -Identity 'svc-webapp' -Properties 'msDS-AllowedToDelegateTo','userAccountControl' | Select-Object Name, msDS-AllowedToDelegateTo, userAccountControl

Convert the userAccountControl value to binary and check whether bit 0x1000000 (TRUSTED_TO_AUTH_FOR_DELEGATION) is present.

[Convert]::ToString((Get-ADUser -Identity 'svc-webapp' -Properties userAccountControl).userAccountControl,2)

On the front-end server, capture the Kerberos ticket cache during a failing non-Kerberos client request to confirm whether an S4U2Self attempt is present and failing, versus never being attempted.

klist tickets

Treat the absence of the T2A4D bit alongside a populated msDS-AllowedToDelegateTo list as the diagnostic signature of this trap: delegation is configured, but only for clients that already hold a Kerberos ticket.

Correction

The correction is to explicitly grant the protocol-transition capability the workflow requires, rather than leaving the account restricted to Kerberos-ticket-only delegation.

Set-ADAccountControl -Identity 'svc-webapp' -TrustedToAuthForDelegation $true

This can equally be applied by reopening the Delegation tab in Active Directory Users and Computers and selecting ‘Use any authentication protocol’ for the same set of target SPNs; the PowerShell command and the GUI option change the same underlying attribute. Do not widen the msDS-AllowedToDelegateTo list while making this change: the correction is to add protocol-transition capability for the existing, already-scoped backend services, not to add new delegation targets.

Validation

Validation succeeds only when a non-Kerberos client path completes the delegated backend call, not merely when the userAccountControl bit is present.

• Re-query userAccountControl and confirm bit 0x1000000 is now set, with msDS-AllowedToDelegateTo unchanged.
• Authenticate to the front-end using a non-Kerberos method (forms authentication or an NTLM-only client) and exercise the code path that calls the backend on the user’s behalf; the call must succeed and the backend must show the delegated identity, not the service account’s own identity.
• Re-test the previously working Kerberos-ticket client path to confirm the change has not altered existing behaviour.
• Review the final msDS-AllowedToDelegateTo list to confirm it still contains only the specific backend SPNs the workflow requires.

Rollback

Rollback removes the protocol-transition capability and returns the account to its previous, narrower delegation behaviour, without altering the msDS-AllowedToDelegateTo scope.

Set-ADAccountControl -Identity 'svc-webapp' -TrustedToAuthForDelegation $false

Record the pre-change userAccountControl value and the msDS-AllowedToDelegateTo list before making the correction, so the rollback restores an exact known state rather than an assumed default. After rolling back, re-run the Kerberos-ticket client test to confirm the previously working path is unaffected, and document that the non-Kerberos path will fail again until the correction is reapplied.

Prevention

Because TRUSTED_TO_AUTH_FOR_DELEGATION permits S4U2Self impersonation of any user to the listed SPNs, treat it as a privileged capability decision rather than a protocol preference, and require the msDS-AllowedToDelegateTo list to stay limited to the specific backend services the workflow actually calls. Build a pre-deployment test matrix for any new or changed constrained-delegation configuration that includes at least one non-Kerberos authenticated client path alongside the domain-joined desktop path, since testing only the Kerberos-ticket path is what allows this misconfiguration to reach production undetected. Periodically re-query userAccountControl and msDS-AllowedToDelegateTo on delegation-enabled service accounts as part of an identity security review, so an account that was correctly scoped at creation time is confirmed to still be correctly scoped as the application’s authentication methods evolve.