Kerberos delegation and RBCD penetration testing guide

Kerberos delegation and RBCD penetration testing determines whether a service can act for a user only against intended backends — and whether a compromised account, host or write permission can expand that relationship into unauthorised impersonation. Finding a delegation attribute is not the conclusion. Identify who can change it, which SPNs it covers, whether protocol transition is permitted and which sensitive users remain delegable.

Delegation solves the legitimate “second hop”: a user reaches a front end and the front end must access a database, share or API as that user. Poor design turns compromise of an application server into the ability to act as people who authenticate to it. Resource-based constrained delegation moves the trust decision onto the target resource, but it does not mean “safe delegation” by definition. An ACL that permits a principal to change the target can be equivalent to impersonation rights against that resource.

Kerberos fundamentals: TGT, TGS, SPN and PAC

After authentication, the client receives a Ticket Granting Ticket from the Key Distribution Center. To use a service, it asks the Ticket Granting Service for a service ticket addressed to a Service Principal Name, such as HTTP, CIFS or MSSQL on a particular account. The server decrypts that ticket with the account’s key and obtains authorisation data, which in Windows environments generally includes a Privilege Attribute Certificate.

An SPN is not a friendly label. It binds a service instance to the account holding the key required to validate its ticket. Duplicate, stale or overprivileged SPN ownership creates security and availability problems. A delegation assessment therefore maps service, host, runtime identity, SPN and backend as one flow.

Distinguish credentials from tickets. Not every delegation method forwards the user’s password or TGT. S4U lets a service obtain user-context tickets through a KDC decision. The risk remains material because the backend receives a ticket whose client identity is the user.

Four delegation models, four risk profiles

Unconstrained delegation

With unconstrained delegation, a service can receive a forwarded user TGT and use it towards other services. MS-SFU explains that the forwarded-TGT mechanism does not constrain which subsequent services the front end accesses as the user. Compromise of such a host can therefore expose the credentials of people who connect to it.

Remove unconstrained delegation from member servers. Any exception needs a documented owner, isolation, monitoring and migration date. Privileged identities should carry “Account is sensitive and cannot be delegated”; suitable user accounts can enter Protected Users after compatibility testing.

Classic constrained delegation (KCD)

Classic KCD stores permitted target services on the front-end account in msDS-AllowedToDelegateTo. The administrator says service A may delegate to SPN B. Scope is smaller than unconstrained delegation, but compromise of A still enables action as delegable users against the approved backends.

“Use Kerberos only” assumes the user authenticated through Kerberos and the front end received an appropriate ticket. “Use any authentication protocol” enables protocol transition, allowing the front end to represent a user after another authentication mechanism. That flexibility expands the threat model: the service identifies a user for S4U2self and the KDC decides whether onward delegation is allowed.

Resource-based constrained delegation (RBCD)

RBCD stores the decision on the target resource in the security descriptor held by msDS-AllowedToActOnBehalfOfOtherIdentity. Server C identifies which principals — for example computer account B — may act for users towards C. Microsoft exposes PrincipalsAllowedToDelegateToAccount as a convenient management representation.

Operationally, the resource owner can manage the relation without modifying the front-end account, and the model better accommodates some cross-domain scenarios. The security risk sits in the ACL. A principal holding GenericWrite, WriteProperty, WriteDACL, WriteOwner or effective control of C can add an identity it controls as a trusted front end. RBCD is only as safe as protection of the target object and the principal admitted to delegation.

Protocol transition and S4U

S4U2self lets a service obtain a ticket to itself containing a user’s identity and authorisation data when the user may have authenticated through another protocol. S4U2proxy then lets that service request a ticket to another service in the user’s context when delegation policy permits it.

Microsoft’s MS-SFU specification states that the returned Service 2 ticket carries the user as the client, not Service 1. The backend handles it as the user’s request. That is the intended capability and the reason compromise of trusted Service 1 matters.

What creates an RBCD attack path?

Reading the attribute is not enough. A path needs at least a controlled service principal with a known key, the ability to modify the target descriptor, valid SPN semantics and reachability to the KDC and target. Historically, users in some domains could create a limited number of computer accounts under ms-DS-MachineAccountQuota, but never assume the value. Assess it together with actual object-creation delegation.

A typical graph path is:

account A can write computer object C or a group controlling C;
A controls service account B or can create an admitted principal;
C’s RBCD descriptor is extended to include B;
B uses an S4U flow so the KDC issues a target-service ticket in a delegable user’s context;
the user’s rights on C determine the final impact.

This is a model, not an operational recipe. A production penetration test should not alter RBCD on a critical server merely to “prove Domain Admin”. Evidence of ACL control and a graph simulation can be sufficient. If the client requires active validation, use a dedicated host and test user without business privileges.

Scope of a technical delegation assessment

Objects and attributes

Inventory user, computer and gMSA identities with delegation flags, msDS-AllowedToDelegateTo, msDS-AllowedToActOnBehalfOfOtherIdentity, SPNs, owner and complete ACL. Include direct and inherited rights, transitive group membership and control of the OU from which an object inherits permissions.

Do not stop at identities where delegation is already enabled. Principals that can configure it, move an SPN, reset a service secret or compromise the host matter just as much. Connect those results to the broader Active Directory security graph.

Application dependencies

For every relation, document the owner, front end, backend, SPN, runtime account, first-hop protocol, required second hop and user population. A configuration without an owner is security debt. Do not remove delegation until integration testing confirms the application does not depend on it.

High-value backends include domain controllers, CIFS services on management servers, LDAP, deployment systems, virtualisation platforms and sensitive databases. Delegation to one SPN may have broader host impact depending on service enforcement, so assess implementation rather than the string alone.

Protected identities

“Account is sensitive and cannot be delegated” should protect administrators and any identity for which impersonation is unacceptable. Protected Users adds restrictions including no NTLM and no delegation, but it can break legacy applications. Roll it out in stages rather than mass-enrolling users during a penetration test.

Administration of delegation relationships belongs behind PAM and just-in-time activation. An application deployer does not need standing permission to modify every computer object.

Safe validation methodology

Phase 1: read and model

Collect configuration using minimum read permissions. Build a table of source principal → delegation type → target SPN/resource → mutable by → protected users. Assign an owner and business rationale to every edge.

Phase 2: analyse impact without changing state

Determine whether front-end control or a target ACL theoretically satisfies S4U conditions. Review segmentation, KDC reachability, service configuration and a test user’s backend rights. A graph is not execution proof, but it can justify a critical rating where active validation would create new production trust.

Phase 3: controlled scenario

If the rules permit it, the client creates isolated resource C, service account B and user U with a harmless record. The team establishes an owner-approved relationship, confirms U’s positive access and another user’s negative access. Do not request administrator-context tickets, access real data or retain configuration after the window.

Phase 4: cleanup and retest

Remove RBCD/KCD, rotate the test principal’s secret, delete test SPNs and verify the former flow fails after relevant artefacts expire or are invalidated. A changed console view does not prove remediation while tickets remain usable until expiry.

Detecting Kerberos delegation abuse

Monitoring should connect directory changes with ticket issuance. Watch modifications to msDS-AllowedToDelegateTo, msDS-AllowedToActOnBehalfOfOtherIdentity, SPNs, owners and ACLs. Event 5136 can record directory-object changes with an appropriate audit policy; 4662 can expose object operations but requires a correct SACL and careful tuning.

Event 4769 records service-ticket requests at domain controllers. Analyse service name, account, client address, encryption, status, flags and baseline timing. One TGS request is not inherently malicious. Valuable correlation combines a recent RBCD change, a first ticket to an unusual SPN, a sensitive client identity and a source with no prior use of that backend.

High-value alerts include:

adding a new principal to an RBCD security descriptor;
classic KCD expanded to LDAP, CIFS or another critical service;
enabling protocol transition or unconstrained delegation;
moving an SPN to another identity or creating one on a user account;
an S4U ticket for an administrator who should be nondelegable;
a relation used by a host other than the inventoried front end.

Microsoft Defender for Identity exposes delegation posture assessments, but its result starts analysis rather than completing it. The SOC needs a runbook containing relation owner, expected front end, last change, host-isolation steps, trust rollback and ticket-lifetime impact.

Hardening: minimise both the relation and the principal

Remove unconstrained delegation from member servers first. Then reduce classic KCD to the smallest SPN set or move to RBCD where resource ownership fits — after securing the resource ACL. Changing the mechanism without reducing write rights merely relocates risk.

Use gMSA for service identities where supported, with minimal local and domain rights. SPNs should be unique, inventoried and attached to the correct account. Delegating front ends need segmentation, EDR, restricted administration, patching and a prohibition on privileged user sign-in.

A Zero Trust security architecture treats every second hop as an explicit flow: defined service, principal, backend, operation and telemetry. “It is inside the network” is not a trust justification.

Kerberos delegation and RBCD checklist

Delegation in the wider assessment

RBCD is rarely isolated. It commonly joins a weak ACL, control of a computer account, overprivileged service identities and unprotected administrators. Include it in a technical Active Directory penetration test and, for broader lateral-movement simulation, an appropriately governed exercise. Our red team versus penetration test guide explains that scope decision.

If you need a delegation map, safe RBCD validation and an application-safe migration plan, contact Breachroad. The report will show the precise trust edge, who can mutate it, impact and detection logic without providing turnkey payloads or touching third-party data.