Domains, Trees & Forests
Part 1 covered what Active Directory is and how it works inside a single environment. Part 2 goes one level up. Once you understand how AD manages identities inside one organisation, the next question is: how does it scale? What happens when a company grows internationally, acquires another business, or needs to run separate IT environments under one roof? That is where domains, trees, and forests come in.
What is a Domain?
A domain is the fundamental unit of Active Directory. Everything in Part 1 — the Domain Controller, Kerberos authentication, Group Policy, objects and attributes — all of that lives inside a domain. Think of a domain as a single, self-contained administrative boundary.
A domain has three defining characteristics:
- A name. Every domain has a DNS name, like corp.contoso.com or london.fabrikam.com. This is not just a label — AD is deeply integrated with DNS. The domain name is how machines find the Domain Controller and how Kerberos knows where to issue tickets from.
- A boundary. Policies, permissions, and administrative control stop at the domain boundary. An administrator in one domain does not automatically have rights in another domain unless explicitly granted.
- A security boundary? Not quite. This is a common misconception. A domain is an administrative boundary, but it is not a full security boundary. A forest is the true security boundary in Active Directory — more on this shortly.
Most small-to-medium organisations run a single domain. One domain, one set of Domain Controllers, one DNS namespace. Every user, computer, and resource lives in that single domain. This is the simplest possible AD setup and perfectly sufficient for thousands of users.
What is a Tree?
A tree is a collection of domains that share a contiguous DNS namespace and are connected by automatic trust relationships. The moment you add a child domain to an existing domain, you have created a tree.
Here is what that looks like in practice. A company starts with a single domain:
- contoso.com — the root domain
- As the company grows, it creates child domains:
- europe.contoso.com — European operations
- asia.contoso.com — Asia-Pacific operations
- uk.europe.contoso.com — UK sub-division under Europe
All of these form a single tree because they share the contoso.com namespace. The shape is literally tree-like: a root domain at the top, branches spreading out below.
Trusts — How Domains Talk to Each Other
When two domains exist in the same tree, Active Directory automatically creates a trust relationship between them. A trust is exactly what it sounds like — domain A trusts that domain B has properly authenticated its users, and vice versa.
Two important properties of trusts in a tree:
- Transitive – If A trusts B, and B trusts C, then A automatically trusts C. This means users in uk.europe.contoso.com can be given access to resources in asia.contoso.com without any additional configuration — the trust chain flows through the tree automatically.
- Two-way – By default, trust runs in both directions. Users in the parent domain can be granted access to child domain resources, and vice versa. One-way trusts can be configured manually for more restrictive scenarios.
A trust does not automatically grant access — it only makes cross-domain access possible. An administrator still has to explicitly assign permissions. The trust just removes the authentication barrier.
What is a Forest?
A forest is the top-level container in Active Directory. It is a collection of one or more trees that share a common schema and Global Catalog, but do not need to share a contiguous DNS namespace.
The first domain ever created in an AD deployment becomes the forest root domain. It is a special domain — it cannot be deleted without destroying the entire forest, and it holds the forest-wide administrative roles (called FSMO roles). This is why choosing the forest root domain name carefully during initial deployment is critical — you cannot rename it later without significant effort.
The Forest as the True Security Boundary
The forest, not the domain, is where Active Directory draws the hard security line. Here is why this matters: a Domain Admin in one domain can escalate to Enterprise Admin privileges and affect the entire forest. Domain boundaries slow this down — they do not stop it.
If you need a genuine hard separation — for example, a company that has acquired a business and wants to ensure neither IT team can reach the other’s systems without explicit permission — you need separate forests. The trust between forests can then be controlled precisely, and neither side has implicit access to the other.
The Real-World Company Analogy
Abstract concepts click faster with a concrete structure. Here is how a large multinational maps to AD:
Scenario: Meridian Group
Meridian Group is a large conglomerate that has grown through acquisitions. It owns three separate businesses: Meridian Financial, a bank acquired five years ago; Meridian Logistics, built from the ground up; and Apex Technologies, a tech firm acquired last year that insisted on keeping its own IT setup during merger negotiations.
Meridian Logistics runs a single domain: meridian-logistics.com. One office, one IT team, 800 staff. Simple. No need for child domains.
Meridian Financial is more complex. Its headquarters are in London with large offices in New York, Singapore, and Frankfurt. Each region has its own IT admin team. They run a tree: meridian-financial.com as the root, with us.meridian-financial.com, apac.meridian-financial.com, and emea.meridian-financial.com as child domains. Each regional team manages their own domain. Group Policy differs by region — for example, APAC applies stricter data residency controls. But a user in London can still be granted access to a shared reporting server in Frankfurt without creating any new trust manually, because the trust flows through the tree.
Apex Technologies refused to merge their AD into Meridian’s existing structure. They run their own forest: apex-tech.internal. This is now a separate forest from Meridian Financial and Meridian Logistics. To allow specific Meridian Financial analysts to access Apex’s development tools, the IT teams created a selective forest trust — one-way, so Apex users cannot roam into Meridian’s environment without an equivalent trust being created going the other direction.
What This Means in Practice
When you understand domains, trees, and forests, you can read an organisation’s AD structure and immediately understand:
- Where the administrative boundaries are — who is responsible for what
- What cross-domain access is possible without additional configuration
- Where the genuine security perimeters are (forest boundaries)
- Why a user in one domain cannot access something in another — and exactly how to fix it
Domains, Trees & Forests
This diagram shows how a real enterprise structures Active Directory. A forest contains trees, trees contain domains, and domains contain your users and computers.
Note the separate forest at the bottom — that’s an acquired company that kept its own AD. A forest trust connects them with limited, controlled access.
A UK analyst in uk.emea.meridian-financial.com needs to read a report on a file server in us.meridian-financial.com. No new trust needs to be created. Because both domains sit in the same tree, the trust chain runs automatically: uk.emea → emea → meridian-financial.com → us. The US admin simply adds the UK user’s account to the file server’s permission list, and it works. Kerberos handles the ticket exchange transparently — the user doesn’t notice any difference from accessing a local resource.
The CISO decides that all domains must enforce a 14-character minimum password policy. She creates a Group Policy Object at the meridian-financial.com forest root and links it to the domain. Child domains inherit this policy automatically unless they override it with a higher-priority GPO linked at their own level. The APAC domain has stricter local regulations, so it applies an additional GPO requiring 16 characters — APAC users see 16 characters, everyone else sees 14. GPO precedence follows the LSDOU order: Local → Site → Domain → OU.
When Apex Technologies was acquired, its IT team refused to merge into the Meridian forest — a common condition in M&A negotiations. Instead, the two IT teams created a one-way forest trust: Meridian trusts Apex, but Apex does not trust Meridian. This means Meridian admins can grant specific Apex users access to Meridian resources. Apex users cannot access anything in Meridian’s forest unless they are explicitly added to an ACL. Apex users cannot grant Meridian users access to Apex resources — that would require a trust in the other direction.
Meridian Financial decides to deploy Microsoft Exchange across the group. Before Exchange can be installed, the Exchange setup wizard runs schema extension — it adds ~1,800 new attributes to the forest schema, including mailbox properties on user objects. This operation touches the meridian-financial.com forest root and immediately replicates to every Domain Controller across both trees. It cannot be undone. Apex’s separate forest is completely unaffected — schema changes never cross a forest boundary, which is one of the key reasons Apex insisted on keeping a separate forest during acquisition.
