Active Directory Fundamentals

Domains, Trees, and Forests

The Domain: The Basic Unit

A domain is the basic administrative unit in Active Directory. Every domain has a name, such as corp.h3ad.local, and every object inside it, from a user account to a printer, is tracked in that domain's copy of the directory. When people say "the domain" in an enterprise context, they almost always mean this logical container, not a physical network segment.

Trees and Forests: The Hierarchy Above It

Domains can be organized into domain trees. If corp.h3ad.local is the root, a child domain might be emea.corp.h3ad.local. The naming convention makes the hierarchy visible at a glance, and objects in a child domain can be authenticated and referenced by objects in the parent, and vice versa, because of the automatic trust that domain tree membership creates.

A forest is the top-level container in Active Directory. Forests do not require a shared DNS namespace, which is the practical difference between a tree and a forest. An organization that acquires another company might bring its domain into the same forest as a separate tree, rather than folding it into the existing namespace, because the acquired company keeps its own domain name.

Domain Controllers Hold It Together

Every domain needs at least one domain controller. Multiple DCs in a domain replicate changes to each other so no single server is a hard point of failure for logins.

Why the Forest Is the Real Boundary

The forest, not the domain, is the actual security boundary. This trips up a lot of people early in their careers because domains look like the isolation unit: they have separate administrators, separate policies, separate password rules. But Enterprise Admins and Schema Admins groups, which live in the forest root domain, have rights that reach every domain in the forest.

Certain attack paths, like exploiting the krbtgt account or abusing trust relationships, can cross domain lines within a forest with far less friction than crossing into a different forest entirely. When you're scoping an assessment or reasoning about blast radius during an incident, think in forests first and domains second.

Organizational Units and Objects

OUs Organize the Directory

An Organizational Unit (OU) is a container inside a domain used to organize objects for administrative purposes. Unlike a security group, which exists to grant permissions or apply access control, an OU exists to structure the directory itself. It groups the Finance department's user accounts together, or all the laptops in the Chicago office, so that policy and delegated administration can target them as a set.

OUs can be nested inside other OUs, which lets organizations mirror their real-world org chart or geography inside the directory tree.

Object Types You'll Meet Daily

The main object types an analyst encounters day to day are users, computers, and groups.

• User: represents a person (or sometimes a service) that can authenticate. Carries attributes like sAMAccountName, userPrincipalName, and memberOf.
• Computer: represents a domain-joined machine and behaves a lot like a user account in the directory. It has its own security identifier and its own password, which it rotates automatically on a schedule.
• Group: a collection of other objects, used almost entirely to grant or restrict permissions in bulk rather than to assign one permission per user.

Reading a Distinguished Name

Every object in Active Directory has a Distinguished Name (DN), which describes its exact position in the directory tree using LDAP notation. A user named Priya in the Finance OU of corp.h3ad.local might have the DN CN=Priya Shah,OU=Finance,OU=Employees,DC=corp,DC=h3ad,DC=local.

Reading a DN from left to right tells you the object's common name first, then walks up through every container it sits inside, ending at the domain components. Analysts run into DNs constantly in event logs, LDAP queries, and tools like BloodHound, so being able to parse one on sight is a basic but genuinely useful skill.

Attributes That Matter in Investigations

A handful of attributes come up again and again in investigation work. distinguishedName and objectGUID uniquely identify and locate an object. memberOf shows group membership, which is central to almost every privilege question.

userAccountControl encodes flags like whether an account is disabled or whether its password never expires. adminCount, when set to 1, flags an account that is or was a member of a protected group such as Domain Admins. It is a favorite pivot point for attackers and defenders alike because it survives even after someone is removed from the protected group, unless it's explicitly reset.

Group Scope: How Far Permissions Reach

Groups themselves come in two scopes that matter for how far their permissions reach: domain local groups, typically used to grant access to resources within a single domain, and universal or global groups, which can be used across the forest.

Getting group scope wrong is a common source of "why can't this user access that resource" tickets. It's also a common source of unintended privilege when someone nests a broad group inside a narrow one without realizing the permissions travel with it.

Group Policy

What a GPO Is

A Group Policy Object (GPO) is a collection of configuration settings that gets applied to users or computers within the scope it's linked to. GPOs are how an organization enforces password complexity requirements, deploys software, maps network drives, restricts which applications can run, and configures thousands of other Windows settings without an administrator ever touching an individual machine.

A GPO exists independently in the directory until it's linked to a site, a domain, or an OU, at which point it starts actually applying to the objects inside that container.

How GPOs Apply: LSDOU Order

Policy application follows a specific order, commonly remembered by the acronym LSDOU. Settings applied later in the sequence generally win when there's a conflict, which means OU-linked policy, especially from a deeply nested OU, has the final say by default.

1. Local policy applies first. Baseline settings configured directly on the machine.
2. Site-linked GPOs apply next. Settings tied to physical location, such as proxy configuration.
3. Domain-linked GPOs apply after that. Company-wide baselines like password policy.
4. OU-linked GPOs apply last. Applied from the OU closest to the domain root down to the OU that directly contains the object, with the closest OU generally winning any conflict.

This processing order is the whole reason OU structure matters beyond just tidy organization: where you place a computer or user in the OU tree directly determines which policies actually take effect on it.

Quick reference for the same four levels:

Inheritance, Block Inheritance, and Enforced

Inheritance means a GPO linked at a parent OU automatically applies to child OUs beneath it, cascading down the tree unless something interrupts that flow. Two mechanisms interrupt it.

• Block Inheritance, set on a child OU, stops policies from parent containers from applying there.
• Enforced, set on a GPO link, forces that specific policy through even past a Block Inheritance setting further down.

Combining these incorrectly is a very common source of "why is this setting not applying" troubleshooting, and it's worth mapping out explicitly rather than guessing when policy behavior looks wrong.

GPO Abuse: A Privilege Escalation Path

GPO misconfigurations are a well-worn privilege escalation and lateral movement vector because GPOs apply with SYSTEM-level authority on the target machine, and because the permission to edit or link a GPO is itself just another set of delegated rights in the directory. If a low-privileged user or group has been granted write access to a GPO that applies to a set of servers, whether through direct delegation or through nested group membership nobody audited, that user can push a scheduled task, a startup script, or a scripted local admin group change to every machine in scope.

Tools like BloodHound explicitly map GPO edit rights alongside group membership and ACLs because this path from "can edit a GPO" to "code execution as SYSTEM on a fleet of machines" is short and frequently overlooked in access reviews.

Because GPO abuse doesn't require exploiting a vulnerability, just abusing legitimate delegated permissions, it often produces very little that looks anomalous in isolation. A new GPO link, or an edited script inside an existing one, can sit unnoticed for a long time unless an organization is specifically auditing GPO changes and the permissions structure that allows them, which is exactly the kind of gap that shows up repeatedly in real intrusion retrospectives.

Domain and Forest Trusts

A trust is a relationship that allows users authenticated in one domain to access resources in another. Trusts vary along two independent properties: direction and transitivity. Both matter a great deal when reasoning about attack paths, because together they define exactly which direction authentication, and potentially an attacker, can move.

Common Trust Types

• Parent-child trusts, formed automatically when a child domain is created under a parent in the same tree.
• Tree-root trusts, formed when a new tree is added to an existing forest.
• Forest trusts, configured explicitly between two entirely separate forests to allow limited cross-forest authentication.
• External trusts, connecting to a domain in a different forest, or even a much older Windows NT-style domain, without extending forest-wide.

Trusts Expand the Attack Surface

Trusts expand the effective attack surface across domain and forest boundaries in a way that's easy to underestimate. Even a one-way, non-transitive trust means an account compromised in the trusted domain can potentially authenticate against resources in the trusting domain. Misconfigured SID history or overly broad group membership across the trust can turn that into a much bigger foothold than the trust's designers intended.

Assessing an environment's actual security boundary means enumerating every trust relationship, not just the domains and forest an organization thinks of as "theirs."

This is exactly why real-world environments try to keep trust relationships as narrow and well-documented as possible. A forgotten trust left over from a merger, or a trust set up years ago for a project that no longer exists, is a classic finding in security assessments: nobody remembers it's there, nobody is monitoring it, and it still provides a working path between two directories.

Domain Controllers and Replication

What a Domain Controller Does

A domain controller does three jobs that make everything else in this chapter function. Every logon, every resource access check that involves Active Directory, and every GPO refresh eventually touches a domain controller in some form.

• Authenticates users and computers against Kerberos and NTLM.
• Stores and serves the directory database that describes every object in the domain.
• Applies Group Policy processing logic to whatever's requesting it.

NTDS.dit: The Directory Database

The directory database itself lives in a file called NTDS.dit, stored locally on each domain controller. It's a structured database, built on the same Extensible Storage Engine used by Exchange, that holds every object in the domain: user accounts and their password hashes, computer accounts, group memberships, GPO links, and the schema that defines what attributes any of those objects can even have.

Because NTDS.dit contains every password hash in the domain, including the krbtgt account's hash that underpins Kerberos ticket signing, getting a copy of it off a domain controller is functionally equivalent to obtaining the keys to the whole domain.

Multi-Master Replication, Step by Step

Domains typically run multiple domain controllers for redundancy, and those DCs replicate changes to each other so that a user created or a password changed on one DC eventually shows up everywhere.

1. A change is written on any DC. Active Directory uses multi-master replication, so nearly all DCs can accept writes, not just one designated primary.
2. The change gets an update sequence number. This tracks what changed and in what order.
3. The Knowledge Consistency Checker propagates it. It manages the replication topology automatically, pushing the change outward to other DCs.
4. FSMO roles handle the exceptions. A handful of specific roles are still held by exactly one DC at a time for operations that genuinely need a single point of coordination, like assigning new object identifiers or processing schema changes.

Sites Control Replication Scheduling

Sites represent physical network locations with good connectivity between machines inside them. They control replication scheduling between DCs in different locations so that replication traffic doesn't saturate a slow WAN link.

Within a site, replication happens quickly and frequently. Between sites, administrators typically configure a schedule that trades off replication latency against bandwidth usage, which means a change made on one continent might take a while to show up on a DC on another.

One DC Compromise Is a Domain Compromise

Compromising a single domain controller is often equivalent to compromising the entire domain, and this is one of the clearest lines connecting AD architecture to real incident response outcomes. An attacker with administrative access to any one DC can extract every password hash in NTDS.dit, forge Kerberos tickets using the krbtgt hash that will be trusted domain-wide, and push malicious Group Policy to every joined machine.

This is exactly why domain controllers get held to a stricter security standard than ordinary servers: no general-purpose software, no browsing from the DC, tightly restricted administrative access, and dedicated monitoring, because the blast radius of one DC going down to an attacker is the entire domain, not just one server.

Why AD Is the Primary Target

Domain Admin Is the Top Objective

Domain admin, or an equivalent level of forest-wide control, is the top objective in most enterprise intrusions that go beyond a single compromised endpoint. The reason is structural, not incidental: Active Directory is the single system that already has authority over every other system.

An attacker who reaches domain admin doesn't need to individually compromise each server, each workstation, and each service account, because AD already has a trust relationship with all of them. Ransomware operators specifically chase domain admin before deploying encryptors, because pushing the payload through Group Policy or a domain-trusted scheduled task reaches every machine at once, rather than one at a time.

This Chapter as an Attack Map

Everything covered in this chapter is also, from an offensive perspective, a map of where that authority lives and how it moves.

• OU structure and GPO linkage determine what policy, and therefore what code, reaches which machines.
• Group membership and delegated permissions determine who can edit that policy.
• Trusts determine which other domains and forests inherit some version of that authority.

None of this is a vulnerability in the traditional sense; it's how AD is designed to work, which is exactly why it's so consistently abused. Most real attack paths chain together several pieces of ordinary, intended functionality rather than a single flashy exploit.

Where the Next Chapters Go

The next two chapters build the mechanics this chapter assumes. Chapter 3 covers authentication in depth: how NTLM and Kerberos actually work, what a ticket contains, and why the krbtgt account mentioned above is so valuable. Chapter 4 covers access control directly: how permissions and ACLs determine what an authenticated identity can actually touch once it's inside the domain. Both chapters give you the mechanical detail behind concepts this chapter has only been able to gesture at.

Chapter 8, later in this module, comes back to Active Directory specifically and covers the attack techniques themselves: Kerberoasting, DCSync, golden and silver tickets, ACL abuse, and the tooling analysts use to both discover and detect these paths, including BloodHound-style attack path mapping. Everything in this chapter is the prerequisite vocabulary and structural understanding that chapter needs to land. Read Chapter 8 without this one, and terms like "OU-linked GPO" or "cross-forest trust" will be abstractions instead of a picture of the actual environment being attacked.