Kerberos delegation: The purpose of unconstrained, constrained, RBCD, and S4U

1. Core mechanism

The delegation decision lives in three places: the KDC (domain controller) that issues the ticket, the AD attributes that define the authority (userAccountControl bits, msDS-AllowedToDelegateTo, msDS-AllowedToActOnBehalfOfOtherIdentity), and the TGS extensions S4U2self and S4U2proxy that execute the flow. The limit of this lesson is the question 'where does the authorization stop and what does each model change?': PAC/authorization data detail is at 06.05, SPN ownership is at 06.03, ticket life and error states are at 06.07.

Interfaces and specifications

• RFC 4120 §2.6: forwardable ticket flags; The delegated identity is carried with a forwarded TGT.
• RFC 4120 §2.8: ok-as-delegate ticket flag; KDC sets this flag when the service account is marked as trusted for unconstrained delegation and tells the client 'delegating credentials to this service is appropriate according to the realm policy'.
• MS-SFU §1.3: TGS extensions S4U2self (protocol transition) and S4U2proxy (constrained delegation); They are two separate steps.
• userAccountControl bits: TRUSTED_FOR_DELEGATION 0x80000 (unconstrained), TRUSTED_TO_AUTH_FOR_DELEGATION 0x1000000 (protocol transition), NOT_DELEGATED 0x100000 (account cannot be delegated).
• msDS-AllowedToDelegateTo: allowed target SPN list that resides in the front-end account in classic constrained delegation.
• msDS-AllowedToActOnBehalfOfOtherIdentity: Security descriptor (String(NT-Sec-Desc), 2.5.5.15), which resides in the back-end account in RBCD and carries the allowed front-end SIDs.
• Windows Security 4769 · Transited Services field: Shows through which service the delegation is made in the ticket issued with S4U2proxy; only on domain controller.

What does delegation solve: the double-hop problem

When tunahan accesses an application on WEB01 with Kerberos, the client presents a service ticket for WEB01. This ticket proves tunahan's identity to WEB01. If WEB01 wants to access the database on DB01 on tunahan's behalf, it does not have a ticket for DB01 unless a delegation flow provides one.

Without delegation, WEB01 can access DB01 under its own identity but cannot carry tunahan's identity to that second service. Delegation is the protocol-approved way to carry the user identity. The difference is which principal authorizes that transfer and how narrowly it is scoped.

The three delegation models place that decision in different locations. S4U2self and S4U2proxy are protocol extensions and flows used with constrained delegation and RBCD; they are not a fourth delegation model. To understand a configuration, ask which object stores the permission that allows the second hop.

Unconstrained: identity is carried unrestricted

TRUSTED_FOR_DELEGATION expresses realm trust in a service as a recipient of delegated credentials. OK-AS-DELEGATE conveys that policy information to the client, which may use or ignore it. The flag does not establish that a TGT was actually forwarded (RFC4120 §2.8).

If the client actually delegates a forwarded TGT, the front-end can use that credential to request tickets for further services as the user. This model is not restricted by a classic constrained SPN list. Target authentication and resource authorization requirements still apply.

Separate account configuration, actual client delegation behavior and the target outcome. Observing one flag proves neither of the latter two.

Constrained delegation: target SPN list and S4U flow

Classic constrained delegation stores its target SPN list in msDS-AllowedToDelegateTo on the front-end account. The KDC compares the requested target SPN with that list. Confusing it with the back-end RBCD descriptor leads to inspecting the wrong policy owner.

With protocol transition, the front-end application must first adequately authenticate the user through its own authentication method. S4U2self can provide user authorization data without obtaining the user’s Kerberos credential; ticket issuance does not establish that the application actually authenticated that user. S4U2proxy concerns delegation to a second service (MS-SFU §5.1).

The target list bounds which services may be within delegation scope. User delegation restrictions, ticket conditions and target resource permissions remain separate; a configured list does not establish that every gate passed.

RBCD: source decides

RBCD evaluates a security descriptor stored in msDS-AllowedToActOnBehalfOfOtherIdentity on the back-end account. In this example WEB01 is the front-end and DB01 is the back-end; DB01 owns this policy value.

The KDC performs an access check on the back-end descriptor with the front-end service’s authorization context. Trustee SIDs, applicable group SIDs, ACE type, requested rights and ACE order are parts of general DACL semantics. Finding a SID in one allow ACE does not establish a successful overall access check. This lesson does not calculate an RBCD-specific exact desired-access mask.

Authority to change configuration and the KDC’s evaluation of that configuration are separate decisions. The descriptor owner does not identify who made a change. Evaluate the management interface, effective permissions and observed read-back when reviewing the target account’s administrative boundary.

msDS-AllowedToActOnBehalfOfOtherIdentity  (String(NT-Sec-Desc), OID 2.5.5.15)
--------------------------------------------------------------------------------
O:BA                       owner: Built-in Administrators
D:(A;;CCDC...WDWO;;;SID)   DACL: single ACCESS_ALLOWED (A) ACE
        type   = A         ACCESS_ALLOWED
        rights = CCDC..WO   broad object rights set written by AD tools
        trustee= S-1-5-...  SID of the ALLOWED front-end principal
--------------------------------------------------------------------------------
KDC S4U2proxy check: 'is the requesting front-end SID allowed in this descriptor?'
The decision is not 'who made the change', but 'is the SID in an allow ACE?'

One question across three delegation models: which object holds the decision?

Unconstrained realm trust is configured on the front-end account; classic constrained target lists belong to the front-end, and RBCD descriptors to the back-end. The KDC evaluates these inputs; client behavior, application authentication and resource authorization remain independent.

Therefore, evaluating delegation in an environment does not mean 'is delegation open?' It is to map 'which object holds the authority for each target and who can write to that object'. In the tunahan → WEB01 → DB01 example we followed throughout the lesson, this map goes down to the ACL of object DB01.

State and data flow

1. Evaluate the front-end application’s user authentication. This identity proof is distinct from S4U authorization data.
2. Identify the WEB01 → DB01 requirement. A user’s access to WEB01 does not authorize the second service.
3. Compare policy locations: classic constrained list on WEB01, RBCD descriptor on DB01; unconstrained includes an independent client decision.
4. Follow the KDC policy decision separately. Allow/deny in this example is a predefined observation; no actual access check or ticket request is executed.
5. Policy eligibility does not replace user restrictions or ticket conditions. If application authentication is unobserved, user identity remains unverified.
6. Read audit evidence within its scope:5136 configuration changes;4769 may carry constrained-delegation context. Empty Transited Services does not establish absence of delegation.
7. Verify resource authorization separately on DB01. A delegation decision does not grant resource access.

2. Exploitation

Broken trust assumption

It is unsafe to assume that only people with a formal administrator role can affect delegation configuration. RBCD policy resides in the back-end account’s descriptor, so authority to administer that configuration matters. Configuration authority, an actually accepted change, the KDC delegation decision and target-resource authorization are distinct.

Technical prerequisites

• Account-administration permissions affecting delegation configuration. DACL administration, attribute updates and KDC policy evaluation are reviewed separately.
• Correctly identified front-end account and registered SPN owner; account-creation authority is not target-policy administration authority.
• Evidence of how the application authenticated the user.
• Separate evaluation of user delegation restrictions and target-resource permissions.

Exploitation mechanism

The risk is inappropriate administrative control over the trust that lets a service represent user identity. Front-end policy and back-end descriptors belong to separate accounts; observing a change on one does not explain every delegation model. How the application authenticates the user and which rights the target grants remain independent boundaries.

Separate configuration authority from the delegation decision

Authority to manage an account DACL and authority to update a delegation attribute are distinct operations. Evaluate object/attribute scope, the management interface and observed effective results separately. This lesson runs no write command or ACL change.

The RBCD attribute msDS-AllowedToActOnBehalfOfOtherIdentity contains a security descriptor. Microsoft’s schema documentation defines it with systemOnly=TRUE; MS-ADTS separately describes general Modify constraints for system-only attributes. The Set-ADComputer documentation also states that PrincipalsAllowedToDelegateToAccount configures this attribute. These statements do not establish that seeing GenericWrite guarantees success for every LDAP operation. Review configuration authority, an accepted change and the KDC’s later delegation decision using separate evidence. A right name in an ACE does not establish these three outcomes.

Evaluate computer-account administration separately

MachineAccountQuota and delegated create authority are distinct administrative paths. A numeric quota alone does not prove that every user can create an account in every OU. Creating a principal does not grant permission to change delegation configuration on a target account.

Inventory join workflows, explicit create delegation and critical service-account administration separately. Changing a quota does not remove existing principals or other delegated create paths.

Where does it stop, how is it limited?

If the identity to be impersonated is marked NOT_DELEGATED or is in the Protected Users group, the KDC rejects the delegation; This is a real limit for critical accounts.

The effect is limited to the target resource: installing RBCD on DB01 gives what the identity impersonated on DB01 can do; This alone does not mean 'the domain has been taken over'. Scope is evaluated based on whether the target is Tier 0 and the rights of the impersonated identity.

3. Defense & Detection

Telemetry scope

• Audit Directory Service Changes subcategory (DC only, requires SACL on relevant object/attribute): msDS-AllowedToActOnBehalfOfOtherIdentity change produces 5136.
• Audit Computer Account Management: creating a new computer account produces 4741, changing it produces 4742; The account created with MachineAccountQuota appears as 4741.
• Audit Kerberos Service Ticket Operations provides4769 observations on DCs. Transited Services concerns constrained-delegation context; an empty or “-” value does not exclude unconstrained delegation.
• If SACL is not configured, 5136 is not generated at all; The assumption that 'every attribute change is automatically logged' is wrong. The observation point for this lesson is the SACL setup first.
• Turning on the TRUSTED_FOR_DELEGATION or TRUSTED_TO_AUTH_FOR_DELEGATION bits in userAccountControl appears as an account change (4738 on user, 4742 on computer).

Events and relevant fields

• 5136 / AttributeLDAPDisplayName: name of the changed attribute; msDS-AllowedToActOnBehalfOfOtherIdentity for RBCD trace.
• 5136 / AttributeValue: SDDL format of the new security descriptor written; The authorized front-end SID is read from here.
• 5136 / OperationType: %%14674 Value Added, %%14675 Value Deleted. It distinguishes whether it is an insertion or a deletion.
• 5136 / SubjectUserSid and SubjectUserName: principal who made the change; An unexpected account writing to a Tier 0 object is a signal.
• 5136 / ObjectDN and ObjectClass: which object (e.g. computer) is targeted.
• 4769 / Transited Services is the display label; the raw XML Data name is TransmittedServices. It can help investigate S4U2proxy context. An empty or “-” value alone does not prove absence of delegation; verify Windows version, auditing and collector mappings.

See change first: No 5136 without SACL

The 5136 record is only generated if there is a SACL on the relevant object or attribute and Audit Directory Service Changes is on. If there is no SACL, the change that establishes RBCD will not appear in telemetry at all.

This record occurs only on the domain controller and has a high volume. If the collection scope and filter are not planned in advance, a critical delegation change will be lost in the noise.

Two different tracks: installation and use are not the same thing

5136 records an attribute change. Transited Services in4769 concerns SPNs requested with constrained delegation; the raw field is TransmittedServices. Configuration change, ticket request and target resource outcomes are separate evidence. An empty list establishes only that no list is observed in this record, not absence of delegation.

The correct reading is to separate the questions 'who wrote' (5136 SubjectUserSid) and 'when and under what username' (4769) and evaluate them on the basis of normal behavior.

Detection logic · Sigma

title: RBCD attribute'una yazma (msDS-AllowedToActOnBehalfOfOtherIdentity)
id: 8a1e2c74-4b19-4d0a-9f22-3d7c1a0e5b44
status: experimental
description: >
  Directory Service Changes kaydinda (5136) msDS-AllowedToActOnBehalfOfOtherIdentity
  attribute'unun degistirilmesini arar. Tek basina kanit degildir; mesru RBCD kurulumu
  da ayni kaydi uretir. SubjectUserSid ve ObjectDN ile normal davranis temeline gore
  degerlendirilmelidir.
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID: 5136
    AttributeLDAPDisplayName: 'msDS-AllowedToActOnBehalfOfOtherIdentity'
  condition: selection
fields:
  - SubjectUserSid
  - SubjectUserName
  - ObjectDN
  - AttributeValue
  - OperationType
falsepositives:
  - Yoneticiler veya otomasyon tarafindan yapilan mesru RBCD kurulumu
  - Gecis/migration araclarinin toplu delegation ayari
level: medium

Query assumptions

• The rule assumes that SACL is configured on the relevant object/attribute and Audit Directory Service Changes is turned on; otherwise the 5136 would never be produced.
• 5136 occurs only on the domain controller; This record is not searched on the source host.
• Field names are EventData names in the Windows Security channel; If a normalizing backend is used, field mapping should be done separately.
• The SDDL in AttributeValue matches without being parsed; Additional parsing is required to extract the permitted SID. This rule was not run on a real SIEM in this session.

False positives

• Conscious RBCD setup by the manager or an automation produces the same record; This is normal.
• Vehicles that set up mass delegation in a service transition trigger the pattern.
• Negative example: if the attribute is first accessed with WriteDACL and then modified, SACL only captures the change event; DACL manipulation requires separate monitoring. The rule is a scope limit, not a proof.

Hardening

• Mark critical accounts as 'Account is sensitive and cannot be delegated' (NOT_DELEGATED) and move them to the Protected Users group; This makes impersonation rejected at the ticket level.
• Review MachineAccountQuota and explicit create delegations against join requirements. A zero quota removes neither existing principals nor other delegated create paths; target service-account administration permissions need separate restriction.
• Limit DACL and delegation-configuration administration on critical accounts with least privilege. Do not infer effective writes from right names; separately verify the supported management interface and actual permission boundaries.
• Set SACL for delegation attributes and collect 5136; The change must first be visible. Due to the high volume, collection and storage are planned in advance.
• Inventory services using unconstrained delegation and client credential forwarding. Assess more constrained delegation models against application needs; the flag alone is not evidence of TGT forwarding.
• Read back configuration after a change and compare the expected descriptor and administrative scope. Check change records under appropriate audit/SACL/collection. A SID list alone is not an effective KDC or resource decision.

Read the examples

O:BAD:(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;S-1-5-21-1109110911-2202220222-3303330333-1140)

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Microsoft-Windows-Security-Auditing" Guid="{54849625-5478-4994-a5ba-3e3b0328c30d}" />
    <EventID>5136</EventID>
    <Version>0</Version>
    <Level>0</Level>
    <Task>14081</Task>
    <Opcode>0</Opcode>
    <Keywords>0x8020000000000000</Keywords>
    <TimeCreated SystemTime="2026-09-29T05:58:11.9930000Z" />
    <EventRecordID>44120</EventRecordID>
    <Correlation ActivityID="{5b2d9a41-77aa-4c19-9d0e-2b7c6a1f3e77}" />
    <Execution ProcessID="712" ThreadID="1332" />
    <Channel>Security</Channel>
    <Computer>DC01.iyelabs.example</Computer>
    <Security />
  </System>
  <EventData>
    <Data Name="OpCorrelationID">{9f14c7a2-0e33-4a51-8b6d-7c0d2a44e109}</Data>
    <Data Name="AppCorrelationID">-</Data>
    <Data Name="SubjectUserSid">S-1-5-21-1109110911-2202220222-3303330333-1105</Data>
    <Data Name="SubjectUserName">birkan</Data>
    <Data Name="SubjectDomainName">IYELABS</Data>
    <Data Name="SubjectLogonId">0x3f9c1</Data>
    <Data Name="DSName">iyelabs.example</Data>
    <Data Name="DSType">%%14676</Data>
    <Data Name="ObjectDN">CN=DB01,CN=Computers,DC=iyelabs,DC=example</Data>
    <Data Name="ObjectGUID">{7c2a1e90-4d5b-4a37-9be2-71c4ad0f3e12}</Data>
    <Data Name="ObjectClass">computer</Data>
    <Data Name="AttributeLDAPDisplayName">msDS-AllowedToActOnBehalfOfOtherIdentity</Data>
    <Data Name="AttributeSyntaxOID">2.5.5.15</Data>
    <Data Name="AttributeValue">O:BAD:(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;S-1-5-21-1109110911-2202220222-3303330333-1140)</Data>
    <Data Name="OperationType">%%14674</Data>
  </EventData>
</Event>

Two reality checks

Assumption: In RBCD, only the domain admin makes the delegation decision.

In fact: Administrative authority over RBCD configuration cannot be reduced to a job title. Policy resides on the back-end account; who can affect it depends on that account’s management boundaries. The KDC separately checks the descriptor with the front-end authorization context. A trustee SID alone proves neither write authority nor the overall KDC decision.

Assumption: If constrained delegation is set up, the service can only go to the listed SPN, so it is secure.

In fact: The target SPN list is an important boundary: the KDC compares the requested SPN with the front-end list. Documented sPNMappings can define equivalence for particular SPN types; that is not a rule accepting every service class on the same host. Evaluate requested SPN, registered ownership and relevant mapping together. User delegation restrictions and target resource rights remain independent.

Sources

• RFC 4120 · The Kerberos Network Authentication Service (V5)
  §2.6 Renewable/forwardable ticket flags; §2.8 OK as Delegate flag (KDC trust marking for unconstrained delegation and the client's decision to send a forwarded TGT).
• Microsoft Open Specifications · [MS-SFU] Kerberos Protocol Extensions: Service for User and Constrained Delegation Protocol
  §1.3 Overview: S4U2self (protocol transition) and S4U2proxy (constrained/resource-based delegation); in RBCD, the KDC's front-end SID access check against msDS-AllowedToActOnBehalfOfOtherIdentity.
• Microsoft · UserAccountControl property flags
  TRUSTED_FOR_DELEGATION 0x80000, TRUSTED_TO_AUTH_FOR_DELEGATION 0x1000000, NOT_DELEGATED 0x100000 bit values and meanings.
• Microsoft · ms-DS-Allowed-To-Act-On-Behalf-Of-Other-Identity attribute
  Attribute definition: security descriptor that defines whom the resource trusts in RBCD; evaluated with an access check; syntax String(NT-Sec-Desc) 2.5.5.15.
• Microsoft · ACE strings
  ACE type A (ACCESS_ALLOWED) and object rights tokens (CC, DC, LC, SW, RP, WP, DT, LO, CR, SD, RC, WD, WO) SDDL syntax.
• Microsoft · 5136(S) A directory service object was modified
  Event XML and Field Descriptions; AttributeLDAPDisplayName, AttributeValue, AttributeSyntaxOID, OperationType %%14674/%%14675, SubjectUserSid; DC only and SACL condition.
• Microsoft · Default workstation numbers a user can join to the domain (ms-DS-MachineAccountQuota)
  ms-DS-MachineAccountQuota default 10; every authenticated user can create up to 10 computer accounts.
• Microsoft Learn · Protected Users security group
  Domain controller protections: Protected User accounts cannot delegate with unconstrained or constrained delegation; applicability requires supported host/domain conditions.
• Microsoft Learn · Event 4769
  Display label Transited Services; raw XML EventData/TransmittedServices. Backend mappings require separate validation.
• Microsoft Open Specifications · msDS-AllowedToDelegateTo
  Attribute definition and multivalued SPN scope; not the RBCD attribute.
• MS-SFU Security Considerations
  §5.1 application authentication before S4U2self
• MS-SFU front-end policy
  §3.2.5.2.1 requested SPN / Service1 account
• MS-SFU back-end descriptor
  §3.2.5.2.3 authorization context / descriptor access check
• Microsoft SPN-Mappings
  Documented type equivalence; no blanket same-host class rule
• Microsoft · MS-ADA2 RBCD attribute
  §2.218; systemOnly TRUE; descriptor semantics; Windows Server 2012 first implementation
• Microsoft · MS-ADTS Modify constraints
  §3.1.1.5.3.2 system-only constraint and listed exceptions; no RBCD exception stated in this passage
• Microsoft · Set-ADComputer
  PrincipalsAllowedToDelegateToAccount parameter documentation; no inference of exact protocol or caller ACL check