Active Directory Architecture

Almost every enterprise on earth runs identity through one design Microsoft shipped in 2000. Learn its shape — forests, domains, trusts, replication — and you stop seeing a confusing pile of acronyms and start seeing the map an attacker walks. The architecture is the attack surface.

Active Directory is two things wearing one name. To an admin it’s the directory that holds every user, computer and group in the company, and the machinery that lets people log in once and reach everything they’re allowed to. To an attacker it’s a graph: a connected set of accounts, machines and trust relationships where, if you can find the right edge, one foothold on a forgotten workstation walks all the way to everything. The difference between those two views is mostly about understanding the architecture — so that’s where we start. Here is the whole logical model in one picture, top to bottom:

The logical model: forest, tree, domain, OU

AD has two structures laid over the same servers: a logical one you design (forest, domains, OUs) and a physical one that follows your network (sites, links, replication). The logical model is where identity and policy live, so start there.

At the top is the forest. A forest is the collection of one or more domains that share a single schema (the master definition of every object class and attribute that can exist), a single configuration partition (sites, replication topology, services), and a single Global Catalog. There is exactly one schema for the whole forest. That sharing is exactly why the forest — not the domain — is the real security boundary, a point we’ll come back to with teeth.

Inside a forest, domains are organised into trees. A tree is a set of domains that form a contiguous DNS namespace: corp.com at the top, emea.corp.com and sales.corp.com beneath it. The moment you grow a child under a parent, AD wires up a two-way trust between them automatically — that’s how the tree stays one logical unit. A forest can hold more than one tree with completely different names (say corp.com and acquired-co.net) joined at the root; each separate namespace is its own tree, and a tree-root trust stitches them together.

A domain is a partition of the directory and an administrative + replication boundary. Each domain holds its own users, computers and groups, replicates its own slice of the database among its own domain controllers, and has its own domain administrators. Splitting an org into multiple domains used to be about replication cost over slow links and delegating admin authority — but here is the single most important sentence in this whole article: a domain is not a security boundary; the forest is. Domain admins in a child domain can, by design, escalate to control the entire forest. People who get that backwards build “secure” multi-domain designs that aren’t.

Below the domain sit Organizational Units (OUs) — containers you nest to mirror your org or geography. OUs are where you delegate administration (“the helpdesk can reset passwords in the Sales OU”) and, crucially, where you link Group Policy. OUs are not security boundaries either; they’re for management. Every leaf in this tree — a user, a computer, a group — is an object, an instance of a class defined in the schema, identified by a globally unique distinguished name like CN=Alice,OU=Sales,DC=corp,DC=com.

# the forest: root domain, schema/forest functional level, domain list
PS> Get-ADForest
  Name                  : corp.com
  RootDomain            : corp.com
  ForestMode            : Windows2016Forest
  Domains               : {corp.com, emea.corp.com, sales.corp.com}
  GlobalCatalogs        : {DC01.corp.com, DC02.emea.corp.com}
  SchemaMaster          : DC01.corp.com
  DomainNamingMaster    : DC01.corp.com

# this domain: its DN, mode, and the three domain-level FSMO holders
PS> Get-ADDomain
  DistinguishedName     : DC=corp,DC=com
  NetBIOSName           : CORP
  DomainMode            : Windows2016Domain
  PDCEmulator           : DC01.corp.com
  RIDMaster             : DC01.corp.com
  InfrastructureMaster  : DC01.corp.com

Domain controllers and AD DS

A domain controller (DC) is a Windows Server promoted to run Active Directory Domain Services (AD DS) — the role that actually is the directory. Everything else in AD is a client of the DCs: workstations authenticate against them, servers check group membership against them, Group Policy is pulled from them. Lose your DCs and you lose the company’s ability to log in.

The directory database lives in one file on each DC: NTDS.dit, under %SystemRoot%\NTDS\. It’s an ESE database holding every object — and, fatally interesting, every account’s password material (NTLM hashes, Kerberos keys). Alongside it is SYSVOL, a replicated file share (%SystemRoot%\SYSVOL\) that carries Group Policy objects and logon scripts to every machine in the domain. Two stores, two replication mechanisms — AD DS replication for the database, DFSR (formerly FRS) for SYSVOL.

AD DS uses multi-master replication: every DC in a domain holds a writable copy of that domain’s partition, and a change made on any one of them propagates, store-and-forward, to all the others until they converge. There’s no single “primary” you must write to. That design is great for resilience — but it has a sharp security consequence. Because DCs legitimately replicate directory data (including secrets) to each other over a protocol called DRSUAPI, anyone who can impersonate a DC asking for a replica can pull every credential in the domain. That’s exactly the DCSync attack, and the architecture is what makes it possible.

# every DC in the domain (multi-master — all are writable)
PS> Get-ADDomainController -Filter * | ft Name,Site,IsGlobalCatalog,OperatingSystem

# the privileges DCSync abuses live in the domain ACL, not on a box:
#   DS-Replication-Get-Changes  +  DS-Replication-Get-Changes-All
# with them, ask a DC to "replicate" the krbtgt secret — like a DC would
$ impacket-secretsdump -just-dc-user CORP/krbtgt 'CORP/[email protected]'
# or from a Windows foothold:
PS> mimikatz "lsadump::dcsync /domain:corp.com /user:krbtgt"

Trusts: how one domain reaches into another

A trust lets accounts from one domain be authenticated and authorised in another. Without trusts, each domain is an island. With them, a user in emea.corp.com can open a share in corp.com, because the resource domain trusts the account domain to vouch for the user. Two properties define every trust, and you must read both: direction and transitivity.

Direction answers “who trusts whom.” A trust is fundamentally one-way: if domain B trusts domain A, then A’s users can be granted access to B’s resources — but not the reverse. The arrow of trust points from the resource (trusting) side to the account (trusted) side; access flows the opposite way. A two-way trust is just two one-way trusts back to back. Transitivity answers “does the trust chain forward?” A transitive trust means if A trusts B and B trusts C, then A effectively trusts C. A non-transitive trust stops at the two domains named and goes no further.

The trust types matter because they have different defaults and different blast radii:

Parent-child and tree-root trusts are created automatically when you build the forest and are always two-way transitive — that’s what makes a forest behave as one connected identity fabric. External and realm trusts are manual and default to non-transitive, so they’re the tightest. A forest trust is the big one: it joins two complete forests, and because each side is internally transitive, a forest trust effectively connects every domain on one side to every domain on the other (modulated by SID filtering and selective authentication).

For an attacker, the trust map is a movement map. A trust direction you can travel and a misconfiguration on the far side — an over-broad foreign group membership, SID history that survives filtering, a Kerberos ticket forged with a trust key — turns a foothold in one domain into access in another. Trusts are why “we segmented into separate domains” rarely buys the isolation people think it does.

# every trust this domain has: name, direction, type, transitivity
PS> Get-ADTrust -Filter * | ft Name,Direction,TrustType,IntraForest,DisallowTransivity

# the classic, still-everywhere way to see and verify trusts
PS> netdom query trust /domain:corp.com
PS> nltest /domain_trusts /all_trusts /v

# attacker view — BloodHound ingests trusts and shows the reachable path
$ bloodhound-python -d corp.com -u alice -p '***' -c Trusts,DCOnly -ns 10.0.0.1

The physical model: sites, subnets and replication

The logical model says nothing about where machines physically are. That’s the job of the physical model — and AD learns the physical world from sites and subnets. A site is a region of well-connected (LAN-speed) network; you define it by associating one or more IP subnets with it. A client uses its own IP to figure out which site it’s in, then finds the nearest DC in that site. Sites are how AD keeps logons local and keeps slow WAN links from being hammered.

Replication then has two flavours. Intra-site replication — between DCs in the same site — is frequent, uncompressed, and notification-driven: a change triggers replication within seconds because bandwidth is assumed cheap. Inter-site replication — across site links you define — is scheduled and compressed to conserve WAN bandwidth, so changes can take longer to converge. The component that builds and maintains this whole replication topology automatically is the Knowledge Consistency Checker (KCC): it runs on every DC, computes the intra-site connections, and (via the Inter-Site Topology Generator role per site) wires up the inter-site connections through chosen bridgehead servers.

Why a defender — and an attacker — cares: replication is convergence over time, not an instant database. Disable an account or change a password and there’s a propagation window where some DCs still hold the old state (the PDC Emulator gets urgent updates to soften this, but the window is real). Attackers exploit it to find a lagging DC; defenders use repadmin to confirm a critical change has actually reached every DC before declaring an incident contained.

# replication summary across the whole forest — look for failures/lag
PS> repadmin /replsummary

# who replicates what to this DC, and when it last succeeded
PS> repadmin /showrepl DC01

# sites, subnets and which DC lives where
PS> Get-ADReplicationSite   -Filter * | select Name
PS> Get-ADReplicationSubnet -Filter * | ft Name,Site

# force convergence after a containment action — don't wait on schedule
PS> repadmin /syncall /AdeP

The Global Catalog

Each domain only fully knows its own objects. So how does a user in one domain find or log on against objects across the forest? The Global Catalog (GC). A GC is a DC that, on top of a full writable copy of its own domain, holds a partial, read-only replica of every domain in the forest — just the most-searched attributes of every object. It’s the forest-wide index.

The GC does the heavy lifting for cross-domain life. Universal group membership is resolved against it at logon (in a multi-domain forest, an incomplete GC can break logons). Forest-wide LDAP searches — “find this user anywhere” — hit the GC on TCP 3268 (and 3269 for LDAPS) instead of the per-domain LDAP port 389. The User Principal Name ([email protected]) you type at login is resolved through the GC. For an attacker doing reconnaissance, the GC is a gift: a single server that will happily enumerate accounts and groups across the whole forest at once.

FSMO roles: where multi-master needs a single master

Multi-master replication is wonderful until two DCs make conflicting changes to something that must be globally unique. AD solves this with FSMO — Flexible Single Master Operations — five special roles, each held by exactly one DC, that serialise the operations you can’t safely do in parallel. Two are forest-wide (one per forest); three are domain-wide (one per domain).

The PDC Emulator is the one you notice if it dies: it’s the authoritative time source the whole domain (and Kerberos) chases, it gets password changes immediately so a just-reset password works everywhere, and it’s the default target for Group Policy edits. For the attacker, FSMO holders are prime targets — but the deeper point is that the Schema Master and RID/PDC roles, and the accounts that can seize them, are textbook Tier-0: control them and you control the forest.

# forest-wide roles
PS> Get-ADForest | select SchemaMaster, DomainNamingMaster
# domain-wide roles
PS> Get-ADDomain | select PDCEmulator, RIDMaster, InfrastructureMaster

# the old reliable, all five at once
PS> netdom query fsmo

AD’s hard dependency on DNS

Here’s a fact that surprises people: Active Directory cannot function without DNS. AD doesn’t use DNS as a nicety — it uses it as the locator service that lets clients find DCs at all. When a DC is promoted it registers a pile of SRV records in DNS that advertise its services: _ldap._tcp.dc._msdcs.corp.com for the directory, _kerberos._tcp.dc._msdcs.corp.com for the KDC, and site-scoped variants so a client finds a nearby DC. A client logging in doesn’t magically know where a DC is — it asks DNS.

So if AD-integrated DNS breaks or is tampered with, the symptoms look like AD is down: domain joins fail, logons hang, Group Policy stops applying. And that tight coupling is also an attack surface — poison or spoof the records that tell a client which DC to trust (or abuse name-resolution fallbacks like LLMNR/NBT-NS when DNS misses) and you can steer authentication toward a machine you control.

# the SRV records every client query depends on
PS> nslookup -type=SRV _ldap._tcp.dc._msdcs.corp.com
PS> nslookup -type=SRV _kerberos._tcp.dc._msdcs.corp.com

# confirm a DC registered its records correctly
PS> dcdiag /test:dns /v

# Linux side — same SRV lookup
$ dig +short SRV _ldap._tcp.dc._msdcs.corp.com

Why the architecture is the attack surface

Now put it together. Everything above isn’t trivia for a cert exam — it’s the reason a single compromised laptop can become “the entire company.” Three structural facts decide your blast radius.

First: the forest is the security boundary, not the domain. Because every domain in a forest shares one schema, one configuration, and a trust fabric that’s transitive by construction, a sufficiently privileged account in any domain can pivot to control the forest root — and from there, everything. If two business units truly must be isolated, that’s a reason for separate forests, not separate domains.

Second: trusts are lateral movement, drawn in advance. Every trust edge is a path identity can travel. A forest trust to a partner, a leftover external trust to a decommissioned domain, SID history that survives filtering — each is a road an attacker maps with BloodHound and walks if the far side is weaker than yours.

Third: a thin layer of objects is Tier-0 — and owns the rest. Domain Controllers, the krbtgt account (whose key signs every Kerberos ticket — steal it and forge a Golden Ticket), the replication rights that enable DCSync, the FSMO holders, AD-integrated DNS. Compromise of any Tier-0 asset is effectively compromise of the directory. The whole point of the tiered administration model (Tier 0 = identity/DCs, Tier 1 = servers, Tier 2 = workstations) is to make sure Tier-0 credentials never touch a Tier-2 box where a phish can grab them.

The map, at a glance