Kerberos delegation and directory permissions

Describe the two hops

The usual example is a web front end calling SQL on the user’s behalf. Check the user’s identity on the first hop, the front-end service account, the back-end SPN and the identity SQL actually sees.

Some applications use their own service identity for the back end and don’t need delegation. Where delegation is intended, a successful first-hop Kerberos logon still leaves the second hop to check.

The delegation settings live in different places

S4U2Self obtains a ticket to the service for a user. S4U2Proxy obtains a ticket to a back-end service on that user’s behalf. RBCD supports cross-domain scenarios; Microsoft’s delegation overview explains the model introduced in Windows Server 2012.

The protocol-transition flag is not permission to obtain any ticket for any user. It affects whether the KDC can mark an S4U2Self result forwardable, subject to the user’s restrictions and current KDC checks. S4U2Self itself, the evidence ticket’s flags, and authorization of the later S4U2Proxy request are separate decisions. The MS-SFU KDC data model maps these controls to the AD attributes.

Inventory all relevant account types

From an AD PowerShell session:

Get-ADObject -LDAPFilter '(|(userAccountControl:1.2.840.113556.1.4.803:=524288)(userAccountControl:1.2.840.113556.1.4.803:=16777216)(msDS-AllowedToDelegateTo=*)(msDS-AllowedToActOnBehalfOfOtherIdentity=*))' `
    -Properties sAMAccountName, userAccountControl, servicePrincipalName,
        msDS-AllowedToDelegateTo, msDS-AllowedToActOnBehalfOfOtherIdentity |
    Select-Object sAMAccountName, ObjectClass, DistinguishedName,
        userAccountControl, servicePrincipalName, msDS-AllowedToDelegateTo,
        msDS-AllowedToActOnBehalfOfOtherIdentity

This queries the current domain naming context. Repeat for other domains when doing a forest review. Querying computer objects alone misses delegation configured on user service accounts.

The RBCD attribute is a security descriptor, not a list of SPN strings. For a known computer account, inspect the module’s resolved view:

Get-ADComputer -Identity SQL01 -Properties PrincipalsAllowedToDelegateToAccount |
    Select-Object Name, PrincipalsAllowedToDelegateToAccount

For each result, find the owner, intended use, permitted destinations and who can edit the account or descriptor. A constrained configuration can still be too broad or writable by the wrong people.

For a user-based service identity, inspect the corresponding account too:

Get-ADUser -Identity svc-web -Server dc1.contoso.com `
    -Properties ServicePrincipalNames, TrustedForDelegation,
        TrustedToAuthForDelegation, msDS-AllowedToDelegateTo,
        PrincipalsAllowedToDelegateToAccount |
    Select-Object SamAccountName, ServicePrincipalNames,
        TrustedForDelegation, TrustedToAuthForDelegation,
        msDS-AllowedToDelegateTo, PrincipalsAllowedToDelegateToAccount

For managed service accounts use Get-ADServiceAccount and the applicable properties. An application pool’s name, the host’s computer account and the outbound connection identity may be three different things. Find the principal sending the request before changing an account’s delegation settings.

The resource descriptor and object DACL protect different operations

The RBCD attribute contains a security descriptor used to decide whether a requesting service may delegate to that account. The AD object’s DACL separately controls who may replace that attribute. A front end being permitted by the first descriptor does not mean its administrator should be allowed to rewrite the second policy.

Check the descriptor, its resolved principals and the object’s modification permissions separately. The attribute definition describes the delegation access check. Include groups controlling the permitted front ends, access to service-account keys, and administrators of hosts that can run under those identities.

Sensitive users can deliberately break delegation

Get-ADUser -Identity alice -Properties AccountNotDelegated |
    Select-Object SamAccountName, AccountNotDelegated
Get-ADGroupMember -Identity 'Protected Users'

The sensitive-and-cannot-be-delegated flag and Protected Users membership can prevent a workflow that otherwise appears correctly configured. Check that before changing a service’s delegation settings. Do not remove user protections merely to make a test succeed; establish how the sensitive account is intended to use the application. See Protected Users.

Inspect the permissions behind the setting

With the AD PowerShell provider available:

$target = 'CN=SQL01,OU=Servers,DC=contoso,DC=com'
(Get-Acl -Path "AD:\$target").Access |
    Select-Object IdentityReference, AccessControlType, ActiveDirectoryRights,
        ObjectType, InheritedObjectType, IsInherited, InheritanceType

An object-specific ACE’s GUID matters. WriteProperty for one harmless attribute is different from permission to replace an RBCD security descriptor. Resolve the GUID against the schema or extended-right definitions before describing its impact.

Also review ownership, WriteDACL, WriteOwner, inherited permissions, and writable group membership. These can provide a path to changing the service relationship even if the current delegation setting looks correct. Effective access depends on the actual token and ACE evaluation, rather than a text search for one group name.

“Deny always wins” is too broad. In the normal canonical order, explicit entries precede inherited entries, so an explicit allow can satisfy a right before an inherited deny is reached. Object-specific rights and inheritance generations add detail. Inspect the actual descriptor and requested rights; see Microsoft’s ACE ordering reference.

The AD: provider uses its own server context. A Get-ADUser -Server DC2 earlier in the console does not retarget that drive automatically. When comparing an ACL change across DCs, use a provider drive bound to the intended server or an explicit LDAP security-descriptor read, and record the target with the result.

MachineAccountQuota is only one creation path

$domain = Get-ADDomain
Get-ADObject -Identity $domain.DistinguishedName `
    -Properties ms-DS-MachineAccountQuota |
    Select-Object DistinguishedName, ms-DS-MachineAccountQuota

Review the quota alongside delegated computer-creation rights, existing object ownership, and the join workflow. Reducing the quota does not remove separately delegated rights or repair overly broad ACLs on existing computers. Treat a quota change as a planned domain change, with the teams that provision devices involved.

For a failing application, use the delegation troubleshooting sequence to distinguish first-hop authentication, evidence-ticket construction, the back-end request, and final authorization. Broadly enabling unconstrained delegation does not identify which of those stages failed.