Administrative delegation: Authority at the object, attribute, and extended-rights levels

1. Core mechanism

The decision is made in the DACL in the nTSecurityDescriptor attribute of the Active Directory directory object; LSA/SRM's access check executes the access decision on the domain controller hosting that object. When a principal attempts an action (reset password, write attribute, change group membership) what is evaluated is whether the ACEs in the object's DACL match the requested ACCESS_MASK and the ObjectType GUID if applicable. The cap of this lesson is the scoping mechanics of ACE: general steps for access check are in 05.01, AdminSDHolder writing back this ACL on protected objects is in 05.06, administrative identities are scoped in 05.07.

Interfaces and specifications

• MS-ADTS §5.1.3.2.1 Control Access Rights: control access rights are defined by a GUID and not by an access-mask bit; ACE carries the RIGHT_DS_CONTROL_ACCESS (CR) bit in ACCESS_MASK and the corresponding GUID in the ObjectType field. If ObjectType is empty, ACE includes all control access rights.
• SDDL object ACE (ace_type = OA, ACCESS_ALLOWED_OBJECT_ACE): fields ace_type;ace_flags;rights;object_guid;inherit_object_guid;account_sid (Microsoft ACE strings).
• User-Force-Change-Password extended right (Display: Reset Password), rightsGuid 00299570-246d-11d0-a768-00aa006e0529 (AD Schema).
• Personal-Information property set, rightsGuid 77b5b886-944a-11d1-aebd-0000f80367c1; In ObjectType, a property set GUID encapsulates a group of attributes with a single ACE (AD Schema).
• DS-Replication-Get-Changes-All control access right, rightsGuid 1131f6ad-9c07-11d1-f79f-00c04fc2dcd2 (AD Schema).
• Windows Security channel: 5136 (directory object modified, requires appropriate SACL), 4662 (object operated on); Subcategory Audit Directory Service Changes and Audit Directory Service Access; only on domain controller.

Delegation does not create a new right, it just adds ACE

When the Helpdesk group for user Şeyma is granted "password reset authority", only one thing happens in the background: an ACE is added to the DACL of the relevant objects. In Active Directory, "delegation" is not a separate mechanism; is to overwrite the standard ACL. That's what the Delegation of Control Wizard does.

Three things determine how wide this ACE is: the ACCESS_MASK bits in the rights field, the ObjectType GUID, and the inheritance in ace_flags. The same "allow" ACE covers all control access rights of the object when the ObjectType is empty, and only a single right when it is full.

So, “What did we give to Helpdesk?” The answer to the question is in the text of the ACE, not in the sentence on the wizard's screen. The example we will follow throughout the lesson is three ACEs added to a user object in the outreason.example field; each represents a different level of coverage.

ObjectType GUID is the field that narrows the scope

MS-ADTS §5.1.3.2.1 is strict: a control access right is not represented by its own bit in ACCESS_MASK, unlike standard access rights. Each control access right is identified by a GUID. When granting this right, an ACE removes the RIGHT_DS_CONTROL_ACCESS (CR) bit in ACCESS_MASK and writes the GUID defining that right into the ObjectType field of the ACE.

The same document adds a critical rule: If there is no GUID in the ObjectType field, ACE control is considered to include the right to perform all operations controlled by access rights. So "give CR, leave ObjectType empty" means "give all extended rights". This is the most common way for an ACE thought to be narrow to turn out to be wide.

Property sets establish the same logic for attributes. When the Personal-Information property set GUID (77b5b886-...) is written to the ObjectType of an ACE, RP/WP is given to dozens of attributes connected to that property set with a single ACE. If we wrote the GUID for a single attribute, the scope would be limited to one attribute.

ACE (SDDL): (ace_type;ace_flags;rights;object_guid;inherit_object_guid;account_sid)

(OA;;CR;00299570-246d-11d0-a768-00aa006e0529;;<Helpdesk-SID>)
  -> yalnizca Reset Password extended right

(OA;;CR;;;<Helpdesk-SID>)
  -> ObjectType BOS: TUM control access right'lar (cok daha genis)

(OA;;RPWP;77b5b886-944a-11d1-aebd-0000f80367c1;;<HR-SID>)
  -> Personal-Information property set'indeki attribute grubu (RP+WP)

The controlAccessRight object is not part of the access decision

For each extended right, validated write, and property set, there is a controlAccessRight object in the schema's Extended-Rights container; The rightsGuid and appliesTo attributes of this object help administrative tools name the right.

MS-ADTS makes an important caveat in the same place: these objects are not integral to evaluating access and their presence is not necessary for the correct functioning of the access control mechanism. The appliesTo field tells you "what class" a right applies to, but it is not enforced at the time of access check.

Practical conclusion: just because a right carries a schema annotation such as "actually applies only to user objects" does not prevent that GUID from being written into another object's DACL. The only thing that determines scope is the actual DACL of the actual object; so we verify the delegation by looking at the ACE above the object, not at the document.

Inheritance moves ACE from single object to subtree

Inheritance flags describe how an ACE propagates, but CI/OI names alone do not identify an AD child class. For object-specific ACEs, AD DS treats all object types as containers. Inspect ACE type, inheritance flags, InheritedObjectType (the child-class GUID), the child class and inheritance protection together. A user object is not automatically excluded by the word “container”.

Delegation on one user object and inheritable delegation on an OU have different scopes. An object moved beneath that OU can be affected only if its class and protection state satisfy the ACE’s inheritance conditions. CI alone does not justify saying that every user below the OU is covered.

In our example, the ACE is placed directly on a single user object; There is no inheritance. This is a conscious choice: the aim of the course is to clearly show how the scope is narrowed and expanded in a single object. In real directories, the same right is often distributed by inheritance through an OU.

Three coverage levels in the same example

The user object we are monitoring has three ACEs in its DACL. The first (OA;;CR;00299570-...) only does Reset Password justice: narrow and purpose-specific. The second (OA;;RPWP;77b5b886-...) gives read/write access to the Personal Information attribute group: attribute level. The third (A;;GA;;;DA) gives Generic All: the entire object.

These three ACEs are evaluated in the same access check table. When a principal attempts an operation, the attempted operation's ACCESS_MASK and, if applicable, ObjectType GUID are compared against these ACEs. A Reset Password attempt matches the first ACE, an attempt to type a phone number matches the second ACE, and an attempt to delete the object matches the third ACE.

The model that the reader should carry is this: the power of delegation lies in the trio of "which ACCESS_MASK + which ObjectType + which inheritance" rather than "to whom" it is given. Changing the given name (Helpdesk, HR, Backup) without changing this trio does not change the scope.

State and data flow

1. The administrator grants Reset Password permission to the Helpdesk group for a user object in outreason.example.
2. The tool adds the ACE of the object to the nTSecurityDescriptor (OA;;CR;00299570-246d-11d0-a768-00aa006e0529;;<Helpdesk-SID>).
3. A second delegation gives the HR group the RP/WP for the Personal-Information property set: (OA;;RPWP;77b5b886-...;;<HR-SID>).
4. The third ACE gives Generic All (A;;GA;;;DA) to Domain Admins; This is full object level control.
5. When the Helpdesk member requests to reset the password, access check matches the GUID of the attempted extended right with the ObjectType of the CR ACE in the DACL.
6. When the HR member wants to type their phone number, access check matches the attribute's property set membership with the ACE's ObjectType GUID.
7. DACL change produces record 5136 (and usually 4662) on the domain controller if the object has the appropriate SACL.
8. Each later attempt is reevaluated against the current DACL, token and requested operation. An unchanged ACE can yield a different result when the token, requested right or other applicable conditions change.

2. Exploitation

Broken trust assumption

The assumption that is broken is: "I delegated narrow authority, so its effect is narrow." In reality, the effect of an ACE depends on the ACCESS_MASK + ObjectType + inheritance triple, not the name of the given job. What appears to be a “just password reset” right is enough to assume the identity of the target account; A CR ACE whose ObjectType is left blank opens all control access rights instead of a single right.

Technical prerequisites

• The attacker has an ACE written to him (or a principal he controls) in the DACL of the target object. This ACE may be a side effect of a legitimate delegation.
• In the Reset Password scenario: the target account is not additionally protected by smart-card-required or any other blocking control; Otherwise, the new password alone will not be enough to log in.
• Sensitive replication permissions must be assessed in the requesting security context. Independent callers’ permissions do not combine into a domain-wide authorization. Audit effective permissions, not only direct assignments to one trustee SID.
• In a group hijacking scenario: WriteProperty (WP) is given to the member attribute of the target group or Generic Write/Generic All is given to the object.
• The target object is not under AdminSDHolder protection; on protected objects SDProp rolls back this ACE as described in 05.06.

Exploitation mechanism

The mechanism is not a weakness, but a misreading of the scope of delegation. The Reset Password right allows assigning a new password without knowing the target user's current password (this is the definition of User-Force-Change-Password). The principal who assigned the new password can now authenticate with that account; so “password reset” is effectively account takeover. The same logic extends further: an empty CR ACE with ObjectType extends all extended rights; The possibility of adding the member attribute given to a group to the group itself; DS-Replication-Get-Changes-All on domain NC enables "secret domain data" (including password hashes) to be retrieved by replication (DCSync). No rules are broken; What is being violated is the assumption that "this right seems harmless".

Why Reset Password is account takeover

The definition of User-Force-Change-Password in AD Schema is clear: it allows resetting the password on a user account. This is different from "change password", which requires knowing the old password; "force change" does not ask for the old password.

If a principal has this right, he can set the target's password to any value he wants, then log in with that password. The result is to take over all access of the target user. The sentence "Helpdesk only resets the password" technically means "Helpdesk can log in to every account within the scope".

That's why Reset Password delegation should never be given to Tier-0 accounts. It may be legitimate for Helpdesk to reset passwords for casual users; Extending the same right to an OU that includes Domain Admins members with inheritance is a separate and much more serious decision.

Empty ObjectType and replication rights

The most insidious extension is leaving ObjectType empty. The spelling (OA;;CR;;;<SID>) does not give a single right, but all control access rights. The delegator thinks "I gave CR"; It actually opens the entire extended right surface of the target.

Replication permissions on the domain naming context expose highly sensitive data and deserve Tier-0 review. Authorization evaluates the caller’s effective security context; “same principal” must not be read as “every relevant ACE must name the same trustee SID”. Group membership can contribute to that context, while unrelated callers’ tokens remain separate.

This right is often granted to a legitimate component (directory synchronization tool, some monitoring solutions). The danger is not to inventory which principal holds the right. Every principal with these two rights on Domain NC should be treated as Tier-0.

Where is it ineffective?

If the ACE is not in the actual DACL of the target object, nothing happens; It does not grant access to schema notes or wizard tags. Likewise, if the ObjectType carries a full and narrow GUID, the scope is really limited to that right.

AdminSDHolder/SDProp is enabled for protected accounts: ACEs manually added to protected objects are written back according to the AdminSDHolder template at the latest in the next SDProp cycle (05.06). Therefore, direct ACL changes made to groups such as Domain Admins may not be permanent.

The effect of Reset Password is limited by additional controls of the target account: smart card requirement, login restrictions or disabled account may prevent the reset password from working. Saying "there is a right" does not always mean "the result is guaranteed"; Access, scope and obstructive conditions are evaluated separately.

3. Defense & Detection

Telemetry scope

• The Audit Directory Service Changes subcategory produces records 5136, 5137, 5138, 5139, and 5141. Relevant for this lesson is 5136, which indicates object change.
• For a 5136 to be generated, the SACL of the changed object must contain the appropriate "Write" auditing entry. If there is no SACL, 5136 will not occur even if the DACL changes; This is the most frequently overlooked prerequisite for delegation monitoring.
• Event 4662 requires Audit Directory Service Access and an object SACL matching the audited operation. It records an operation and relevant property/right GUIDs; it does not establish a complete before/after descriptor diff. Event 5136 has separate prerequisites: Audit Directory Service Changes and appropriate attribute Write auditing.
• Both events occur only on the domain controller; It is a directory change record, not a member server event.
• For a DACL change, 5136 typically produces two records: first Value Deleted and then Value Added for nTSecurityDescriptor. The new value appears in the AttributeValue field as raw SDDL text and must be further parsed to be read.

Events and relevant fields

• 5136 / AttributeLDAPDisplayName: changed attribute. The value looked for in delegation monitoring is nTSecurityDescriptor.
• 5136 / AttributeValue: new value. If nTSecurityDescriptor has changed, this field is an SDDL text; It is only possible to see which ACE has been added to which trustee when this text is parsed.
• 5136 / OperationType: %%14674 Value Added, %%14675 Value Deleted. An ACL change usually produces both; comparison gives old/new DACL.
• 5136 / ObjectDN and ObjectClass: DN and class of the modified object. It is used to filter the Tier-0 scope (Domain Admins members, AdminSDHolder, domain root).
• 5136 / SubjectUserName and SubjectUserSid: principal who made the change. It is compared with the expected delegation tools/accounts.
• 4662 / Properties: attribute or control access right GUIDs used in the operation. For example, the appearance of the DS-Replication-Get-Changes-All GUID (1131f6ad-...) at 4662 is a sign of replication-based access.
• 4662 / AccessMask and ObjectServer: desired access and target. The 4662 alone is high volume; The property becomes too large to be analyzed without the GUID filter.

Reading 5136 requires parsing the descriptor

5136 tells you that an object has changed and which attribute has been written. If the changed attribute is nTSecurityDescriptor, the event itself does no more than say "DACL changed"; Which right is added to which trustee is stated in the SDDL text in AttributeValue.

That's why 5136 alarm alone is not enough. It is necessary to parse the new SDDL and extract the added ACEs, then compare them with the old value (Value Deleted record). Reading an SDDL at the CR/RP/WP/GA and ObjectType GUID level, as in the tutorial artifact, is exactly this step.

OpCorrelationID is used for correlation: Value Deleted and Value Added records of the same write are mapped to this ID. Thus, "what was, what happened" is seen as a single change.

Which record answers which question?

5136 "has the directory object changed and which attribute?" the question; 4662 "Which operation was performed on the object, with which property/right GUID?" answers the question. Both depend on the object SACL and occur only in DC.

To capture a replication-based access (DCSync), it is more direct to look for the DS-Replication-Get-Changes / DS-Replication-Get-Changes-All GUIDs on the 4662; because this indicates the moment the right is exercised, not the moment the ACL changes.

In the context of this lesson, 5136 represents the moment when the delegation was established, and 4662 represents the moment when a given right was exercised. Keeping the two as separate points of observation preserves the distinction between “authority granted” and “authority exercised.”

Detection logic · Sigma

title: Dizin nesnesi security descriptor'i degistirildi (delegasyon izi)
id: 0a7c9d31-3d2e-4d0a-8f7a-2b6d1f4c5e90
status: experimental
description: >
  5136 kaydinda nTSecurityDescriptor attribute'unun degistigi olaylari arar. Bu bir
  delegasyon/ACL degisikligi izidir; tek basina kotu niyet kaniti degildir. AttributeValue
  ham SDDL'dir ve hangi trustee/hak eklendigi backend'de ayristirilmalidir.
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID: 5136
    AttributeLDAPDisplayName: 'nTSecurityDescriptor'
    OperationType: '%%14674'
  condition: selection
fields:
  - ObjectDN
  - ObjectClass
  - SubjectUserName
  - AttributeValue
falsepositives:
  - Delegation of Control Wizard ve otomatik provisioning araclari
  - Grup/OU yeniden yapilandirmasi sirasinda toplu ACL guncellemeleri
level: medium

Query assumptions

• 5136 is generated only if there is a "Write" auditing entry in the SACL of the changed object. If this SACL is not already configured on Tier-0 objects, the rule sees nothing.
• The AttributeValue field is the raw SDDL text; SDDL parsing is required in the backend to see which ACE is added to which trustee. The rule only signals "descriptor changed".
• The OperationType '%%14674' (Value Added) filter targets the newly added value; Records '%%14675' must be mapped to see the old value as well.
• Field names are EventData names in the Windows Security channel; For a normalizing backend, field mapping must be done separately.
• This rule has not been run on a real SIEM; field names and event semantics are based on the primary source and should be verified against the schema of the version used.

False positives

• Legitimate delegation: Delegation of Control Wizard or provisioning automation regularly writes nTSecurityDescriptor.
• Bulk ACL changes during OU/group restructuring produce the same record.
• Backup/restore and migration tools can rewrite descriptors.
• Negative example: When ACE is added to an OU with inheritance, the real change occurs in the OU; A separate 5136 may not appear in the user object. It is necessary to set the scope to include OU objects.

Hardening

• First inventory: Which principal is authorized with which ACCESS_MASK + ObjectType on which object? "Cleaning" without this map would break the legitimate delegation. Each principal carrying DS-Replication-Get-Changes-All on Domain NC is also listed.
• Delegate to ad hoc groups, not individual accounts; Keep the scope at the OU boundary and with narrow ObjectType GUIDs. Using ObjectType empty CR ACEs without conscious justification.
• Exclude Tier-0 objects (Domain Admins members, AdminSDHolder, domain root) from delegation; Verify that AdminSDHolder/SDProp protection is enabled on these objects (05.06).
• Add "Write" auditing to the SACL of Tier-0 objects for monitoring; Without SACL the 5136 will not be produced. This step is a prerequisite for delegation control.
• Verification step: add a test delegation, see the nTSecurityDescriptor change in record 5136 and the new ACE in AttributeValue appear, then parse the SDDL and see the expected trustee/rights match.
• Set up periodic ACL review: review the actual DACL of objects based on raw ACEs, not the schema/tag assumption; Do not accumulate deviations until the next inspection.

Read the examples

O:DAG:DAD:AI(OA;;CR;00299570-246d-11d0-a768-00aa006e0529;;S-1-5-21-1470163944-2039885437-3358247602-5101)(OA;;RPWP;77b5b886-944a-11d1-aebd-0000f80367c1;;S-1-5-21-1470163944-2039885437-3358247602-5102)(A;;GA;;;DA)

Two reality checks

Assumption: Checking the "Reset user passwords" box in the Delegation of Control Wizard is a harmless helpdesk privilege.

In fact: Reset Password (User-Force-Change-Password, rightsGuid 00299570-246d-11d0-a768-00aa006e0529) allows assigning a new password without knowing the old password; this is being able to log in with the target account, effectively taking over the account. It may be reasonable for casual users, but it is a means of privilege escalation when given with inheritance to an OU containing Tier-0 accounts. "It only resets the password" is the same as "it can access every account in scope".

Assumption: If I write CR (Control Access) to an ACE, I only grant a certain extended right.

In fact: According to MS-ADTS §5.1.3.2.1, it is the ObjectType field that determines the scope: If there is a GUID in the ObjectType with CR, only that right is granted; If ObjectType is empty, ACE control covers all operations controlled by access rights. That is, (OA;;CR;;;SID) opens not a single right, but the entire extended right surface of the target. Scope is determined by the presence of the GUID in the text of the ACE, not the sentence on the tool's label.

Sources

• MS-ADTS · Control Access Rights
  §5.1.3.2.1: a control access right is identified by a GUID; the ACE carries the RIGHT_DS_CONTROL_ACCESS (CR) bit in ACCESS_MASK and the right's GUID in the ObjectType field; if ObjectType is empty, the ACE covers all control access rights; controlAccessRight objects (rightsGuid, appliesTo) are not an intrinsic part of access evaluation.
• Microsoft · User-Force-Change-Password extended right (AD Schema)
  CN User-Force-Change-Password, Display-Name Reset Password, Rights-GUID 00299570-246d-11d0-a768-00aa006e0529; "Permits resetting a password on a user account."
• Microsoft · Personal-Information property set (AD Schema)
  CN Personal-Information, Rights-GUID 77b5b886-944a-11d1-aebd-0000f80367c1; attribute list for property set members (telephoneNumber, streetAddress, etc.).
• Microsoft · DS-Replication-Get-Changes-All extended right (AD Schema)
  CN DS-Replication-Get-Changes-All, Rights-GUID 1131f6ad-9c07-11d1-f79f-00c04fc2dcd2; "Control access right that allows the replication of secret domain data."
• Microsoft · ACE strings (SDDL)
  SDDL ACE field order ace_type;ace_flags;rights;object_guid;inherit_object_guid;account_sid; OA = ACCESS_ALLOWED_OBJECT_ACE_TYPE; CR/RP/WP/GA rights abbreviations.
• Microsoft · 5136(S) A directory service object was modified
  Subcategory Audit Directory Service Changes; SACL Write auditing prerequisite; EventData fields AttributeLDAPDisplayName, AttributeValue, OperationType (%%14674/%%14675), ObjectDN, ObjectClass, SubjectUserName.
• Microsoft · ACE Inheritance Rules
  Object-specific ACE inheritance; DS treats all object types as containers; InheritedObjectType class scope.
• Microsoft · Setting Rights to Specific Types of Objects
  Class-targeted inheritance and InheritedObjectType.
• Microsoft · 4662: An operation was performed on an object
  Audit Directory Service Access, matching object SACL, Properties/AccessMask; operation evidence, not complete descriptor diff.
• Microsoft · Audit Directory Service Access
  Audit subcategory and 4662 event scope.
• Microsoft · Access Tokens
  Caller context includes user and group SIDs; separate tokens do not pool rights.