Active Directory Logical vs Physical Structure

You have spent this module picturing Active Directory as domains, forests, and organizational units, a neat logical model of how identity is organized. That model is real, but it is only half the picture. Underneath it runs a physical reality of actual servers in actual buildings, connected by networks that are sometimes slow, replicating to each other on a schedule. This last orientation sub is about the gap between the two, because that gap is where a surprising amount of your evidence lives and where more than one attack hides.

Active Directory keeps two structures at the same time. The logical structure is the model of domains, trees, forests, and OUs, the administrative and security organization you have been learning, and it is deliberately independent of where anything physically sits. The physical structure is the set of real domain controllers, the network locations they live in, and the replication that keeps them in step. The same directory wears both at once, and a defender has to think in both.

The logical view, briefly

You already hold the logical view, so this is just to name it as one of the two. Logically, Active Directory is domains grouped into trees by namespace, all inside a forest, with objects sorted into organizational units and policy applied through Group Policy.

None of that says anything about hardware. A domain is not a server; it is an administrative boundary that may be served by two controllers or twenty, in one building or ten. The logical model is how you reason about authority and access, and it is intentionally abstract.

The reason the logical model can stay abstract is that the physical layer takes care of making it work everywhere, and it does so through three things you should know by name: sites, replication, and the controllers themselves.

That abstraction is also why an object keeps its identity wherever it is served. A user has a security identifier and a globally unique identifier that do not change because a different controller answered the request, and its group memberships mean the same thing on every controller. The logical model is the shared truth all the physical controllers are trying to agree on, which is precisely why they have to replicate.

The physical view: controllers, sites, and replication

The controllers are the real machines. Whether they are physical servers in a rack or virtual machines in a data center, each domain controller is a host with an operating system, a location, and a set of logs, and these are the actual tier-zero assets you protect. The logical domain is an idea; the controllers are the things an attacker compromises and the things you harden, patch, and watch.

Because they are real machines, controllers carry physical risks the logical model hides. A stolen or copied controller, or a copied virtual disk, hands an attacker the directory database and the secrets in it, which is why controller backups and the virtualization platform that hosts them are themselves tier zero.

An attacker who cannot log into a controller may settle for its backup or its virtual disk and reach the same secrets by a quieter route. Protecting the directory means protecting the machines and everything that can stand in for them.

Sites represent physical locations and network topology. A site is, roughly, a part of the network that is well connected internally, usually a single building or data center, and Active Directory uses sites to send a client to a nearby controller rather than one across a slow link, and to decide how replication should flow.

Sites are defined by the IP subnets that belong to them, so a machine's address is what tells the directory which site it is in. When you see authentication described as belonging to a site, that is the physical topology showing through.

Sites exist mainly for efficiency, steering a user to a controller on their own network and keeping bulk traffic off slow links, but they carry a defensive signal too. The site an authentication appears to come from should match where the account actually is.

A logon that maps to a site the user has no business being in, or that jumps between distant sites faster than a person could travel, is the kind of inconsistency the physical topology makes visible. The same subnet-to-site mapping that routes clients efficiently also gives you a rough sense of where an authentication physically originated.

Replication is how the controllers stay in agreement. Active Directory uses multi-master replication, meaning a change can be made on any writable controller and then copies itself to the others. Within a single site, replication is fast and near-constant.

Between sites, it is scheduled and compressed to save bandwidth, so a change made on a controller in one office can take minutes, sometimes longer, to reach a controller in another. That delay is normal and designed, but it has direct consequences for a defender, which is the heart of why this sub exists.

Replication also leaves its own records, and they are useful to a defender. Every replicated change carries metadata about which controller originated it and when, so the directory itself can often tell you where a change really came from, even after it has spread everywhere. That metadata is forensic gold in an AD investigation, and learning to read it is part of the later modules. The flip side is that attacks abusing replication are trying to blend into exactly this normal, trusted flow.

Why the distinction matters for defense

The physical structure is not trivia; it changes how you investigate and what some attacks can do. Three consequences are worth carrying into the rest of the course.

The first is that evidence is per-controller. An event is logged on the domain controller that handled it, not on all of them at once. If an attacker requested a ticket from one controller, the record of that request is on that controller, and a search of a different one will not find it.

To see the whole of an intrusion you may need logs from several controllers, and an investigation that checks one and stops can miss what happened on another. This is the single most practical reason to understand the physical layer.

The practical answer most teams reach for is to forward every controller's security log to a central place, a SIEM or a collector, so the per-controller evidence is gathered into one searchable view. That does not change the underlying fact that each event was recorded on one controller, but it spares you from logging into each one during an incident.

Whether that forwarding is in place, and whether it covers every controller including the ones in branch sites, is one of the first things worth confirming, because a controller whose logs go nowhere is a blind spot exactly where you can least afford one.

A few kinds of activity also concentrate on particular controllers by role. The controller holding the primary-domain-controller-emulator role handles certain password and lockout events preferentially, so some evidence clusters there rather than spreading evenly. Knowing that a specific role draws specific events tells you which controller to check first for certain questions.

The second is replication timing. Because a change takes time to propagate, the same query against two controllers can disagree for a while, exactly as the scenario showed. In an investigation, knowing which controller saw a change first, and when, can tell you where the action originated. It also means an attacker's change is not instantly everywhere, which occasionally matters for how fast a response has to move.

There is a subtlety worth holding for investigations. The propagation delay can create a window where a malicious change is live on the controller the attacker used but not yet visible elsewhere, which is part of why some attacks aim at a specific controller. But the same replication metadata that records origin can later let you reconstruct which controller a change started on and when, turning the distributed nature of the directory from a blind spot into a source of evidence, when you know to look for it.

The third is that replication itself is an attack surface. Some of the most serious techniques in this course abuse the replication machinery directly: DCSync impersonates a controller to pull secrets through replication, and other techniques inject changes as if they were replicated, sliding past the normal logging because they masquerade as routine controller-to-controller traffic. You cannot reason about those attacks at all without the physical picture of how controllers replicate.

It is worth naming the two so the later modules land. DCSync asks the directory for secrets using the same replication request a real controller would make, so to the domain it looks like ordinary synchronization rather than theft.

DCShadow goes further and briefly registers a rogue controller, then pushes malicious changes through replication as though they were legitimate, which can sidestep the normal change logging entirely. Both are only comprehensible once you know that controllers trust each other's replicated changes by design, and that trust is the thing being abused.

Closing the orientation

That completes the map. You now hold both structures: the logical model of domains, forests, and OUs that organizes access, and the physical reality of controllers, sites, subnets, and replication that runs underneath and decides where your evidence lives. A defender who can move between the two reads telemetry with the right expectations, knows which controller to pull, and understands why a replicated change behaves the way it does.

Step back and look at the whole module. You started with what Active Directory is and why it is the most attacked thing in most enterprises. You saw its attack surface as a graph of relationships, the common paths intrusions walk through it, and the reasons securing it is genuinely hard, which is why detection has to carry so much of the defense.

Then you built the structure itself: domains, forests, and trusts; the users, groups, computers, service accounts, Group Policy, and protocols inside them; the modern reach into Entra ID, AD CS, and ADFS; and now the physical layer beneath it all. That is the full vocabulary the rest of the course assumes.

Module 1 begins the hands-on work. It turns from what Active Directory is to what its attacks leave behind: the telemetry each step writes, where that evidence sits, and the surfaces you read it on. From here on, every technique comes with its evidence and its detection, starting with the foundations of how AD authenticates and what that authentication records. You have the map. Now you learn to read the tracks on it.