Skip to content

Module 01 — AD & Windows Security Model

Type 1 · Concept Autopsy — dissect how Windows authenticates a user, decides what they can access, and how AD structures those decisions across an enterprise, producing a from-memory map of the token/PAC/ACL model that every later attack exploits. (Secondary: Misconception Reveal — surface where auth-vs-authz and the Kerberos PAC look like features but are the seam.) Go to the hands-on lab →

Last reviewed: 2026-06

Active Directory & Windows Security — before you can attack or defend a domain, you need an accurate map of how Windows decides "yes" or "no."

Difficulty: Intermediate  ·  Estimated time: ~5–7 hrs (study + lab)  ·  Prerequisites: Foundations

In 60 seconds

Windows answers every "can this user do that?" by comparing an access token (your SID and group SIDs) against an object's security descriptor (its ACL). Active Directory scales that same yes/no across an enterprise: a Domain Controller holds the LDAP directory, Kerberos hands out tickets, and your group SIDs ride inside the ticket's PAC. Domains are replication boundaries, forests are the security boundary, and GPOs are how policy actually lands. Get this map straight and every later attack — Kerberoasting, ACL abuse, pass-the-hash — reads as a seam in a model you already understand.

Why this matters

Every Kerberos attack, every ACL abuse, every pass-the-hash scenario in this track exploits a seam in the Windows security model that looks like a feature until someone weaponises it. Attackers who understand the model find those seams; defenders who understand the model close them systematically instead of whack-a-mole. This module builds that shared map: the vocabulary and the mental model that every later lab assumes you have.

Objective

Describe how Windows authenticates a user, how it decides what that user can access, and how Active Directory structures those decisions across an enterprise — without looking at notes.

The core idea

Windows security is built on two separable concerns: authentication (proving who you are) and authorization (deciding what you're allowed to do). They interact through a single object — the access token — that Windows creates when you log in and attaches to every process you start. The token carries your SID (a unique identifier), the SIDs of your groups, and a set of privilege flags. When your process tries to open a file, pipe, registry key, or AD object, Windows compares the token against the object's security descriptor — a structured list of who can do what (the DACL) and who gets told when (the SACL). Every access decision in the OS reduces to this: does the token satisfy any ALLOW ACE in the descriptor, and does no DENY ACE come first?

flowchart LR
    T["Access token<br/>your SID + group SIDs"] --> C{"Compare against<br/>security descriptor"}
    O["Object's DACL<br/>(list of ACEs)"] --> C
    C -->|"matching DENY ACE"| D["Access denied"]
    C -->|"matching ALLOW ACE,<br/>no prior DENY"| A["Access granted"]

Active Directory extends this model to the domain. Instead of a local SAM database, a Domain Controller holds a replicated LDAP directory of every user, computer, group, and service account. Authentication flows through Kerberos (default since Windows 2000) or NTLM (fallback). In Kerberos, the Key Distribution Centre on the DC issues tickets: a Ticket Granting Ticket (TGT) proves who you are to the KDC, and service tickets (TGS) prove it to individual services. The critical insight: tickets are cryptographic blobs encrypted with the service's key, not the user's. The service decrypts it, reads your SID and group SIDs from the embedded PAC, and makes an access decision — exactly like a local token, but assembled from the ticket rather than the SAM.

sequenceDiagram
    participant C as Client
    participant KDC as KDC (on DC)
    participant S as Service (e.g. file server)
    C->>KDC: AS-REQ — prove identity
    KDC->>C: TGT (encrypted with krbtgt key)
    C->>KDC: TGS-REQ — present TGT, ask for service
    KDC->>C: Service ticket (encrypted with service's key)
    C->>S: Present service ticket
    Note over S: decrypts ticket, reads SIDs from PAC,<br/>makes the same token-vs-DACL decision

The mental model

Every access decision in Windows is the same comparison: token vs. security descriptor. A Kerberos service ticket is just that token assembled remotely — the service reads your SIDs out of the PAC the same way the kernel reads them out of a local token. Learn the one comparison and the domain version stops being a separate thing to memorise.

The organisational unit that makes this manageable at enterprise scale is the domain. A domain is a single replication boundary and trust boundary: all DCs share the same directory, and every object in the directory is identified by its distinguished name under the domain's DNS root. Domains can be grouped into forests (a forest is the outermost security boundary; a domain is a management boundary inside it). Trust relationships — transitive within a forest, explicitly configured between forests — let a user in one domain authenticate to resources in another. Every misconfigured trust is a lateral-movement opportunity.

Two structural ideas that trip people up in practice: groups vs. group types, and GPOs. Security groups accumulate SIDs into a token — being a member of Domain Admins is simply having the Domain Admins SID in your token, nothing magical about it. Distribution groups carry no SID and have no security meaning. Group Policy Objects are settings pushed to computers and users by the DC; they define password policy, audit policy, software restrictions, logon scripts, and hundreds of security controls. GPOs are the enforcement mechanism for most hardening controls — and the most common place defenders find gaps, because a GPO applied to the wrong scope or with the wrong precedence silently does nothing.

The gotcha

"Domain admin" carries no magic — it is just the Domain Admins SID sitting in your token. And a GPO that looks applied can silently do nothing: LSDOU precedence (Local, Site, Domain, OU) and the wrong scope mean a hardening policy can be linked everywhere and enforced nowhere. The seam is always "looks like a feature, behaves like a gap."

Go deeper: forest vs. domain is a security-boundary distinction, not a naming one

A common mistake is treating a domain as the security boundary. It is the management boundary; the forest is the security boundary. Transitive trust inside a forest means a compromise in any domain can reach every domain — which is why cross-forest trusts (explicit, non-transitive) matter so much for attack scoping, and why "we'll just spin up a child domain to isolate that risky app" does not isolate anything from a privilege standpoint.

AI caveat

A model is a strong Socratic tutor for this model — ask it to trace a file-share logon step by step. But the subtle parts (PAC validation, unconstrained-delegation side effects) are exactly where it confabulates, so cross-check every claim against the Microsoft Docs links below before you rely on it.

Learn (~4 hrs)

The Windows security model - Windows Internals, Part 1 — Security chapter overview (Microsoft Docs) — the authoritative reference; read the "Security" chapter intro (Chapter 7 in the book). Understand access tokens, security descriptors, and ACL evaluation order. - Access Tokens — Microsoft Docs — short and precise; this is the mechanism that every lateral-movement technique eventually subverts.

Kerberos in practice - Kerberos Authentication Explained (Computerphile, ~8 min) — the clearest visual walkthrough of TGT/TGS flow. Watch before reading the MSFT spec. - How Kerberos Works in Windows Environments (Microsoft Docs) — maps the generic Kerberos RFCs to actual DC roles and ticket fields. Focus on the PAC structure and ticket encryption.

Active Directory structure - Active Directory Domain Services Overview (Microsoft Docs) — domains, forests, OUs, trusts, sites. The foundation for understanding why things are laid out the way they are. - Understanding AD Trusts (Microsoft Docs) — the trust types and what they allow/deny. A forest trust is not the same as a domain trust and the difference matters for attacks.

Group Policy - Group Policy Overview (Microsoft Docs) — GPO processing order, WMI filters, and precedence. Pay attention to LSDOU (Local, Site, Domain, OU) — it governs which policy wins.

Key concepts

  • Access token = your identity credential at the kernel level; attached to every process you own.
  • Security descriptor = the object's policy; DACL contains ACEs that allow/deny access.
  • Kerberos TGT proves identity to the KDC; TGS (service ticket) proves identity to a specific service.
  • PAC (Privilege Attribute Certificate) carries group SIDs inside the ticket — it's how authorization data travels.
  • Domain = replication boundary + Kerberos realm; forest = security boundary.
  • Transitive trusts inside a forest mean compromise anywhere can reach everywhere.
  • GPO = the enforcement mechanism; LSDOU precedence governs which policy wins.
  • NTLM is the fallback — no KDC needed, which is why it's still exploitable decades later.

AI acceleration

Ask a model to walk you through what happens step-by-step when a domain user opens a file share: what tickets are requested, what fields are inspected, and what the file server actually checks. Then verify each claim against the Microsoft Docs links above. This is a great use of AI as a Socratic tutor — it explains at your pace — but the AD security model has enough subtle details (PAC validation, unconstrained delegation side effects) that you must cross-check against primary sources before you rely on the answer.

Check yourself

  • When a file server decides whether to grant you access, what two things is it comparing — and how is a Kerberos service ticket related to one of them?
  • Why is the forest, not the domain, called the security boundary?
  • A hardening GPO is linked at the domain root but the setting isn't taking effect on some hosts. What model explains how that can happen?

Comments

Sign in with GitHub to comment. Choose the type: Feedback (errors or suggestions on this page) · Hints (help for fellow learners — no spoilers) · General (anything else).