Learn Active Directory - Active Directory Architecture & Logical Structure
Breaking down Active Directory's logical structure: forest, domain tree, domain, organizational unit, object, and trust relationships, plus the role of the schema, global catalog, and FSMO roles in shaping the security and administration boundaries of directory services.
#Introduction
In episode 1, you understood why Active Directory exists and the problems it solves. Now it's time to unpack its logical architecture — the blueprint that determines how AD is organized, where security boundaries sit, and how objects are arranged.
Here's an analogy: picture a country. There's the nation as the highest boundary, provinces with autonomous governments, cities with day-to-day administration, and districts/villages as organizational units. Every level has its own function and authority. In AD, that hierarchy is called the forest, domain, and organizational unit.
It's important to understand from the start: the logical structure is separate from the physical infrastructure (network and servers). You can design a clean logical structure on top of a messy network — the physical topic is covered in episode 3.
#Forest
The forest is the top-level container in AD and the primary security boundary. All domains sharing one forest share three things:
- The same schema: the complete definition of the object types and attributes allowed in the directory.
- The same global catalog: a partial index of every object in the forest.
- The same Configuration container: topology, site, and service information.
The forest also has a forest functional level — the AD version that determines which features are available across the entire forest. The flip side is important to remember: if two forests don't trust each other, objects in one forest are not automatically recognized in the other. This makes the forest a security fence: problems in one forest don't spread to another.
#Domain Tree
A domain tree is a hierarchical collection of domains sharing a contiguous namespace. For example, corp.example.com as the parent with jakarta.corp.example.com as its child. This relationship automatically forms a transitive trust: if domain A trusts B, and B trusts C, then A automatically trusts C.
Why use a tree? Because a decentralized organizational structure — for example, subsidiaries with different business units — may still want to share the same forest. A tree lets domains grow hierarchically without reworking the namespace.
#Domain
A domain is the unit of administration, replication, and security policy:
- Administration boundary: domain administrators only manage their own domain, unless delegated otherwise.
- Replication boundary: all domain controllers in one domain replicate the same database among themselves; between domains, only partial data is replicated.
- Security policy boundary: password and account lockout policies apply per domain.
Domain names follow DNS, e.g. ad.example.com, and have their own domain functional level. A common rule of thumb: start with a single domain, and split into multiple domains only when there's a real need — for example, sharply different security policies or replication isolation. Every additional domain adds administrative overhead.
#Organizational Units (OU)
An Organizational Unit (OU) is a container within a domain for holding objects — users, groups, computers, even other OUs. The difference from groups: an OU is a structural container (objects live inside it), while a group is a collection of references for granting access rights.
Two main functions of an OU:
- Group Policy application: policies can be linked to an OU so they apply to all objects inside it. This is how AD centrally manages configuration.
- Administration delegation: you can grant limited authority to specific teams — for example, letting the helpdesk manage accounts in a particular OU without becoming a domain admin.
OU design should reflect organizational structure and administrative needs, not just business structure. You could create Jakarta and Bandung OUs, then Users, Computers, and Groups OUs inside each. Delegation and policies will later attach to this structure.
#Objects
Everything stored in AD is an object — an entity with attributes defined by the schema. Common objects:
| Object | Example Attributes | Function |
|---|---|---|
| User | displayName, userPrincipalName, password | Identity for a person or service |
| Computer | dNSHostName, operatingSystem | Machine account for domain-joined devices |
| Group | member, groupType | Collection of objects for access rights |
| Printer | printShareName, location | Print resource |
| Shared folder | UNCName | File sharing |
| Contact | mail, telephoneNumber | Representation without credentials |
| Service account | servicePrincipalName | Identity for services |
Every object has a unique Distinguished Name (DN), for example CN=Arman,OU=Users,DC=ad,DC=example,DC=com. This DN is the object's full address in the hierarchy — you'll encounter it often when working with PowerShell and LDAP.
#Trust Relationships
A trust is a bridge of trust between two domains or forests that lets users on one side be recognized by the other. Here are the trust types:
| Trust Type | Scope | Characteristics |
|---|---|---|
| Parent-child | Between domains in a tree | Automatic, two-way, transitive |
| Tree-root | Root domain with other domains in a forest | Automatic, two-way, transitive |
| External | Two domains in different forests | Manual, can be one-way, non-transitive |
| Forest | Two forests | Manual, can be transitive |
| Shortcut | Two domains whose trust path crosses forests | Manual, shortens the authentication path |
| Realm | AD forest with non-Windows Kerberos | Manual, integration with heterogeneous systems |
Trusts are useful, but don't treat them as free: every trust expands the trust surface. As a principle, only create a trust when business needs genuinely call for it, and restrict its direction and transitivity.
#Schema, Global Catalog, and FSMO Roles
Three mechanisms "bring the logical structure to life":
- Schema: the master template defining all object types and attributes, plus the rules governing them. The schema is forest-wide and highly sensitive — schema changes affect the entire forest and can almost never be undone.
- Global Catalog (GC): a partial index of all objects across the forest. It's crucial for user logon (especially universal group membership) and cross-domain searches. Every forest must have at least one GC.
- FSMO Roles: five "single-master" roles that ensure certain operations don't conflict in a multi-master architecture. Two are forest-wide (Schema Master and Domain Naming Master) and three are domain-wide (PDC Emulator, RID Master, Infrastructure Master). Placing and failing over these roles is important for stability, and will be covered in detail in a related episode.
#Logical vs Physical Structure
Everything in this episode is logical structure: a design outcome representing your organization — forest, domain, OU, objects, trust. In contrast, physical structure concerns the real infrastructure: network sites, subnets, and where domain controllers are placed. The logical and physical structures can be completely different — you can have one domain (logical) spread across ten offices (physical).
This separation is one of AD's strengths: organizational decisions aren't bound to the network, and network decisions don't change the logical structure.
Once your lab is up, you can start the logical structure by creating a simple OU with New-ADOrganizationalUnit:
New-ADOrganizationalUnit -Name "Users" -Path "DC=ad,DC=example,DC=com"
New-ADOrganizationalUnit -Name "Computers" -Path "DC=ad,DC=example,DC=com"
New-ADOrganizationalUnit -Name "Groups" -Path "DC=ad,DC=example,DC=com"#Conclusion
In episode 2 you've mastered AD's logical map: the forest as the security boundary, the domain as the administration and replication boundary, the OU as the organizational unit and policy application point, objects as managed entities, trusts as bridges of trust, and the schema, global catalog, and FSMO roles as supporting mechanisms.
Key takeaways:
- The forest is the security boundary; the domain is the administration, replication, and policy boundary.
- Start with a single domain; split only when there's a real need.
- OUs are where Group Policy and delegation attach; design them according to administrative needs.
- Logical structure is separate from physical structure — two different things that complement each other.
In the next episode, we move to the physical side: Active Directory physical structure — sites, subnets, site links, domain controller placement, and how replication works within and between sites. That's where the logical structure you designed meets the real network!