CN, DN, UPN, and sAMAccountName: Why does one account have multiple names?

1. Core mechanism

This lesson covers distinguishedName, cn/name, userPrincipalName, and sAMAccountName. Their stable counterparts, objectSid and objectGUID, are covered in 03.03; LDAP connectivity and search in 03.05; and the forest-wide role of the Global Catalog in 03.04. The goal is to make each name's function and uniqueness scope explicit.

Interfaces and specifications

• distinguishedName (DN): the object's full directory location, a comma-separated sequence of RDNs (RFC 4514).
• relativeDistinguishedName (RDN): the object's name within its parent. This AD user example uses the naming attribute cn and RDN CN=Büşra. General LDAP string syntax permits one or more attribute-value assertions in an RDN.
• cn (commonName): the naming attribute of a user object; it supplies the RDN.
• userPrincipalName (UPN): prefix@suffix logon name; forest-wide uniqueness is checked under documented originating-write conditions.
• sAMAccountName: a down-level logon name of no more than 20 characters, unique within a domain.
• upnSuffixes / Partitions container: Configuration entries that define alternative UPN suffixes.

distinguishedName is a location, not an identity

A DN is a directory address made of comma-separated RDNs: CN=Büşra,OU=Staff,DC=outreason,DC=example. CN=Büşra is this user's RDN; the remainder is the parent path. Under RFC 4514's general string syntax, multiple attribute-value assertions within one RDN are separated by +; this AD user example uses cn as its naming attribute. A move changes the parent path and a rename changes the RDN; both change the DN.

An application that stores a DN in external configuration may no longer find the object through that address after rename or move. An objectGUID provides a durable directory reference. A Windows DACL ACE identifies its principal through a trustee SID, not a DN. The stored address, directory object identity and SID used for resource authorization are distinct.

cn and rename

cn is the naming attribute and forms the object's RDN. Changing the leftmost RDN is a rename; moving the object to another OU is a move. Both change the DN while objectGUID remains constant.

A rename or OU move within the same domain changes the DN while retaining objectGUID and objectSid. A cross-domain move differs: objectGUID follows the object, the destination assigns a new objectSid and the former SID is added to sIDHistory. Deleting and recreating the same name creates a new object with a new GUID and SID. The displayed name alone cannot distinguish these outcomes.

userPrincipalName: an internet-style logon name

A UPN is a prefix@suffix logon name, such as busra@outreason.example. The uniqueness target is the complete value across the forest; busra@a.example and busra@b.example are different values. That target is not proof that duplicate UPNs cannot exist in directory state.

MS-ADTS specifies the forest-wide check for originating Add, Modify and Undelete operations on a DC at functional level DS_BEHAVIOR_WIN2012R2 or later. Applicable OS updates and configuration also matter. A configuration exception can suppress UPN checking; replicated updates do not enforce this uniqueness constraint. Check the actual DC version, updates, configuration and directory values rather than infer a universal guarantee from the naming rule.

The suffix need not be the user's domain; it can be a forest domain name or an alternative defined in the Partitions container's upnSuffixes. A rename or move does not change UPN unless an administrator changes it explicitly. During logon, the UPN is checked in the local domain and, when needed, the Global Catalog.

sAMAccountName: the down-level logon name

sAMAccountName supports legacy clients and servers such as Windows NT 4.0, Windows 95/98, and LAN Manager. It appears in DOMAIN\user down-level logon and is at most 20 characters, unique among security principals in its domain.

The scope is the critical point: sAMAccountName is domain-unique, not forest-unique. Two domains can therefore contain the same value, so matching a principal by sAMAccountName alone is unsafe in a multi-domain environment.

State and data flow

1. The user logs on with a UPN such as busra@outreason.example; the system validates it in the local domain and, if necessary, through the Global Catalog.
2. A down-level client logs on as OUTREASON\busra.old using sAMAccountName, which is unique only in OUTREASON.
3. An application uses distinguishedName for location or objectGUID for a durable identity when it searches for the object.
4. An administrator renames or moves the object to another OU within the same domain; DN changes while objectGUID and objectSid remain stable. Cross-domain moves have a separate SID boundary.
5. An administrator changing a UPN should preserve full-value forest uniqueness; enforcement depends on the originating DC and documented conditions. sAMAccountName keeps its separate domain naming scope.
6. Event 4781 records the sAMAccountName rename; TargetSid anchors the record to the account. A UPN change needs separate 5136 evidence under the relevant audit/SACL conditions.

2. Exploitation

Broken trust assumption

The broken assumption is that matching an account by name makes it a unique, stable principal.

Technical prerequisites

• Authorization or correlation logic uses a name (sAMAccountName, UPN prefix, cn, or DN) instead of SID/objectGUID.
• Using a narrower name fragment as an identity key: sAMAccountName is domain-scoped; a UPN prefix alone omits its suffix, and full-value uniqueness checking has documented exceptions.
• An object can be deleted and recreated with the same name, or renamed into the path of an old reference.
• A multi-domain or trusted environment permits the same sAMAccountName in different domains.

Exploitation mechanism

Names can change and have limited uniqueness scopes. objectSid and objectGUID remain stable during a rename or an OU move within the same domain; moving an object to another domain can assign a new objectSid and place the previous SID in sIDHistory (03.03). objectGUID remains unchanged through rename and move. If an authorization or matching decision uses a name, a rename or recreation can make the same name refer to a different object, and the same sAMAccountName in another domain can be confused with it. The result can be authorization for the wrong principal or misattribution. The boundary is the application or configuration that keys decisions by name; the control is to use name-independent identifiers and reconcile SID changes with sIDHistory during domain migration.

Follow the stable identity, not the presentation field

A rule such as 'allow user X' is fragile while X is a name. It can be reassigned, repeated within a different scope, or changed by a rename. objectSid/objectGUID remain stable across a rename or an OU move within the same domain; a cross-domain move can change objectSid, while objectGUID remains unchanged. Authorization and log correlation should therefore use name-independent identifiers such as objectSid or objectGUID; domain migration also requires reconciling SID history.

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 account naming 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=4781]]

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.
• Inventory full UPN values across the forest and investigate duplicates or unexpected suffixes; do not assume write-time checks make a current duplicate scan unnecessary.
• 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>4781</EventID>
    <Version>0</Version>
    <Level>0</Level>
    <Task>13824</Task>
    <Opcode>0</Opcode>
    <Keywords>0x8020000000000000</Keywords>
    <Channel>Security</Channel>
    <Computer>DC01.outreason.example</Computer>
  </System>
  <EventData>
    <Data Name="OldTargetUserName">busra.old</Data>
    <Data Name="NewTargetUserName">busra</Data>
    <Data Name="TargetDomainName">OUTREASON</Data>
    <Data Name="TargetSid">S-1-5-21-3623811015-3361044348-303003820-1155</Data>
    <Data Name="SubjectUserSid">S-1-5-21-3623811015-3361044348-303003820-500</Data>
    <Data Name="SubjectUserName">Administrator</Data>
    <Data Name="SubjectDomainName">OUTREASON</Data>
    <Data Name="SubjectLogonId">0x2f1a4</Data>
    <Data Name="PrivilegeList">-</Data>
  </EventData>
</Event>

Two reality checks

Assumption: sAMAccountName is forest-unique, so it is a safe key by itself.

In fact: sAMAccountName is domain-scoped and has the 20-character naming limit. The full UPN has a forest-wide uniqueness target, with documented enforcement conditions and replication exceptions. Neither a name fragment nor this target is a durable identity key; use objectSid/objectGUID with the relevant domain context.

Assumption: Renaming an account changes its SID and removes its existing access.

In fact: A rename or an OU move within the same domain changes the name/location; objectSid and objectGUID remain stable. A cross-domain move can assign a new objectSid and add the old SID to sIDHistory, while objectGUID remains stable through rename/move. TargetSid in Event 4781 identifies the same account during a rename. SID-based ACEs therefore continue to apply after rename (03.03).

Sources

• Microsoft · User Naming Attributes
  Naming attributes and design uniqueness scope; enforcement exceptions qualified separately by MS-ADTS Uniqueness Constraints; stable identity and cross-domain move behavior
• IETF · RFC 4514 LDAP: String Representation of Distinguished Names
  §2 DN = sequence of RDNs; §2.3 RDN = attributeType=value
• Microsoft · 4781(S) The name of an account was changed
  Event XML, field descriptions, OldTargetUserName/NewTargetUserName, and stable TargetSid
• Microsoft · Audit User Account Management
  Audit User Account Management subcategory and the Events List containing 4781
• Microsoft · 5136(S) A directory service object was modified
  Tracking changes to attributes such as userPrincipalName with AttributeLDAPDisplayName
• IETF · RFC 4511 Lightweight Directory Access Protocol (LDAP): The Protocol
  Modify DN operation and rename/move semantics
• Microsoft Open Specifications · MS-ADTS Uniqueness Constraints
  §3.1.1.5.1.3: originating versus replicated updates, DC functional level, configuration and update scope