Chapter purpose
A forest, domain and trust are not just names in a console. They define security, replication, namespace and administrative boundaries.
Learning objectives
- Explain forest, domain, OU and trust in plain language.
- Identify when one forest and domain is simpler than adding boundaries.
- Explain why trust does not automatically grant access.
- Plan DNS naming before creating the first domain controller.
Why this matters in a real company
Bad directory boundaries are expensive to undo. A company that gets the logical design right can grow and delegate administration without creating unnecessary domains or forests.
1.1 Forest, domain and OU are different boundaries
A forest is the top-level Active Directory security and schema boundary. Domains live inside a forest and hold domain-specific objects such as users, groups and computers. Organizational Units live inside domains and are mainly used for delegation and Group Policy scope.
A common mistake is creating a new domain for every department. Departments usually need OUs and security groups, not separate domain boundaries. Every extra domain adds DNS, trust, replication and recovery complexity.
- Forest: highest AD boundary and shared schema/configuration.
- Domain: authentication and directory partition for domain objects.
- OU: administrative and policy container.
- Group: authorization mechanism for resource access.
1.2 Trust is recognition, not permission
A trust allows security principals from one domain or forest to be recognized across a boundary. The target resource still evaluates permissions. A trusted user is not automatically entitled to a file share, application or administrator role.
Within a forest, trust relationships are designed to make resource access across domains possible. Between forests, trust should exist because a business relationship such as a merger, shared service or migration requires it.
1.3 DNS naming is part of the directory design
Active Directory domains use DNS names. Clients use DNS service records to locate domain controllers and services, so namespace design is not cosmetic. Choose the namespace before deployment and understand how it relates to the company public DNS domain.
Avoid adding domains simply to mirror an organization chart that may change next year.
Get-ADForest
Get-ADDomain
Get-ADTrust -Filter *1.4 Design before deployment
Microsoft AD DS guidance separates design, deployment and operations. That order matters. First document requirements and boundaries, then test the design, then deploy and operate it.
Smaller organizations often benefit from a simpler design than administrators expect. Complexity should have a business reason.
- List legal and security boundaries.
- List locations and network links.
- List administrative teams and delegation needs.
- Choose forest and domain model.
- Choose DNS namespace.
- Define OU and group strategy.
- Test in a lab before production.
Security boundaries and forest thinking
A forest is not just a larger domain. It has one schema and one configuration partition shared across all domains in that forest. That means schema extensions and many forest-level configuration changes affect the whole forest. If two business units need truly independent directory control, separate forests may be justified. If they merely need different administrators for different departments, OU delegation is usually the cleaner answer.
Trust design also deserves an exit strategy. During acquisitions, trusts often begin as temporary bridges but remain for years because nobody owns removal. Document who owns the trust, which resources depend on it, how name resolution works across it, and what event allows it to be retired.
Functional levels and compatibility
Domain and forest functional levels enable certain AD capabilities and constrain which domain controller operating systems can participate. Do not raise a functional level because a wizard offers the option. First inventory every DC, confirm application/vendor dependencies, verify replication health and document rollback limitations.
The deeper lesson is that Active Directory design is lifecycle design. A forest that is easy to create but impossible to change safely is not a good design. Build for administration, recovery and future migration, not only day-one login.
Two companies merge but keep separate IT teams
Company A acquires Company B. Users need selected access to shared applications, but both IT teams need operational independence for a transition period.
Decision: Do not merge directories immediately just because ownership changed. Model the required access first, then decide whether a temporary forest trust, migration or long-term separate forest is appropriate.
Evidence: Show exact cross-forest resources, groups granted access, name-resolution path and the plan to remove or migrate the trust.
Hands-on lab
Draw a fictional company with one forest, one domain, three OUs and role groups. Redraw it with two forests and list every new dependency.
Troubleshooting exercise
- Trusted-domain user cannot access a share: prove trust, DNS, authentication and resource ACL separately.
- Application asks for a new domain: determine whether it needs a security boundary or merely an OU/service account.
- Merger creates duplicate namespaces: resolve naming and DNS design before touching trust settings.
Field checklist
- Forest/domain boundaries have a reason.
- DNS namespace documented.
- Trust direction and purpose documented.
- OU structure based on management needs.
- Resource access uses groups and ACLs.
- Temporary trusts have an exit plan.
Current technical references
The supplied PDF books are used as a historical curriculum map. Current implementation guidance is checked against current Microsoft documentation.