What problem does Active Directory solve? Workgroup, domain, and centralized identity

1. Core mechanism

Who tracks changes in a workgroup?

A Windows computer outside a domain manages its own local accounts. In this example, IT chooses to create separate local accounts for Tunahan on WS01, WS02 and FS01. Creation, password administration and disabling are separate jobs in each account authority. Three accounts are a scenario choice, not a requirement for every workgroup.

Changing a setting on WS01 does not update a report permission on FS01. Other tools can automate administration; a workgroup does not mean everything must be manual. The distinction here is whether these computers use a shared AD domain identity.

What does a domain share?

AD DS stores users, groups and computers in a shared directory. IT creates one user account for Tunahan in IYELABS. Domain-joined WS01 and WS02 can use that domain identity; permissions on FS01 can refer to the same domain account or group. Each member computer does not need a newly created local copy of the user.

A domain controller, or DC, runs directory and domain authentication services. Central administration does not require a single physical server: multiple DCs can replicate directory data. Domain membership also does not remove local accounts from a computer.

The directory is more than a user list. Computer objects, group memberships and appropriately scoped Group Policy settings support a shared administrative arrangement. Later lessons explain their processing; the idea here is a common foundation for identity and administration.

Joining, changing roles and leaving

When Tunahan joins, IT creates his domain account and determines required groups and resource permissions. If a team group already has report-read permission, managing his membership is clearer than writing his username on every file. Creating a group alone grants nothing: FS01 must also assign that group the relevant permission.

A role change requires reviewing both old memberships and new access needs. Disabling the domain account when an employee leaves is a central step intended to block new domain authentications. Local accounts, application sessions and previously established access contexts still need attention.

Directory changes reach other DCs through replication. A membership change does not rewrite an existing token; disabling an account does not instantly destroy all existing sessions and tickets. Central administration and immediate universal revocation are different claims.

Authentication does not open every file

Domain authentication answers which account is being used. FS01 separately evaluates whether that account or its groups may read the report. Tunahan can use a valid domain identity and still be unable to read a report because the needed group or resource permission is missing.

AD supplies a common administrative foundation without granting universal access. Directory administration therefore needs carefully scoped privileges: permission to change many accounts or memberships can have a broader effect than an ordinary change on one device.

Explore identity as a separate question

The takeaway is that AD supports shared domain administration of accounts, memberships and policy as an organization grows. Resource permissions still need to be configured and evaluated separately.

Why are WS01\tunahan, FS01\tunahan and IYELABS\tunahan different accounts? Lesson 02.01 separately explains a person versus an account and a displayed name versus a SID. First explain this management problem in your own words, then continue to the identity comparison.

State and data flow

1. Identify what Tunahan needs on WS01, WS02 and FS01: work, report reading and an access lifecycle.
2. Choose workgroup or domain and compare the authority that stores the managed accounts.
3. This example manages three separate local accounts in a workgroup, or one shared domain account used by member devices.
4. Report permission on FS01 is assigned separately. A shared domain account or group does not automatically grant READ to everyone.
5. Tunahan leaves: review the separate local accounts in the workgroup, or centrally disable his domain account in the domain.
6. A central change does not instantly erase existing sessions, tokens or tickets. DC replication and existing access contexts need separate consideration.

2. Exploitation

Broken trust assumption

Broken assumption: a shared domain identity automatically grants administrative and resource access rights. Domain membership grants neither directory delegation nor FS01 READ permission.

Technical prerequisites

• A domain account or administrative role with actual permissions.
• A known set of users, groups or objects that the role can change.
• Separately required resource permissions for resource access.

Exploitation mechanism

Changes to shared-directory accounts and memberships can affect identities used by multiple resources. Actual delegation and resource permissions bound impact; local admin on one device is not automatic domain administration.

Scope of central administration

A shared directory makes permission to change its users and groups consequential. Joining a domain grants no such administration right; delegation and actual privileged-account permissions determine the scope.

Control over one local account and directory administration are different outcomes. Bound impact by the device, account authority and objects that can be changed. Explore identity and credential reuse separately in 02.01.

3. Defense & Detection

Telemetry scope

• Telemetry is generated by the workstation or server where the session is created; the channel is Security.
• Success in the Audit Logon subcategory supports 4624 success records; Failure supports 4625 failure records.
• Event 4624 is recorded on the target computer. This artifact supports only comparison of successful 4624 records; it does not show a failure result or access to a resource object.

Events and relevant fields

• 4624 / Computer + TargetDomainName + TargetUserSid: host and account context of a session; inspect the separate examples in 02.01.
• 4624: a successful target session, not proof that disabling ended every access or that a file was read.

Separate administrative changes from outcomes

Start with an inventory of the domain account, local accounts, memberships and resource permissions. Account status alone does not establish that all previously created access contexts have ended.

A directory change, a successful session and a particular file read are separate observations. This lesson uses a synthetic administrative comparison, not a Windows event. Lesson 02.01 reads session evidence with account authority; chapter 15 develops resource evidence.

Detection logic · XPath

*[System[(EventID=4624)]] and *[EventData[Data[@Name='TargetUserName']='tunahan']]

Query assumptions

• This is an unexecuted candidate filter for Windows Event Log XML fields; it is not a SIEM query or a password-reuse detector.
• Classify results together with TargetUserSid, TargetDomainName, and Computer.
• TargetDomainName formatting varies by environment and logon path; without a computer/domain inventory, it should not be used for definitive classification.
• The fixture has not been run through the parser; no result is claimed for an actual Windows dataset.

False positives

• A help-desk standard may exist as the same local account on many devices.
• Service, built-in, and cached domain-logon records can be misclassified if classification relies on a single field.
• Negative example: 4624 records do not show that two accounts use the same password.

Hardening

• Manage onboarding, role changes and leaving as one lifecycle.
• Administer resource permissions through task-appropriate groups and review old memberships.
• Limit directory delegation and privileged-account use to the necessary scope.
• When disabling a domain account, review local accounts and existing session/ticket contexts separately.
• Verify account, session and file-access evidence as separate observations.

Read the examples

{
  "kind": "teaching-record",
  "synthetic": true,
  "scenario": "Tunahan joins, uses three devices, then leaves",
  "devices": [
    "WS01",
    "WS02",
    "FS01"
  ],
  "workgroup": {
    "accountAuthorities": [
      "WS01 local SAM",
      "WS02 local SAM",
      "FS01 local SAM"
    ],
    "managedAccounts": 3,
    "disableScope": "Each selected local account separately"
  },
  "domain": {
    "accountAuthority": "IYELABS AD DS",
    "managedUserAccounts": 1,
    "memberDevices": [
      "WS01",
      "WS02",
      "FS01"
    ],
    "disableScope": "Domain account; local accounts are separate"
  },
  "resource": {
    "host": "FS01",
    "requestedRight": "READ",
    "permission": "Configured separately"
  },
  "existingSessionsAndTickets": "No instantaneous revocation claimed"
}

Two reality checks

Assumption: Joining a domain copies the user into a local account on every computer.

In fact: Domain members can use the shared domain principal. Local accounts remain separate; the domain user object need not be recreated on every member computer.

Assumption: Authenticating with a domain account grants access to all resources in the domain.

In fact: Domain authentication supplies identity and token inputs. Each resource still evaluates the requested access with its own security descriptor and security context; a successful logon does not authorize access automatically.

Sources

• Microsoft · Active Directory Domain Services overview
  Directory objects, integrated security, policy administration and replication; consulted 2026-10-11.
• Microsoft · Local accounts
  Introduction and “Local accounts”: how local accounts are defined on a device and how the local security context works.
• Microsoft · Security Principals
  “How security principals work”, “Security identifiers”, and “Access tokens”.
• Microsoft · Credentials Processes in Windows Authentication
  “Windows credentials authentication overview”: local SAM and domain/DC authentication paths.
• Microsoft · 4624(S): An account was successfully logged on
  Event Description, Version 2 XML, New Logon fields, and Account Domain behavior for local accounts.
• Microsoft · Windows LAPS overview
  Introduction and Benefits: unique per-device local-administrator passwords and rotation.