Active Directory is the identity and management backbone of almost every corporate Windows network. It is the system that decides who a user is, what they are allowed to touch, and how thousands of machines agree on those answers without asking each other every time. Understanding its structure is the prerequisite for everything else in this section, because every AD attack is ultimately about abusing a feature of this design rather than a software bug.
What a directory service is
At its core, Active Directory is a database — a hierarchical one — that stores information about the objects on a network and makes that information queryable. A user, a computer, a group, a printer, a policy: each is an object with a set of attributes. The database is exposed over LDAP for queries and defended by Kerberos and NTLM for authentication.
The service that runs all of this is the Domain Controller (DC). Every domain has at least one, usually several, and they replicate the database between themselves so any DC can answer any question. Compromising a DC means compromising the database — which is why every attack path in this section is, in the end, a path to a domain controller.
The structural units
| Unit | What it is |
|---|---|
| Domain | The core administrative and security boundary — a group of objects sharing one database, one policy set, and one authentication authority (e.g. corp.target.local) |
| Tree | One or more domains sharing a contiguous namespace, linked by automatic parent-child trusts |
| Forest | The outermost boundary — one or more trees. The forest, not the domain, is the true security boundary |
| Organizational Unit (OU) | A container inside a domain for grouping objects so policy and delegation can be applied to them |
| Site | A representation of physical network topology, used to steer replication and authentication traffic efficiently |
The single most important sentence in AD security: the forest is the security boundary, not the domain. If you own one domain in a forest, you can almost always reach every other domain in that forest, because they share the schema and the configuration partition and trust the same authority. A "we'll just put the sensitive systems in a separate domain" design does not contain a breach.
Objects and their identifiers
Every object has two identity numbers that matter to an attacker:
| Identifier | Meaning |
|---|---|
| SID (Security Identifier) | The unique, immutable ID of a security principal. Windows makes access decisions on SIDs, never on names. Format: S-1-5-21-<domain>-<RID> |
| RID (Relative Identifier) | The last portion of a SID, unique within the domain. Well-known RIDs are constant: 500 is the built-in Administrator, 512 is Domain Admins |
| GUID | A globally unique ID that never changes even if the object is renamed or moved |
| DN (Distinguished Name) | The object's full path in the directory, e.g. CN=John Doe,OU=Staff,DC=corp,DC=target,DC=local |
The SID/RID relationship is why RID cycling works for enumeration: if you learn the domain SID, you can walk RIDs (1000, 1001, 1002…) to enumerate every account even when direct listing is blocked, because the SID prefix is shared and only the RID changes.
Security principals and groups
A security principal is anything that can authenticate and be
granted access: users, computers, and groups. Yes — computers are principals.
Every domain-joined machine has a machine account (shown with a
trailing $, e.g. WKSTN01$) with its own password that
rotates automatically. Machine accounts authenticate, hold privileges, and can
be abused exactly like user accounts, which is the basis of coercion and
delegation attacks.
Groups nest, and nesting is where privilege hides. The groups that matter most:
| Group | Why it matters |
|---|---|
| Domain Admins | Full control of the domain. The usual objective |
| Enterprise Admins | Full control of the entire forest — every domain in it |
| Schema Admins | Can modify the schema itself; forest-wide and rarely needed, so membership is suspicious |
| Administrators (built-in) | Local and, on a DC, effectively domain-level control |
| Account / Backup / Server Operators | Delegated privileges that frequently provide a path to full compromise |
| DnsAdmins | Historically abusable for code execution on a DC via a malicious DLL |
Nested membership is the trap. A user in "IT Support" which is a member of "Workstation Admins" which is a member of "Server Operators" is effectively privileged, and reading the top-level Domain Admins list will never reveal it. This is precisely the reasoning BloodHound automates.
The global catalog and partitions
The AD database is split into naming partitions: the domain partition (users, computers, groups), the configuration partition (forest-wide topology, replicated to every DC in the forest), and the schema partition (the definitions of every object and attribute type). The Global Catalog is a partial, forest-wide index that lets any principal search across all domains — which is convenient for users and equally convenient for an attacker enumerating a forest from a single foothold.
How authentication flows
When a user logs in, the workstation authenticates them to a DC using Kerberos (the default) or NTLM (the fallback). The DC issues proof of identity, and from then on the user presents that proof to access resources rather than re-entering a password. Two protocols, two theory pages:
- Kerberos — the modern, ticket-based default. Almost every high-impact AD attack (Kerberoasting, delegation abuse, ticket forgery) targets some part of its exchange.
- NTLM — the older challenge-response fallback. Still everywhere, and the basis of pass-the-hash and relay attacks.
Why Active Directory is so attackable
AD is not insecure because it is badly built. It is attackable because of deliberate design choices that trade security for the usability a large organisation needs:
| Design choice | Consequence for an attacker |
|---|---|
| Any user can read most of the directory | A single low-privilege credential enumerates users, groups, computers, ACLs, and policies |
| Backwards compatibility is preserved for decades | NTLM, legacy Kerberos encryption, and old protocol behaviours remain enabled and abusable |
| Delegation lets services act on users' behalf | A convenience feature that becomes impersonation when misconfigured |
| Trust is transitive within a forest | Access to one part of the forest tends to reach the whole forest |
| Rights are granted via editable ACLs | A single mis-set permission on one object can create a path to Domain Admin |
| Credentials are cached on endpoints | Compromising one workstation yields the secrets of everyone who logged into it |
Every other page in this section is a specific instance of one of these rows. Kerberoasting abuses readable service accounts. Delegation abuse exploits the impersonation feature. DCSync uses the replication trust between DCs. The fundamentals are the vocabulary; the attacks are the sentences.
The mental model to carry forward
Hold three ideas. First, everything is an object with attributes, and access is decided on SIDs and the permissions attached to those objects — so reading and writing attributes is the whole game. Second, the DC holds the database and the forest is the boundary, so every path leads there. Third, authentication produces reusable proof — tickets and hashes — and stealing or forging that proof is more productive than attacking passwords directly.
With those in place, the tooling in theToolkit Vulns & Misconfigs stops looking like a random collection of scripts and starts looking like what it is: a set of instruments for reading, writing, and forging the objects and proofs this page just described.