Windows Identities: Local Accounts vs Domain Accounts

DFIR Investigation Axiom

The username is not an identity. Two accounts sharing the string Administrator on two separate hosts or domains share absolutely zero security authority or cryptographic secrets.

The core thread of any forensic triage must strictly enforce:

Identity → Authentication → Authorization → Access → Action

Concept

In the Windows operating system, a Security Principal is an entity that can be authenticated by the operating system and assigned permissions on securable objects (files, registry keys, network shares, processes).

A fundamental, airtight division exists between two architectures:

1. Local Accounts: Stored exclusively in the SAM (Security Account Manager) registry hive of a single machine.
2. Domain Accounts: Stored centrally in the Active Directory database (ntds.dit), replicated across Domain Controllers (DC).

Identity is never established by the display name or logon name (sAMAccountName), but by an immutable mathematical identifier: the SID (Security Identifier).

---

Why This Matters in DFIR

During post-breach triage and ransomware investigation (e.g., Akira, LockBit), analysts frequently miscorrelate log events by relying on usernames alone:

• False Sense of Continuity: Seeing Administrator successfully log into Server A and then Server B does not prove it is the same actor or the same account. If Server A used SERVER-A\Administrator and Server B used SERVER-B\Administrator, these are distinct security authorities, even if credential reuse was involved.
• Blast Radius Assessment: Compromising a high-privileged local account does not inherently yield domain-wide control, whereas compromising a domain account that belongs to local administrators groups via GPOs provides immediate lateral reach across the entire fleet.
• Authority Validation: A standalone (non-domain-joined) host has zero native awareness of what an Active Directory domain account is without explicit network federation or application-layer integration.

---

How It Works

1. The Local Security Account Manager (SAM)

Every standalone or domain-joined Windows machine maintains a local database inside HKLM\SAM.

• Issuing Authority: The local host (COMPUTERNAME).
• Storage: Password hashes (NTLM) are stored encrypted by Syskey (HKLM\SYSTEM).
• Validation: Local authentications are handled directly by LSASS via MSV1_0.DLL against this database.

2. Active Directory Database (ntds.dit)

On a Domain Controller, the operational SAM database is superseded by the ESE relational database ntds.dit.

• Issuing Authority: The Active Directory Domain Controller.
• Storage: Centrally managed and replicated across all DCs in the domain.
• Validation: Authentications are negotiated via Kerberos (KDC / TGT and TGS tickets) or NTLM Pass-Through via the Netlogon service.

Criterion	Local Account (SAM)	Domain Account (Active Directory)
Storage Location	HKLM\SAM on local host storage	ntds.dit on Domain Controllers
Security Authority	Local Host (COMPUTERNAME)	Active Directory Domain (DOMAINNAME)
SID Format	S-1-5-21-<Machine_ID>-<RID>	S-1-5-21-<Domain_ID>-<RID>
Offline Validity	Permanent on the host	Requires Cached Credentials (MSCACHE)
Management Interface	lusrmgr.msc or net user	ADUC (dsa.msc), PowerShell ActiveDirectory

---

What Is Possible

• Homonymous Accounts Across Authorities: An account named Administrator can exist independently on Host A, Host B, Domain A, and Domain B.
• Domain Logons on Joined Hosts: A domain-joined machine resolves domain credentials by routing Kerberos/NTLM authentication requests to a Domain Controller.
• Network Access via Local Accounts: As detailed in Doc 20: Local Accounts on Domain-Joined Machines, a local account can be used over network boundaries (SMB, WinRM, RPC) targeting the machine that hosts its SAM.
• Maintaining Local Accounts on Joined Hosts: Domain joining does not delete or disable the local SAM. SERVER01\LocalAdmin remains operational.

---

What Is Not Possible

• Local Accounts Cannot Authenticate Against Active Directory: SERVER01\LocalAdmin is unknown to the Domain Controller and cannot obtain a Kerberos TGT to access domain assets.
• Cross-Host Trust for Local Accounts: Machine B cannot natively validate a local account belonging to Machine A unless an identical username and password hash coincidentally exist on Machine B.
• Domain Controllers Do Not Possess Distinct Local User Accounts: Promoting a server to a DC merges user management into ntds.dit (except for Directory Services Restore Mode - DSRM).

---

Common Misconceptions

Forensic Traps

1. Confusing Workgroup with Standalone SAM: When an event log shows Workstation\admin, some analysts conclude the host is not domain-joined. Every domain-joined machine still retains its local SAM.
2. Tying Privileges to the Username: Renaming Administrator to SVC_Backup does not strip its administrative privileges because its SID still ends with RID 500 (see Doc 02: SID, RID and Windows Identity).
3. Believing Trusts Bridge Local Accounts: Active Directory Trusts only bridge domain security authorities. A trust never connects two local SAM databases.

---

Concrete DFIR Scenario

Consider domain PROD.CORP (Domain SID: S-1-5-21-111111111-222222222-333333333) and domain-joined file server FS01 (Machine SID: S-1-5-21-777777777-888888888-999999999).

When an attacker authenticates to FS01:

• If specifying Administrator without domain context, NTLM resolves against local SAM: FS01\Administrator (S-1-5-21-777777777-888888888-999999999-500).
• If specifying PROD\Administrator, Kerberos/NTLM evaluates against the Domain Controller: PROD\Administrator (S-1-5-21-111111111-222222222-333333333-500).

These are two entirely separate entities with distinct password hashes, distinct Kerberos keys, and distinct token privileges.

---

Forensic Artifacts

In Security.evtx, Event ID 4624 (Successful Logon) provides definitive evidence of the issuing authority:

EventID: 4624
SubjectUserSid: S-1-5-18 (SYSTEM)
TargetUserSid: S-1-5-21-777777777-888888888-999999999-500
TargetUserName: Administrator
TargetDomainName: FS01                  <-- PROOF: Local SAM Account
LogonType: 3                             <-- Network Logon (SMB/RPC)
AuthenticationPackageName: NTLM
PackageName: NTLM V2

Whereas a domain account authentication demonstrates:

TargetUserSid: S-1-5-21-111111111-222222222-333333333-500
TargetUserName: Administrator
TargetDomainName: PROD                  <-- PROOF: Domain Account
AuthenticationPackageName: Kerberos

---

Investigation Methods

1. Offline SAM Registry Triage:

   # Extract local security principals from disk images
   secretsdump.py -sam sam.save -system system.save LOCAL

2. Live PowerShell Inspection:

   Get-LocalUser | Select-Object Name, SID, Enabled, LastLogon
   (Get-CimInstance Win32_ComputerSystem).Domain

3. Security Event Triage:
   • Extract Event ID 4624 / 4625.
   • Compare TargetDomainName with the host’s COMPUTERNAME. If equal, the principal is a local SAM entity.

---

Key Takeaways

1. The username is just a cosmetic label; the SID is the immutable legal identity.
2. Domain-joined machines ALWAYS maintain an active local SAM database.
3. To determine authority in logs, verify whether TargetDomainName matches the local hostname or an AD domain.
4. Active Directory Trusts have zero relationship with local SAM accounts.

---

Cross References

• Doc 02: SID, RID and Windows Identity
• Doc 04: Local Administrator vs Domain Administrator
• Doc 20: Local Accounts on Domain-Joined Machines
• Active Directory Fundamentals