Skip to content
WindowsDeep Dive Published Updated 4 min readViews unavailable

Windows RBCD Audits: Trace Resource-Based Kerberos Delegation

Audit which Active Directory principals may delegate to a service, distinguish RBCD from classic KCD, and verify scope without changing directory state.

Resource-based constrained delegation (RBCD) records which front-end principals a resource account trusts to request Kerberos service tickets on behalf of users. It is easy to confuse this with classic constrained delegation, where the front-end account carries a list of allowed back-end service principal names. The location of the trust matters during reviews: RBCD is stored as a security descriptor on the account running the resource service.

This is a read-only audit workflow. It uses Active Directory query cmdlets only and deliberately omits commands that grant, replace, or clear delegation state. Run it with an account authorized to read the target objects, and treat any proposed change as a separate, reviewed directory operation.

Separate RBCD from classic constrained delegation

The directory attribute msDS-AllowedToActOnBehalfOfOtherIdentity is on the resource account. Microsoft defines it as an access-check descriptor for deciding whether a requestor may act on behalf of other identities to services running as that account. A resource administrator can therefore inspect the target service account to find which front-end principals it trusts.

Classic constrained delegation uses a different attribute, msDS-AllowedToDelegateTo, on the delegating account. That attribute lists the service principal names of services to which the front-end account may delegate. Do not review only the front-end object and assume it describes RBCD. Conversely, an RBCD entry on a resource account does not by itself prove that the front-end service is healthy, that its SPNs are correct, or that a user request reached the intended service.

RBCD is account-scoped rather than a separate ACL for each displayed SPN. Inventory the service account and its SPNs so that you understand which services share that account identity. A computer account may run several services; a user or group Managed Service Account may also be the account associated with a resource service.

Query a known resource account without changing it

Start with a target identified from the application path, such as a back-end computer. The Active Directory module exposes the computed PrincipalsAllowedToDelegateToAccount property as well as the underlying security descriptor:

Import-Module ActiveDirectory

$resource = Get-ADComputer -Identity 'APP-BACKEND' -Properties @(
    'PrincipalsAllowedToDelegateToAccount',
    'msDS-AllowedToActOnBehalfOfOtherIdentity',
    'ServicePrincipalName'
)

$resource |
    Select-Object Name, DistinguishedName, ServicePrincipalName

$resource.PrincipalsAllowedToDelegateToAccount |
    Select-Object Name, SamAccountName, DistinguishedName, ObjectClass

$descriptor = $resource.'msDS-AllowedToActOnBehalfOfOtherIdentity'
if ($null -eq $descriptor) {
    'No RBCD security descriptor was returned for this object.'
} else {
    $descriptor.Access |
        Select-Object IdentityReference, ActiveDirectoryRights,
            AccessControlType, IsInherited
}

Use Get-ADUser or Get-ADServiceAccount when the resource runs under one of those object types. If the audit spans domains or replication sites, query the intended domain controller explicitly and compare the replicated result before declaring a change effective. Do not enumerate every account blindly; begin with the resource identities in the application’s documented call path.

Resolve each returned principal to its owner and workload. Confirm that it is an expected front-end service identity, still enabled, and still used by the application. Review stale computer accounts, retired services, broad groups, unknown SIDs, and principals that can be controlled by less-trusted teams. An ACL entry is not merely a descriptive setting: it delegates a service’s ability to present user identity to another service.

Interpret the protocol boundary, not only the ACL

S4U2Proxy lets a service obtain a Kerberos ticket to a second service on behalf of a user. The client does not necessarily supply a forwarded ticket-granting ticket and may not know that the service is performing delegation. Microsoft documents that RBCD allows protocol transition as if the traditional trusted-to-authenticate-for-delegation bit were set. That behavior makes the resource-side authorization path especially important.

The allowed-principal list does not prove a user can reach the resource. The account must have the required service identity and SPN, the KDC must be able to process the request, the back-end service must accept the ticket, and its own authorization policy must permit the requested operation. A successful connection may also use another authentication mechanism, so capture the client, front-end identity, exact target name, domain controller, time, and authentication package during validation.

Before proposing remediation, preserve the queried object, its distinguished name, current descriptor, relevant SPNs, domain controller, timestamp, and application owner. Have the resource owner approve the intended front-end set and review who can write the resource account’s delegation attribute. This article does not include a write procedure; do not turn an audit finding into a broad delegation grant or clear an entire descriptor without an authorized, scoped change plan.

Related:

Sources:

Comments