Active Directory / Basic / Lesson 2
Domains, forests, and functional levels
Separate logical and administrative boundaries from controller operating-system versions, then reason about feature prerequisites without performing a promotion or level change.
On this page
Lesson goals
- Explain forest-wide schema/configuration and domain partitions.
- Distinguish domain boundaries from complete security isolation.
- Apply a declared functional-level compatibility model.
A forest groups domains under shared directory foundations
A forest contains one or more domains sharing schema, configuration, and forest-wide search capabilities. Domains within the forest have automatic transitive trust relationships, but resources still perform authorization. A domain is a directory partition and an administrative/account organization, not a physical site. One domain can span several sites, and one site can contain controllers for more than one domain. Adding a domain should solve a justified requirement rather than imitate an organizational chart. More domains create operational and recovery dependencies that need ownership, evidence, and testing before an approved design becomes a deployment plan.
Operating system and functional level are different dimensions
A controller’s Windows Server release describes its operating system. Domain and forest functional levels govern available directory capabilities and supported controller combinations, not the operating systems of every joined client. Microsoft’s current table distinguishes the 2016 and 2025 functional levels; Windows Server 2019 and 2022 do not introduce levels named after themselves. Raising a level is not an ordinary way to repair a logon incident. Identify all controller versions and feature prerequisites first. This course’s compatibility example is a limited projection of the reviewed table, not a tool that inventories or modifies a real forest.
allowed = {2016: {2016, 2019, 2022, 2025}, 2025: {2025}}
print(2025 in allowed[2016])
print(2022 in allowed[2025])
print(all(version in allowed[2025] for version in [2025, 2025]))
True
False
True
The outputs are True, False, and True. This model checks only listed controller OS membership, not every upgrade prerequisite or support-lifecycle condition.
A separate domain is not automatic isolation from forest control
Forest-wide administrators and shared directory foundations make the forest an important security boundary. A child domain can distribute administration but does not create a fully independent adversarial-security boundary from forest control. OUs provide finer delegation inside a domain, not a new forest. Trust direction, resource permissions, and administrative control should be documented separately. A design that requires isolation from an untrusted administration may need another architecture and a formal risk review. Do not promise that a new domain or trust solves that requirement merely because the names look separate in a directory tree.
List assumptions and blockers before selecting a target
The contextual record separates the proposed forest level, domain level, and controller inventory. It is a planning fixture, not valid configuration to import or execute. A real change review also needs schema compatibility, application support, backups, replication health, rollback limitations, and organizational approval. Some features require an additional optional-feature decision even after a level prerequisite is met. Avoid treating the maximum modeled level as a universal recommendation for an existing environment. The highest compatible design depends on the complete supported system, not one server’s newly installed operating system.
{"forest":"ad.example.test","forest_level":"2016","domain_level":"2016","controller_os":["2022","2025"],"change_state":"review_only"}
The record keeps OS and functional levels separate. It changes no directory level and supplies no live compatibility or recovery evidence.
Test the decision against the whole environment
A safe review checks the actual inventory and Microsoft’s applicable compatibility guidance, then validates supported application behavior and recovery in an authorized isolated environment. A Python membership test cannot prove a schema extension, optional feature, or live controller is compatible. Document the review date because product support and guidance can change. Keep level changes separate from routine object edits in the change process. When an incident begins after a change, record the exact boundary that changed instead of saying only that Active Directory was upgraded. That distinction narrows investigation without guessing which system property is responsible.
Common errors and fixes
A 2022 functional level is assumed to exist.
- Why it happens
- Server release names were copied into directory-level names.
- How to fix it
- Use Microsoft’s actual functional-level matrix.
- Prevent it next time
- Record OS, schema, and levels as separate fields.
A child domain is promised as complete forest isolation.
- Why it happens
- Administrative organization was confused with a security boundary.
- How to fix it
- Review forest control and the real isolation requirement.
- Prevent it next time
- Include security ownership in logical design reviews.
A level is raised to troubleshoot a routine sign-in failure.
- Why it happens
- A high-impact capability change replaced evidence-based diagnosis.
- How to fix it
- Investigate the failing authentication dependencies first.
- Prevent it next time
- Require a separate approved plan for level changes.
Check your understanding
1. The proposed 2025-level fixture contains one 2022 controller. What does the model report, and what does it not authorize?
Show worked solution
The listed compatibility test fails because 2022 is not in the model’s allowed 2025-level set. This flags a planning blocker only. It does not authorize removing, replacing, demoting, or upgrading any controller, and it does not certify a recovery path. Gather the actual inventory and an approved migration design before any operational decision.
2. Two offices share one domain but require different replication schedules. Explain why a second domain is not the first conclusion.
Show worked solution
Physical locality and replication connectivity are modeled through sites, subnets, and site links, while a domain is a logical directory partition. Review those topology requirements before adding a domain. A second domain introduces additional account, trust, policy, and recovery complexity and should follow a justified logical requirement rather than substitute for site design.
Key takeaways
- Keep logical boundaries separate from physical topology.
- Functional levels are not controller OS labels.
- Compatibility review is not authorization to change a forest.