Kerberos Delegation Attacks: From Unconstrained to RBCD Abuse

What Are Kerberos Delegation Attacks?

Kerberos delegation attacks abuse legitimate Active Directory delegation features that allow a service to access another service on behalf of a user. Delegation exists for real application flows, such as a web tier connecting to a database tier with the user's identity. The security problem starts when the delegation scope is broader than the application actually needs, or when an attacker can modify the delegation relationship.

The three delegation models defenders usually need to review are:

• Unconstrained delegation, where a trusted service can receive delegable Kerberos material and use it beyond a single back-end service.
• Constrained delegation, where the front-end service is limited to specific service principal names listed in Active Directory.
• Resource-Based Constrained Delegation (RBCD), where the target resource controls which principals are allowed to act on behalf of users to that resource.

Those models should not be treated as equivalent risk. Unconstrained delegation is usually the highest priority because compromise of the delegated host can expose reusable delegated credentials. Constrained delegation and RBCD can still be dangerous, especially when the allowed services are too broad or when write permissions let an attacker change the delegation attributes.

How Kerberos Delegation Works

Kerberos delegation extends normal Kerberos service authentication. In a standard Kerberos flow, a user obtains a ticket-granting ticket from the Key Distribution Center and then requests service tickets for specific services. Delegation adds the ability for a service to obtain or use tickets on the user's behalf for another service.

With unconstrained delegation, the account or computer is marked as trusted for delegation. If a user authenticates to that service with delegation enabled, the service can receive delegated Kerberos material. If the host is compromised, the attacker may be able to reuse that delegated access. This is why Microsoft Defender for Identity treats unconstrained Kerberos delegation as a security assessment item: the setting can expose privileged credentials when sensitive users authenticate to delegated services.

Constrained delegation narrows the scope. Instead of allowing delegation to any service, the account is allowed to delegate only to configured services, represented by values such as msDS-AllowedToDelegateTo. Protocol transition changes the risk again because the service can obtain a delegated ticket for a user without the user's original Kerberos authentication to that front-end service when configured to use any authentication protocol.

RBCD reverses part of the administrative model. The resource stores the list of principals allowed to act on behalf of users to that resource in msDS-AllowedToActOnBehalfOfOtherIdentity. That makes RBCD useful for some application scenarios, but it also means write control over a computer object can become a delegation path.

Preconditions That Make Delegation Abuse Work

Delegation settings are not automatically exploitable by themselves. The dangerous cases usually combine multiple conditions:

• a server or service account is configured for unconstrained delegation and is easier to compromise than the users that authenticate to it
• privileged users or domain controllers authenticate to systems that can receive delegated credentials
• computer objects have weak ACLs that allow non-administrative principals to modify delegation-related attributes
• service accounts have broad constrained-delegation targets that no longer match the application requirement
• RBCD entries exist without a documented owner, application dependency, or expiration process
• Domain Controllers expose coercion paths that cause machine-account authentication to systems where delegated material can be captured or reused

The defensive conclusion is practical: a delegation review is not just a list of attributes. It must include host hardening, privileged-account logon paths, object ACLs, and application ownership.

The Attack Chain

A delegation attack normally follows a sequence rather than a single event.

1. The attacker identifies computers or service accounts configured for delegation.
2. The attacker compromises a delegated host, a service account, or an identity with write access to a computer object.
3. The attacker waits for or induces authentication from a valuable account, or modifies RBCD so an attacker-controlled principal can impersonate users to a target resource.
4. The attacker reuses the resulting delegated access to reach a more sensitive service.
5. If the path reaches Domain Controller replication rights, Tier-0 systems, or privileged administrative services, the attack can become domain compromise.

For unconstrained delegation, the most severe cases involve privileged accounts or Domain Controller machine accounts authenticating to a compromised delegated server. For RBCD, the key question is different: who can write the target computer object's delegation attribute, and does the resulting trust relationship match a legitimate application dependency?

Detection

No single Windows event proves a Kerberos delegation attack. Detection comes from correlating delegation inventory, object changes, Kerberos service-ticket activity, logon events, and host telemetry.

Delegation Inventory Signals

Start with configuration data:

• accounts or computers with unconstrained delegation enabled
• accounts with TrustedToAuthForDelegation enabled
• populated msDS-AllowedToDelegateTo values
• populated msDS-AllowedToActOnBehalfOfOtherIdentity values
• privileged accounts not marked as sensitive and therefore still eligible for delegation paths
• weak ACLs on computer objects that allow unexpected principals to write delegation-related attributes

Inventory alone is not enough, but it gives detections the context they need. A 4769 service-ticket event is more meaningful when the service account is known to be configured for risky delegation.

Windows Events to Correlate

Event 5136 requires the right audit policy and SACL coverage. Microsoft documents that it is generated when an Active Directory object is modified, but useful detection depends on retaining the object, attribute, and operation details.

High-Signal Detection Patterns

Prioritize these detections before writing broad anomaly rules:

• a new or changed msDS-AllowedToActOnBehalfOfOtherIdentity value on a computer object
• unconstrained delegation enabled on a non-DC system
• a privileged account authenticating to a system configured for unconstrained delegation
• Domain Controller machine-account logon activity to unexpected member servers
• delegation-related attribute changes made by accounts that do not own the application
• RBCD entries where the acting principal is newly created, rarely used, or unrelated to the target service

The alert should include both sides of the relationship: the account or computer allowed to delegate, and the service or resource being delegated to.

Remediation

Treat unconstrained delegation on non-DC systems as a high-priority finding. If an application still needs delegation, move to a narrower model and prove the target list is correct.

1. Remove Unconstrained Delegation Where Possible

Identify computers and accounts trusted for unconstrained delegation, confirm application ownership, and remove the setting from systems that do not have a current business requirement.

Get-ADComputer -Filter {TrustedForDelegation -eq $true} -Properties TrustedForDelegation |
  Select-Object Name, DistinguishedName, TrustedForDelegation

Do not blindly disable delegation on production application servers without testing. Some legacy applications may depend on delegation for user-to-back-end authentication. The safe remediation path is inventory, owner confirmation, staging, change, and validation.

2. Narrow Constrained Delegation

For services that still need delegation, constrain the allowed target services to the smallest viable set. Review msDS-AllowedToDelegateTo values and remove stale SPNs. If protocol transition is enabled, verify that the application truly needs it and that the service account is protected like a privileged identity.

3. Review and Clean RBCD

For RBCD, review every populated msDS-AllowedToActOnBehalfOfOtherIdentity value. Each entry should map to a documented application dependency. If the entry exists only because troubleshooting required it months ago, remove it. Also review who can write to the target computer object, because write control is often the real vulnerability.

4. Protect Privileged Accounts From Delegation Exposure

Privileged users should not authenticate interactively to lower-trust servers. Use tiered administration, dedicated admin workstations, and logon restrictions so Tier-0 credentials do not land on delegated hosts. For sensitive accounts, review the account settings and operational model that prevent delegation exposure.

5. Reduce Coercion Exposure on Domain Controllers

If the Print Spooler service is not required on Domain Controllers, disabling it removes one well-known machine-account authentication path used in delegation abuse chains. Treat this as one layer, not the only fix. The root issue remains unsafe delegation and credential exposure.

Validation After Remediation

Delegation remediation is not complete until you validate both security and application behavior:

• confirm non-DC systems no longer have unconstrained delegation unless explicitly approved
• confirm remaining constrained-delegation target SPNs match the application design
• confirm RBCD entries have documented owners and no unexpected acting principals
• test the application flow that previously required delegation
• monitor event 5136 for renewed delegation attribute writes after the cleanup
• monitor privileged logons to delegated hosts for at least one change window after remediation
• review computer-object ACLs to ensure attackers cannot rebuild the delegation path

The final validation question is simple: if an attacker compromises the same application server tomorrow, can it still collect or create delegated access to a higher-trust resource?

How EtcSec Detects This

EtcSec audits delegation settings across computers and service accounts in every AD scan.

UNCONSTRAINED_DELEGATION identifies systems and accounts configured for unconstrained delegation.

CONSTRAINED_DELEGATION highlights risky or overly broad constrained-delegation settings.

RBCD_ABUSE surfaces Resource-Based Constrained Delegation relationships that deserve review because they may provide an unexpected impersonation path.

Related Controls

Delegation review belongs next to Kerberoasting: How Attackers Crack Service Account Passwords, ACL Abuse and DCSync: The Silent Paths to Domain Admin, Active Directory Monitoring: Security Event IDs That Matter, GPO Misconfigurations: How Group Policy Becomes an Attack Vector, and Golden Ticket Attack: The Keys to Your Kingdom. In real environments these paths are often chained rather than exploited in isolation.

Primary References

• Microsoft Defender for Identity: security assessment for unconstrained Kerberos delegation
• 5136: A directory service object was modified
• 4738: A user account was changed
• Defender for Identity event collection overview
• Kerberos constrained delegation with Microsoft Entra application proxy