Active Directory Architecture: Domains, Forests, Trusts, DCs

You already know one piece of this without having studied it. Anywhere you have typed a login as COMPANY\yourname, the COMPANY part is a domain, and you were naming the authority you wanted to authenticate against. This sub builds out from that small piece of familiar ground into the full structure of Active Directory, because you cannot defend a thing whose shape you cannot describe, and every later attack lives somewhere in this structure.

Active Directory is organized as a hierarchy of containers, and a small number of named pieces. Learn the pieces and how they nest, attach the security meaning to each, and the structure stops being jargon and becomes a map you can defend on. Take them from the inside out.

Domains, trees, and forests

A domain is the basic building block: a collection of users, computers, groups, and policy that share one administrative authority and one directory database, served by that domain's controllers. It has its own set of administrators, the Domain Admins, who hold full control over everything in it. The COMPANY\ in a login names the domain, and for most day-to-day purposes the domain is the unit people think in.

A domain is also a boundary for a few things worth knowing. It has its own directory database and its own replication, so changes propagate within it. It carries its own security identifier, and every account in it has a SID built on the domain's. Its policy, applied through Group Policy, is scoped to the domain. The Domain Admins group is all-powerful within that domain but, in principle, only within it; their authority stops at the domain's edge, which is exactly the boundary the rest of this sub will complicate.

A tree is what you get when domains share a contiguous namespace. If corp.com is a domain and the business adds eu.corp.com and us.corp.com beneath it, those child domains and their parent form a tree, their names nesting the way the DNS names do. Child and parent domains are joined automatically by a two-way trust, so the tree behaves, in many respects, as one connected structure.

A forest is the top of the hierarchy: one or more trees under a single definition of the directory, sharing a common schema, configuration, and global catalog. The first domain created becomes the forest root, which carries special, forest-wide significance. The forest is the largest container, and here is the single most important architectural fact in this sub: the forest, not the domain, is the real security boundary of Active Directory.

That sentence deserves unpacking, because a great deal follows from it. People instinctively treat the domain as the wall, because it has its own admins and its own name. But Microsoft is explicit that the security boundary is the forest. Within a forest, the domains share trust and infrastructure so deeply that an attacker who fully controls one domain can, through several well-known techniques, reach the others and ultimately the forest root. Defending one domain while assuming the others cannot affect it is a serious and common mistake.

It is worth being concrete about why. The forest root domain holds forest-wide groups that outrank any single domain's admins: Enterprise Admins, whose authority spans every domain in the forest, and Schema Admins, who can change the directory's very definition.

The whole forest shares one schema, one configuration, and one global catalog, and its domains are joined by transitive two-way trust. Those shared foundations are why a determined attacker in one domain has documented routes toward the forest root, and from the root toward every other domain. The domain feels like a wall, but the forest is the building.

Trusts

A trust is a relationship that lets identities from one domain or forest be accepted by another. Without a trust, two domains are strangers; with one, a user authenticated in domain A can be granted access to resources in domain B. Trusts are what make a multi-domain or multi-forest environment usable, and they are also a path an attacker travels.

Trusts come in a few kinds, and the differences matter. The trusts inside a single forest, between parent and child domains, are created automatically, are two-way, and are transitive, meaning trust flows along the chain so that everything in the forest effectively trusts everything else. Trusts between separate forests, or to external domains, are set up deliberately and can be limited: one-way instead of two, and non-transitive, so they do not automatically extend further.

Two further points repay knowing early. First, direction can be confusing: in a one-way trust, access flows opposite to the trust direction, so the trusting domain is the one exposing its resources to the trusted side. Second, there are mitigations, chiefly SID filtering, that limit what a trust will honor and blunt some cross-trust attacks, and whether they are switched on is a real defensive setting.

The practical takeaway is that trusts are not all equal: a defender taking on an environment should enumerate every trust, its direction, its type, and whether its protections are in place, before assuming the domain's edge is where exposure ends.

For a defender, the lesson is that every trust enlarges what you have to think about. A trust you set up years ago to a partner, a subsidiary, or an old domain you meant to retire is a standing route that an attacker who lands in the weaker side can try to walk into the stronger.

The strength of your domain is capped by the strength of everything it trusts, so a trust is not just a convenience to grant and forget; it is attack surface you own for as long as it exists, and worth inventorying early in a new environment.

Domain controllers and read-only controllers

Everything above is logical structure. The machines that make it real are the domain controllers. A domain controller runs the AD Directory Service, holds a writable replica of the domain's directory, and answers the authentication and authorization questions every member asks. Controllers within a domain replicate to each other constantly, so a change on one appears on all.

Because a domain controller holds the directory and the secrets that protect it, it is the most valuable machine in the domain, and it sits at the very top of tier zero. Whoever controls a domain controller controls the domain: they can read every password hash, forge any ticket, and grant themselves anything.

This is why so many of the attacks in this course are, in the end, routes to a domain controller, and why protecting controllers, limiting who can log on to them, what can reach them, and how their backups are handled, is the center of AD hardening.

It helps to be concrete about what a controller holds and does. Writable controllers use multi-master replication, so each carries a full, changeable copy of the directory and they reconcile changes among themselves. They store the password material for the whole domain, publish the Group Policy that configures members, and some act as global catalog servers holding a partial copy of every domain in the forest.

So owning a controller is not owning one server's data; it is owning the authority, the secrets, and the configuration of an entire domain at once. That is what tier zero means in practice.

A read-only domain controller is a variant built for places you cannot fully trust physically, like a branch office or a remote site. It holds a read-only copy of the directory and, by default, caches the secrets for only a limited set of accounts rather than all of them, and it cannot be written to.

The idea is that if someone steals the server from a branch closet, they get far less than they would from a full controller. It is a useful mitigation, but a partial one: an RODC still answers authentication, still holds some secrets, and is still a target, so it reduces rather than removes the risk.

The caveats are worth holding. Which accounts an RODC is allowed to cache is itself a setting that can be set too generously, and if a privileged account's secrets are cached there, a stolen RODC gives them up. An RODC also still participates in the domain, so it is a foothold, not an inert box. It is a sensible control for exposed sites, but it does not turn a branch closet into a safe place to keep a controller.

One controller role is worth naming now, because it recurs. Among the controllers, certain special duties are assigned to one controller at a time, and the most relevant to security is the primary domain controller emulator, which among other things anchors time across the domain.

Time matters more than it sounds, because Kerberos depends on clocks being roughly in sync, so the controller that governs time quietly underpins authentication itself. Misconfigure or lose that role and Kerberos can begin failing across the domain for reasons that look nothing like a clock problem, which is also why an attacker who can skew time holds a quiet lever on authentication.

Holding the map in mind

Put the pieces together and you have the frame the rest of the course hangs on. Domains are the working unit, grouped into trees by namespace, all contained in a forest that is the true security boundary. Trusts connect domains and forests, extending both usefulness and attack surface. Domain controllers serve it all and sit at the top of tier zero, with read-only controllers as a hardened variant for exposed sites.

Every attack you will study has an address in this structure. Kerberoasting happens against accounts in a domain. DCSync targets a domain controller. A trust is what carries a compromise from one domain into another. When an alert says something crossed a trust or touched a controller, you will now know what that means and why it matters, which is the difference between reading telemetry and merely seeing it.

That addressing is not academic. When you investigate, knowing whether something happened inside a domain, across a trust, or on a controller tells you immediately how serious it is and where to look next. A failed logon inside one domain is routine; the same pattern arriving across a forgotten trust from a domain you do not manage is a different story. The structure is the context that turns a raw event into a judgment.

You have the skeleton. The next sub fills it in with the objects that live inside a domain, the users, groups, computers, and service accounts you protect, the Group Policy that configures them, and the directory protocols, Kerberos and NTLM, that authenticate them. Those components are where most of the attacks actually land.