Skip to content

02 · Windows and Active Directory

Depth: developed lesson · Prerequisites: foundations, processes and networking · Time: two 90-minute sessions.

A directory describes identities and relationships. A running process acts under a security context. A resource applies a policy to an operation. Keeping these three things separate makes Windows investigations much more precise: finding a group name is an observation, while proving access requires an actor, target, action and decision.

Outcomes

  • Distinguish directory membership, a process token, and resource authorization.
  • Explain why a display name is a weaker identity reference than a SID.
  • Read your own Windows identity context without modifying it.
  • Build a prerequisite chain and identify the evidence missing from each edge.

Three views of the same identity

AD DS stores directory objects and relationships and supports centralized identity administration. A domain controller provides directory services; it is not the same thing as every member computer or application in that domain. A directory query can describe an account without testing what a particular service permits it to do. Microsoft AD DS overview.

On Windows, an access token describes the security context of a process or thread. It contains a user SID, group information and privileges, among other fields. A thread can use an impersonation context, so the identity of the service process alone may not describe the identity used for a particular access. Privilege presence and privilege enablement are separate observations. Microsoft access tokens.

Finally, ask about the object being accessed. Reading a file, changing a directory object and invoking an application endpoint are different actions against different resources. A useful investigation follows the identity through to the actual enforcement point instead of stopping at “this account belongs to a powerful-sounding group.”

View Question Evidence that answers it
Directory Which identity and relationships are recorded? A scoped directory observation with time and object identity
Execution Under which context is this operation attempted? The relevant process/thread or logon context
Resource Which operation was allowed or denied? Policy plus an observed decision on that resource

Do not join records solely on a friendly name. In your worksheet use an immutable identifier where available and record where it came from. Redact real identifiers before sharing a report.

Session 1: interpret a synthetic access model

The following is an original fictional policy, not actual Windows command output or a complete DACL evaluator. It deliberately excludes deny entries, inheritance, nested groups, token attributes and special privileges so that you can practice reasoning about the evidence boundary first.

Identity A: lab-alice, identifier U-A, groups {G-READ}
Identity B: lab-bob,   identifier U-B, groups {G-READ, G-EDIT}
Service S:  lab-sync,  identifier U-S, groups {G-SYNC}

Resource R1: training-report
  read:  G-READ
  write: G-EDIT
Resource R2: upload-inbox
  write: G-SYNC

Teaching rule: allow only when a listed group grants the exact action.
No other grants exist in this fictional model.

Before opening the answer, classify six requests: Alice reads R1; Alice writes R1; Bob writes R1; service S writes R2; service S reads R1; Bob writes R2. For each one name the matching grant or the missing prerequisite.

Worked answer

Allow, deny, allow, allow, deny, deny. Bob's write permission on R1 does not transfer to R2. The service's narrow upload permission does not make it a general administrator. Alice's successful read provides no evidence of write access.

Now change exactly one fact: add G-EDIT to Alice's directory record, but retain an observation of a running process whose recorded group set remains {G-READ}. Can you conclude that the process can now write R1? No: the worksheet lacks evidence that the context used for the request has changed. This is an evidence problem; do not turn it into a claim that every Windows logon and group update behaves identically.

Write a second case where the policy changes while identity stays fixed. Compare the two cases. One changes the actor context, the other the resource rule; your report must say which was tested.

Session 2: inspect your own Windows lab context

This optional native exercise needs Windows. Run the following in an ordinary terminal under your own disposable lab account. These commands inspect the current identity; they do not enumerate a domain or change membership.

whoami /user
whoami /groups
whoami /priv

Record the account/SID association, one group row including its attributes, and one privilege row including its state. Keep the raw output private. Microsoft documents these switches as views of the current user, groups and privileges. Microsoft whoami reference.

Do not run sudo, request elevation or switch accounts just to make the result look more interesting. A sparse token is a valid result. If Windows is unavailable, complete the synthetic exercise and label native execution not performed. These instructions were reference-checked; a macOS documentation build does not validate Windows execution.

Compare the output with the three-view table. Which facts are available? Which resource decision is still missing? A group row does not show the access rule on every remote share; a privilege row does not prove that an application action succeeded.

From relationships to a defensible path

Consider the proposed path: “Alice can edit a service configuration; that service runs as S; therefore Alice can obtain S's authority.” It contains several separate hypotheses: an effective configuration-write grant, an editable setting that changes relevant behavior, a way for the change to take effect, and execution under the claimed context. The two sentences are not proof of all four edges.

Draw each edge with observed, source-described, or unresolved next to it. Name one defensive boundary that could break the chain. This chapter teaches prerequisite reasoning; it does not perform service modification or demonstrate privilege escalation.

Evidence and acceptance

Save the six-request matrix, the two changed-fact scenarios, and a path diagram with unresolved edges. If you performed the Windows exercise, add OS version, terminal context, timestamp and redacted observations. Pass the worksheet when every allow has a specific grant and every conclusion stays within its evidence.

Safety and scope

Use your own local account or disposable Windows lab. Do not publish SID inventories or workplace directory output. The worksheet changes no machine state; the native commands require no cleanup beyond securely storing or deleting your transcript.

Teach-back

  1. How could the same account name lead to two different authorization observations?
  2. Why does a service identity need to be examined separately from the human who launched a client?
  3. Which extra evidence would turn a proposed relationship into a demonstrated path edge?
  4. Why is this six-request model insufficient to implement Windows access checks?

Continue: 03 · Kerberos and identity evidence. Directory ACLs, trusts, delegation and certificate services remain deeper chapters to develop in the coverage map.