User, computer, and group objects: The logic of attributes and schema

1. Core mechanism

The schema lives in the forest-wide Schema naming context (CN=Schema,CN=Configuration,...). Class definitions are classSchema objects and attribute definitions are attributeSchema objects: they are objects in the directory data store, not compiled code. This lesson examines those definitions and their relationship to an instance. Replication metadata, Global Catalog selection, and schema-extension procedure are outside this lesson.

Interfaces and specifications

• classSchema: the definition of an object type, including objectClassCategory, subClassOf, and mustContain/mayContain.
• attributeSchema: the definition of one attribute, including lDAPDisplayName, attributeSyntax/oMSyntax, isSingleValued, and schemaIDGUID.
• objectClass: a multi-valued instance attribute listing the structural/abstract superclass chain and any dynamically attached auxiliary classes.
• objectCategory: a single-valued attribute holding the distinguished name of the class or a superclass, used for searches.
• mustContain / mayContain (and systemMustContain / systemMayContain): the class's required and optional attribute sets.
• attributeSyntax + oMSyntax: the value type (Unicode string, integer, SID, DN, and so on) and comparison rule.
• schemaIDGUID: the stable identifier used to refer to an attribute or class in security descriptors.

The schema is a set of objects, not a fixed table

When you create a user object, the directory answers ‘what is a user and which fields may it contain?’ from classSchema in the Schema naming context, not from hard-coded application logic. The schema is itself made of directory objects, which is why it can be queried and, with appropriate rights, extended.

An attributeSchema object defines an attribute's identity and behavior: lDAPDisplayName is used by LDAP clients, syntax defines the value type, and schemaIDGUID identifies the attribute in security descriptors. department and servicePrincipalName are therefore defined attributes, not arbitrary text.

The structural type is fixed; objectCategory makes lookup practical

An instance's objectClass attribute is multi-valued and includes its structural/abstract superclass chain. A user object includes top, person, organizationalPerson, and user in that chain. Statically linked auxiliary classes are not listed in the instance value; on Windows Server 2003 and later, a dynamic auxiliary class can be added to or removed from one object and appears in objectClass. This does not change the object's structural class: structuralObjectClass identifies that class and its inheritance chain.

objectCategory is single-valued and indexed, and is initialized from the class's defaultObjectCategory. This helps searching but does not select the intended object type by itself. (objectCategory=person) can match users and contacts, while (objectClass=user) can match users and derived computer objects. Combine both predicates to select user objects: (&(objectClass=user)(objectCategory=person)). Base and scope separately determine the domain or OU being searched.

Required and optional attributes come from the class

mustContain/systemMustContain define required attributes, while mayContain/systemMayContain define optional attributes. An instance can use attributes inherited through its subClassOf chain and those supplied by auxiliary classes.

You cannot write any arbitrary field to a user. The attribute must be permitted by the class chain; otherwise the directory rejects the definition at schema validation, not as an access-denied decision.

Syntax defines value representation and comparison

Every attribute has exactly one syntax. Syntax identifies whether a value is a Unicode string (2.5.5.12), integer/enumeration (2.5.5.9), SID (2.5.5.17), or DN (2.5.5.1), and determines comparison behavior. For example, userAccountControl is an integer and department is a Unicode string.

A value that violates the attribute syntax fails to write. That is why AttributeSyntaxOID in the artifact matters: it connects the changed attribute and its representation to the schema definition.

Connecting to the next mechanism

Schema describes accepted attribute values; it does not grant write rights to a caller. 03.05 reads an entry; 03.07 separates schema and authorization checks within one Modify. 05.05 explains the effective-right path separately.

State and data flow

1. The client sends an LDAP request to create a user object.
2. The directory reads the target classSchema and verifies every required mustContain attribute.
3. For each requested attribute, it checks class-chain membership in mustContain/mayContain and validates the attribute syntax.
4. The system sets the structural/abstract inheritance chain in objectClass and sets objectCategory from defaultObjectCategory. A dynamic auxiliary class can later be added to or removed from objectClass; this does not change structuralObjectClass or objectCategory.
5. The object is stored with identity constants such as objectGUID and objectSid.
6. A later attribute change produces Event 5136 when the relevant SACL applies; the event identifies the changed attribute and value.

2. Exploitation

Broken trust assumption

The broken assumption is that changing an account attribute is merely cosmetic and cannot affect identity or service behavior.

Technical prerequisites

• The actor needs the effective write authority required for the target attribute or property set. Object class, attribute-specific operation constraints and the configuration path accepted by the DC are separate checks; Write Property is not a universal success guarantee.
• The attribute controls a security-relevant behavior, such as userAccountControl, servicePrincipalName, or msDS-AllowedToActOnBehalfOfOtherIdentity.
• Replication carries the change to other domain controllers and the relevant service reads the new value.
• The class definition permits the attribute; the directory does not accept arbitrary schema-free fields.

Exploitation mechanism

An attribute change can alter the behavior of the service that consumes it. For example, servicePrincipalName associates a service identity with an account's key context; an SPN is not an empty string but a syntactically valid, unique service identity. userAccountControl can affect authentication conditions, while delegation configuration bounds one principal acting on behalf of another. These are not merely presentation data such as a telephone number. A write right alone still proves neither a successful change nor domain compromise: inspect the object, operation constraints, effective configuration and the credential used by the service. Restrict who can change these fields and why, and verify the resulting behavior.

Review authority at the attribute level

A help-desk account may have been delegated only to update telephone numbers. If the ACE instead covers a broad property set or all attributes, its effective scope can reach fields affecting security behavior. Review who can write which attribute on which object.

An attribute’s name does not establish its risk. Examine its syntax and the mechanism consuming its value; together they determine what the change can affect.

Separate the schema label from the operation outcome

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.

3. Defense & Detection

Telemetry scope

• Enable the audit policy that records schema and directory attribute changes at the relevant domain controller and scope.
• Correlate the actor, target, authoritative identity, and operation rather than treating one event as proof.
• Use the directory object's stable identifier when joining records across rename, move, or replication boundaries.
• Record the SACL and policy scope: absence of an event may mean the relevant object or attribute was not audited.

Events and relevant fields

• Event fields identify the actor and target; preserve their names exactly when normalizing logs.
• The event is evidence of a directory operation, not proof that a downstream service accepted or used the value.
• Correlate related create, modify, move, and delete events within a time window and across domain controllers.
• Validate the event schema and parser against the actual Windows build before deploying a detector.

Anchor the investigation in authoritative fields

Read the event together with the directory schema and the object's stable identity. This separates a requested change from the authorization and downstream behavior it may influence.

A detector is only as complete as its SACL, parser, and correlation assumptions. Document those boundaries and treat missing telemetry as an unknown, not as evidence that no change occurred.

Detection logic · XPath

*[System[EventID=5136]] and *[EventData[Data[@Name='AttributeLDAPDisplayName']='msDS-AllowedToActOnBehalfOfOtherIdentity']]

Query assumptions

• This detection is a bounded query over one event document. Field shape, host correlation, policy scope, and absence of a result require independent validation.
• This detection is a bounded query over one event document. Field shape, host correlation, policy scope, and absence of a result require independent validation.
• This detection is a bounded query over one event document. Field shape, host correlation, policy scope, and absence of a result require independent validation.
• This detection is a bounded query over one event document. Field shape, host correlation, policy scope, and absence of a result require independent validation.

False positives

• Legitimate administration or lifecycle activity can produce the same signal. Interpret it with actor, target, timing, scope, and the corresponding state change.
• Legitimate administration or lifecycle activity can produce the same signal. Interpret it with actor, target, timing, scope, and the corresponding state change.
• Legitimate administration or lifecycle activity can produce the same signal. Interpret it with actor, target, timing, scope, and the corresponding state change.
• Legitimate administration or lifecycle activity can produce the same signal. Interpret it with actor, target, timing, scope, and the corresponding state change.

Hardening

• Apply least-privilege delegation at the object, attribute, and property-set boundary.
• Protect high-value principals and attributes with targeted SACLs and change monitoring.
• Prefer stable identity fields for authorization and correlation; inventory rules that key decisions on names.
• Pilot controls, measure false positives, and retain a tested rollback path before broad deployment.

Read the examples

<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>
    <Channel>Security</Channel>
    <Computer>DC01.outreason.example</Computer>
  </System>
  <EventData>
    <Data Name="OpCorrelationID">{4b2f7d90-0c2a-4c7f-9f1e-8c5a2b3d6e10}</Data>
    <Data Name="AppCorrelationID">-</Data>
    <Data Name="SubjectUserSid">S-1-5-21-3623811015-3361044348-303003820-1108</Data>
    <Data Name="SubjectUserName">deleg-hr</Data>
    <Data Name="SubjectDomainName">OUTREASON</Data>
    <Data Name="SubjectLogonId">0x3b8f2</Data>
    <Data Name="DSName">outreason.example</Data>
    <Data Name="DSType">%%14676</Data>
    <Data Name="ObjectDN">CN=İlkkan,OU=Staff,DC=outreason,DC=example</Data>
    <Data Name="ObjectGUID">{7d3a1f6c-2b45-4e88-9a0c-1e2f3a4b5c6d}</Data>
    <Data Name="ObjectClass">user</Data>
    <Data Name="AttributeLDAPDisplayName">department</Data>
    <Data Name="AttributeSyntaxOID">2.5.5.12</Data>
    <Data Name="AttributeValue">Guvenlik Operasyonlari</Data>
    <Data Name="OperationType">%%14674</Data>
  </EventData>
</Event>

Two reality checks

Assumption: I can turn a user object into a group by editing objectClass.

In fact: The structural class and objectCategory are determined when the object is created and cannot be changed. A dynamic auxiliary class can be added to or removed from objectClass, but this does not change structuralObjectClass; making a user a different structural type such as group requires a separate object.

Assumption: I can write any attribute to a user if I have directory write access.

In fact: The class chain must permit the attribute and its value must satisfy the attribute syntax. A failure at that boundary is schema validation, not merely an access denial.

Sources

• Microsoft · Active Directory Domain Services overview
  Directory object/attribute model and the location of the schema
• Microsoft · Characteristics of Attributes
  attributeSchema; lDAPDisplayName, schemaIDGUID, syntax, and isSingleValued
• Microsoft · Structural, Abstract, and Auxiliary Classes
  objectClassCategory (1/2/3) and the union of mustContain/mayContain
• Microsoft · Object Class and Object Category
  Multi-valued objectClass superclass chain and single-valued objectCategory
• Microsoft · 5136(S) A directory service object was modified
  Event XML, field descriptions, and OperationType values
• Microsoft · Audit Directory Service Changes
  SACL requirement, DC-only generation, and scope
• IETF · RFC 4511 Lightweight Directory Access Protocol (LDAP): The Protocol
  LDAP Add/Modify operations and the attribute-value model
• Microsoft · Determining the Classes Associated With an Object Instance
  structuralObjectClass versus objectClass; dynamically attached auxiliary classes and statically linked auxiliary classes
• Microsoft · Adding an Auxiliary Class to an Object Instance
  An existing object instance can receive a dynamic auxiliary class through objectClass
• Microsoft Open Specifications · [MS-ADTS] Auxiliary Classes
  §3.1.1.3.1.1.5; dynamic auxiliary classes are added/removed through objectClass; objectClass contains structural, abstract, and dynamic auxiliary classes
• Microsoft · Deciding What to Find
  Finding user objects; AND of objectClass=user and objectCategory=person
• 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