SID, RID, and objectGUID: Identity independent of the name

1. Core mechanism

This lesson covers name-independent identity constants: objectSid components, RID allocation, and objectGUID persistence. Names are covered in 03.02; token construction and access checks in 02.03–02.04; and forest-wide distribution in 03.04. RPC and packet-marshalling details for SID are left to MS-DTYP; here the focus is string representation and component meaning.

Interfaces and specifications

• objectSid: the binary SID that identifies a security principal; assigned when the account is created, stable through rename/same-domain OU move, and replaced on cross-domain move.
• Revision (R): the version of the SID structure (practically 1).
• Identifier authority (X): the highest authority that issued the SID; 5 for NT Authority and 1 for World Authority.
• Domain identifier: the subauthority sequence before the RID; it distinguishes a domain within the forest.
• RID: the final subauthority; it distinguishes an account within the domain and is never reused.
• objectGUID: a globally unique 128-bit identifier assigned when an object is created; it survives rename and move.
• sIDHistory: a multi-valued attribute that stores former objectSid values when an object moves between domains.

A SID is a hierarchy, not a single number

A SID is written as S-R-X-Y1-Y2-...-Yn: S is the fixed prefix, R is revision, X is identifier authority, and the Y values are subauthorities. In S-1-5-21-3623811015-3361044348-303003820-1108, revision is 1, identifier authority is 5 (NT Authority), the domain identifier is 21-3623811015-3361044348-303003820, and 1108 is the RID.

For domain accounts, the SID combines the domain SID with an account-specific RID. The domain identifier separates domains in the forest and the RID separates accounts within one domain. Built-in groups are different: they use the well-known domain identifier 32, for example S-1-5-32-544 for Administrators.

How RID allocation preserves uniqueness

A domain can have several domain controllers, each holding a writable copy of the account database. RID allocation is single-master: the RID Master assigns each DC a block, and the DC uses each value in that block once before requesting another.

The security consequence is that the authority does not issue the same SID twice and does not reuse the SID of a deleted account. If a former employee returns, a newly created account receives a new RID and SID; none of the old principal's access follows automatically.

objectGUID: the immutable anchor

Active Directory assigns objectGUID when an object is created; it is globally unique, not merely enterprise-unique. Rename or move changes distinguishedName but never changes objectGUID, making it a reliable way to locate the same object.

The distinction matters: objectSid is the security identity used by access checks; objectGUID is the directory-object anchor. Both remain stable through a rename and same-domain OU move; a cross-domain move changes objectSid and carries the old SID in sIDHistory, while objectGUID stays with the object. GUID/SID evidence helps resolve cases where two different objects have the same name.

sIDHistory: identity carried across a move

A cross-domain move assigns a new objectSid and adds the former SID to sIDHistory. This directory attribute is not itself an access decision. SIDs accepted under the applicable logon and trust conditions enter the access token; the resource access check compares token SIDs with DACL ACE trustee SIDs. SID filtering can limit which former SIDs are accepted in authorization data crossing a trust. The same stored sIDHistory therefore does not imply the same access result at every target.

That convenience is a trust boundary. If a privileged SID can be written into sIDHistory, the privilege can be carried without changing the account's name. The Red layer examines this assumption.

State and data flow

1. A new domain account is created; the DC combines the domain SID with a RID from the block allocated by the RID Master.
2. The system assigns a globally unique objectGUID at the same time; it remains stable for the object's lifetime.
3. The account is renamed or moved to another OU in the same domain: cn/DN changes, objectSid and objectGUID stay stable, and SID-based ACEs continue to apply to the same account.
4. Deleting and recreating the same name produces a new RID and objectSid; old ACEs do not match the new principal.
5. A cross-domain move retains objectGUID, replaces objectSid and adds the old SID to sIDHistory. SIDs accepted under the applicable logon/trust conditions enter a fresh token.
6. The resource compares token SIDs with ACE trustee SIDs. Rename retains the principal; recreating a name does not restore the old SID. A SID match does not replace other access-check conditions such as ACE order and requested rights.

2. Exploitation

Broken trust assumption

The broken assumption is that identity is equivalent to a name, that reclaiming a name restores access, and that sIDHistory is only a harmless migration record.

Technical prerequisites

• Access decisions rely on a name or stale SID reference instead of the current objectSid.
• A privileged migration path for adding an SID to sIDHistory, or broader control over a domain controller/directory store. For example, the documented DsAddSidHistory API for interforest migration requires Domain Admin in the destination domain and Administrator or Domain Admin in the source domain.
• The relevant cross-domain trust boundary permits the source SID to enter the target authorization data; which SIDs are accepted depends on trust type and filtering configuration.
• ACE entries for deleted accounts remain on resources as orphaned SIDs.

Exploitation mechanism

A token's authorization data is built from the current objectSid, group SIDs, and sIDHistory values; access checks compare SIDs, not names. Adding a privileged SID to sIDHistory through an authorized migration operation (or allowing that SID through the relevant trust boundary) can therefore carry access without changing the account's visible name. For example, the documented DsAddSidHistory API for interforest migration requires Domain Admin in the destination domain and Administrator/Domain Admin in the source domain; an ordinary Write Property delegation alone does not satisfy this API's checks. The same SID-based rule invalidates the reverse assumption: a deleted and recreated account gets a new RID and does not inherit the deleted account's ACEs, so “same name = same access” is false. The boundary is trust type/configuration and who can write sIDHistory; controls include applying appropriate SID filtering at the trust boundary, restricting sIDHistory writes to authorized Domain Admin migration flows, and cleaning orphaned SIDs.

Follow the stable identity, not the presentation field

In one direction, the danger is attaching a privileged SID to an account through sIDHistory or authorization data accepted by the trust boundary; the account can look ordinary while its token carries elevated access. In the other direction, the assumption “we restored the old name, so the old access returns” fails because RIDs are not reused. The documented DsAddSidHistory route for interforest migration requires Domain Admin in the destination domain and Administrator/Domain Admin in the source domain; ordinary attribute delegation does not automatically satisfy that requirement.

Trace the writer, the authoritative field, the service that consumes it, and the event evidence separately. A name or attribute in a log is not, by itself, proof of authorization or compromise.

3. Defense & Detection

Telemetry scope

• Enable the audit policy that records SID history and identity 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.
• objectGUID remains stable through rename/move; objectSid also remains stable on rename and same-domain OU move, but is replaced on cross-domain move while the old SID enters sIDHistory. ObjectGUID in Event 5136 anchors a change record to the object independently of its name.

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.
• The documented 5136 XML uses SubjectUserSid and SubjectLogonId for the requesting principal and its session; correlation with 4624 on the same DC is a candidate link. The 4765 page instead supplies Subject / Security ID and Logon ID schema labels; this lesson does not derive EventData field names from those labels. A Logon ID alone proves neither authentication nor misuse.

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']='sIDHistory']]

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

O:DAG:DUD:(A;;GRGWGX;;;S-1-5-21-3623811015-3361044348-303003820-1108)(D;;GA;;;S-1-5-21-3623811015-3361044348-303003820-1109)(A;;GRGX;;;S-1-5-21-3623811015-3361044348-303003820-513)S:(AU;SA;GWGA;;;S-1-5-21-3623811015-3361044348-303003820-1108)

Two reality checks

Assumption: Recreating a departed employee's old name restores the old file and group access.

In fact: A deleted SID/RID is not reused. A recreated account receives a new SID; access returns only through explicit reauthorization or controlled sIDHistory migration.

Assumption: objectGUID and objectSid are two representations of the same identity.

In fact: objectGUID and objectSid serve different purposes: objectSid is the SID used in access checks, while objectGUID is a 128-bit object identity assigned at creation. Both remain stable through rename and same-domain OU move; moving an object to another domain assigns a new objectSid and adds the old SID to sIDHistory, while objectGUID remains stable.

Sources

• Microsoft · Security Identifiers
  SID architecture, S-R-X-Y notation, RID allocation, and non-reuse of SIDs
• Microsoft Open Specifications · [MS-DTYP] SID
  SID string syntax, 96-bit account-store identifier, and 32-bit RID
• Microsoft · User Naming Attributes
  objectGUID assignment and persistence; objectSid and sIDHistory on cross-domain move
• Microsoft · ACE strings
  SDDL ACE syntax; A/D/AU types and GR/GW/GX/GA generic rights
• Microsoft · 4765(S) SID History was added to an account
  Event schema (Subject/Target/Source Account and SID List), DC-only generation, Version 0
• Microsoft · 5136(S) A directory service object was modified
  ObjectGUID, AttributeLDAPDisplayName, and syntax OID (String(Sid) 2.5.5.17)
• Microsoft · DsAddSidHistoryW function
  Security-sensitive sIDHistory addition; source/destination account parameters and privilege requirements linked through Using DsAddSidHistory
• Microsoft · Using DsAddSidHistory
  Authorization Requirements, Threat Models, and requirements for Domain Admin at destination and Administrator/Domain Admin at source
• Microsoft Open Specifications · [MS-PAC] SID Filtering and Claims Transformation
  §4.1.2.2 trust boundary types and SID filtering rules; effective filtering depends on trust boundary