Active Directory structure is rarely reviewed carefully until the environment outgrows its initial setup and the day-one decisions start creating support tickets. Understanding the active directory structure before you build it is what separates environments that stay manageable from the ones that become a maintenance burden two years later.
The logical model is a hierarchy: forests contain domain trees and domains, domains contain OUs and directory objects. Each layer solves a different operational problem, and getting the purpose wrong (especially for OUs) is one of the most common structural mistakes in SMB environments. If you’re starting from zero, What Is Active Directory? covers the fundamentals before this article picks up.
- For most SMB and homelab environments, start with one forest and one domain
- The forest is the security boundary in AD DS; a domain is a directory partition and replication boundary
- Domain trees matter mainly in multi-domain forests
- OUs are for GPO scope and delegated administration, not resource permissions
- Security groups control access to files, printers, and applications
- Sites and subnets describe the physical topology, not the OU hierarchy
- Audit accidental-deletion protection and enable AD Recycle Bin before you need it
What Is Active Directory Structure?
Active Directory structure is the hierarchy that organizes directory data and defines where authentication, replication, Group Policy, and delegated administration are scoped. A forest contains one or more domain trees and domains; domains contain OUs and directory objects. AD sites, subnets, and domain controllers form the separate physical topology used for replication and client location.
The forest is the outermost boundary. Everything inside it shares one schema, one configuration partition, and a forest-wide global catalog namespace. The domain is where authentication happens and where most objects live. OUs sit inside domains and exist to organize objects for administration.
Knowing what each layer is for matters more than memorizing the diagram.
Logical vs Physical Active Directory Structure
The logical structure consists of forests, domain trees, domains, OUs, groups, and directory objects. It determines how data, policy, authentication, and administration are organized.
The physical side of the active directory structure consists mainly of sites, subnets, site links, and domain controllers. It determines how clients locate domain controllers and how replication traffic moves across the network. A site is not contained inside an OU or domain in the same way an OU is contained inside a domain; it describes network topology, not object placement.
Operators conflate the two more often than you’d expect. A site does not apply a GPO the way an OU does (GPOs can be linked to sites, but that is a different scope with different processing order), and moving a domain controller between sites changes replication behaviour, not delegation. For the replication and DC-location side of the design, see the AD Sites and Services guide and Microsoft’s site topology design documentation.
Active Directory Structure at a Glance
| Component | Primary purpose | Scope |
|---|---|---|
| Forest | Security boundary, shared schema and configuration | One or more domain trees and domains |
| Domain tree | Domains sharing a contiguous DNS namespace | Inside a forest |
| Domain | Authentication, directory partition, replication | Inside a forest |
| OU | GPO targeting and delegated administration | Inside one domain |
| Site | DC location and replication topology | Physical network topology |
| Security group | Authorization and resource access | Membership-based |
What Is an Active Directory Forest?
The forest is the top-level logical boundary. It’s not a server; it’s a logical container that defines the outer limit of trust, schema, and configuration. Microsoft’s documentation on the AD DS logical model describes the forest as the security boundary of the Active Directory environment.
Every forest shares one schema. If you extend the schema during an Exchange or Configuration Manager installation, that extension affects every domain in the forest. There is no per-domain schema, which is why schema extensions get planned rather than improvised.
The forest also provides a forest-wide global catalog namespace for locating objects across domains. One or more domain controllers can be configured as global catalog servers. Each GC server stores a full replica of its own domain and a partial replica of objects from the other domains in the forest.
What the Forest Contains
| Component | Scope | Notes |
|---|---|---|
| Schema | Forest-wide | Defines object classes and attributes; shared across all domains |
| Configuration partition | Forest-wide | Sites, subnets, site links, and service data replicate to every DC |
| Global catalog | Forest-wide namespace | Hosted by one or more GC-enabled domain controllers |
| Domains | Contained in forest | One or more; each is a partition and replication boundary |
| Trusts | Inside and between forests | Two-way transitive trust exists between all domains in the same forest |
For most SMB and homelab deployments, one forest is the right starting point for the active directory structure. Multiple forests exist for mergers and acquisitions, regulatory separation, or situations where two organizations need to stay structurally independent while sharing limited resources.
A second forest can provide a genuine security and administrative boundary, because the forest (not the domain) is the primary security boundary in AD DS. That isolation comes with significant operational overhead: separate DC infrastructure, trust configuration, identity lifecycle duplication, and cross-forest tooling. A separate forest should be introduced only when the requirement cannot be satisfied through OUs, delegation, administrative tiering, or other controls inside the existing forest.
Where Domain Trees Fit
A domain tree is one or more domains that share a contiguous DNS namespace. For example, ad.example.com and europe.ad.example.com belong to the same domain tree. A forest can contain more than one tree when domains use different DNS namespaces but still share the forest schema, configuration, global catalog, and transitive trust relationships.
Most SMB environments run one forest with one domain, so the forest, tree, and domain look like the same layer in practice. The distinction matters mainly in multi-domain forests, and it shows up in conversations about DNS delegation and namespace planning rather than day-to-day administration.
What Is an Active Directory Domain?
A domain is a directory partition, authentication scope, and replication boundary inside a forest. Domain controllers replicate the domain naming context with other domain controllers in the same domain. A domain also provides a scope for administration and policy, but it is not an independent security boundary from administrators who control the forest.
Objects that belong to a domain: user accounts, computer accounts, security groups, service accounts, and Group Policy Objects. Authentication is domain-scoped, so when a user logs in, a domain controller in their domain processes the Kerberos ticket. The domain name becomes part of every user’s UPN suffix by default.
DNS Naming for a New Domain
For a new deployment, use a DNS namespace that your organization controls, commonly a dedicated subdomain such as ad.example.com. Existing .local domains keep working, but they create additional considerations for Microsoft 365, certificate issuance from public CAs, and user principal names. Naming decisions belong in the deployment phase, not in a later restructuring project.
One Domain Is the Default Starting Point
Historically, large organizations used multiple domains to manage replication across slow WAN links. That constraint is mostly gone: modern replication handles bandwidth through site topology configuration, which is a physical-design concern rather than a domain-design concern.
Multiple domains today add administrative complexity without proportional benefit. Each domain needs its own domain controllers, GPO management crosses domain boundaries awkwardly, authentication can require cross-domain referrals, and inter-domain trusts introduce their own failure modes.
One domain is the default starting point for most SMB and homelab environments. Add another domain only when a documented requirement cannot be satisfied with OUs, delegation, sites, or a separate forest.
What Is an Organizational Unit (OU)?
An OU is a container inside a domain. You create OUs to organize objects (users, computers, groups) into logical groupings for two specific purposes: applying Group Policy and delegating administrative permissions.
That’s the complete definition of what an OU is for. It’s not a security boundary. It’s not a permissions mechanism. It’s an administrative organization tool.
When you link a Group Policy Object to the Workstations OU, every computer in that OU processes the policy. When you delegate the Reset Password permission to a help desk group on the Users OU, that group can reset passwords for every user in that OU. Those are the two jobs OUs do well. They don’t do permissions on file shares, and they don’t control access to a network printer.
OUs vs Security Groups: A Common Confusion
This is the active directory structure mistake that causes the most ongoing trouble in SMB environments. Both OUs and security groups can contain users, which creates the false impression that they’re interchangeable.
| OU | Security group | |
|---|---|---|
| Purpose | Administration scope | Resource access control |
| Used for | GPO targeting, delegation | File share permissions, printer access, application authorization |
| Membership | Determined by object placement | Explicit membership assignment |
| In Kerberos token | No | Yes, group SIDs are included at logon |
| Affects resource access | No | Yes: NTFS permissions, share permissions, application ACLs |
A pattern that surfaces repeatedly in inherited AD environments: the Finance team sits in a Finance OU, and someone has tried to grant that OU access to the finance file share. The assignment appears to succeed in the GUI, but users report they can’t reach the share.
Windows resource permissions are evaluated against security group membership carried in the Kerberos token. OUs are not represented in that token. The access fails without a useful error, which is why operators usually burn an hour on share permissions and DFS namespaces before questioning the OU itself. The fix is a security group with the same members.
Use security groups for resource authorization. Use OUs for object placement, GPO scope, and delegated administration. Using one for the other’s job doesn’t fail loudly. It just doesn’t work, which is worse.
Recommended Structure for a Small Environment
Complexity should come from actual requirements, not from over-engineering because something “might be needed later.” Environments that end up with twelve layers of nested OUs and three domains usually started small and grew without design intent. Rationalizing that later is a multi-day project with GPO and delegation fallout.
As an operational guideline, keep the OU hierarchy as shallow as the delegation and GPO requirements allow. Two or three levels are usually sufficient for an SMB, but this is a design heuristic rather than a hard AD limit. Every level you add is another layer of inheritance to trace when a policy stops applying.
For OU hierarchy patterns, delegation models, and GPO scope planning, the Active Directory OU Design guide covers those decisions in full, and Group Policy in Active Directory covers how the OU hierarchy and GPO scope interact during processing. Microsoft’s OU design guidance outlines how depth affects delegation and inheritance.
Default Containers Are Not the Same as OUs
The built-in CN=Users and CN=Computers containers are not organizational units. You cannot link a GPO directly to them, which means every account left in a default container silently misses the policy set the rest of the environment receives.
In a managed active directory structure, create dedicated OUs for users and computers, move existing objects, and consider redirecting the default locations for newly created accounts and joined computers. The redirection commands and the rest of the day-one work belong in the AD Post-Install Checklist.
Protecting and Recovering OUs From Accidental Deletion
Deleting an OU does not move its child objects to the LostAndFound container. If a tool or script performs a recursive deletion, the OU and its child objects are deleted and represented in the hidden Deleted Objects container. The LostAndFound container is used for orphaned objects created by conflicting directory operations during replication, not as the normal destination for deleted OUs.
If Active Directory Recycle Bin was enabled before the deletion, deleted objects retain the attributes needed for a substantially complete restore. Without Recycle Bin, recovery may require an authoritative restore from a valid domain controller backup, performed on a system that is authenticating the entire environment.
New OUs created with New-ADOrganizationalUnit are protected from accidental deletion by default unless the setting is explicitly disabled. Modern management tools also normally create new OUs with protection selected. Do not assume the entire directory is protected, however: inherited and legacy OUs, along with some built-in containers, may still have the setting disabled. Audit the current state rather than trusting the default.
- Audit existing OUs for
ProtectedFromAccidentalDeletion; do not assume legacy OUs are protected - Enable Active Directory Recycle Bin before an incident occurs; it cannot restore objects deleted before the feature was enabled
- Identify the exact deleted OU in Active Directory Administrative Center or with
Get-ADObject -IncludeDeletedObjects - For nested deletions, restore the parent OU before child OUs and their objects
- If Recycle Bin was not enabled, follow a tested authoritative-restore procedure using a valid system-state backup
- After recovery, validate group memberships, GPO links, delegation ACLs, and application references
# List deleted OUs first, before restoring anything
Get-ADObject `
-IncludeDeletedObjects `
-Filter 'ObjectClass -eq "organizationalUnit"' `
-Properties lastKnownParent,msDS-LastKnownRDN |
Select-Object Name,ObjectGUID,lastKnownParent
# Restore one verified OU by ObjectGUID
Get-ADObject `
-IncludeDeletedObjects `
-Identity "GUID-HERE" |
Restore-ADObjectFor a deleted hierarchy, restore the parent OU before restoring child OUs and objects. Use Active Directory Administrative Center when the recovery scope is unclear; piping an unreviewed filter straight into Restore-ADObject restores more than you expect and gives you a second cleanup problem on top of the first.
Verification Commands
After building or inheriting an environment, these commands give a current-state summary of the active directory structure: forest configuration, domain properties, and OU layout. Running them on first login to an unfamiliar domain is standard practice before making any changes.
# Forest summary
Get-ADForest |
Select-Object Name,ForestMode,RootDomain,Domains,GlobalCatalogs,
SchemaMaster,DomainNamingMaster
# Domain summary
Get-ADDomain |
Select-Object DNSRoot,DomainMode,PDCEmulator,RIDMaster,
InfrastructureMaster
# OU inventory and protection state
Get-ADOrganizationalUnit -Filter * `
-Properties ProtectedFromAccidentalDeletion |
Select-Object Name,DistinguishedName,ProtectedFromAccidentalDeletion
# Find unprotected OUs
Get-ADOrganizationalUnit -Filter * `
-Properties ProtectedFromAccidentalDeletion |
Where-Object { -not $_.ProtectedFromAccidentalDeletion } |
Select-Object Name,DistinguishedName
# Create a new OU with the intended protection state stated explicitly
New-ADOrganizationalUnit `
-Name "Servers" `
-Path "DC=ad,DC=example,DC=com" `
-ProtectedFromAccidentalDeletion $trueGet-ADForest returns the forest functional level, the schema master FSMO holder, the GC server list, and the domains in the forest. That output alone tells you whether the environment matches the diagram someone handed you. Get-ADOrganizationalUnit -Filter * gives the full OU tree as Distinguished Name paths, which shows exactly how deep the structure goes without opening ADUC.
-ProtectedFromAccidentalDeletion $true is shown explicitly so the intended state is visible in the deployment script, even though New-ADOrganizationalUnit protects new OUs by default.
FSMO role placement, DC promotion, and site link scheduling are separate design decisions and are out of scope here. This article covers the logical hierarchy and how its layers are meant to be used.
Inherited-Environment Check
Taking over an existing domain, in practice, starts with the same five questions every time. Answer them before proposing any restructuring.
- Count forests and domains with
Get-ADForest; confirm the diagram matches reality - Export the OU tree as Distinguished Names and look at actual hierarchy depth
- Find OUs without accidental-deletion protection
- Identify objects still sitting in
CN=UsersandCN=Computers, since no GPO is reaching them - Review delegated ACLs and GPO links before moving a single object
Common Active Directory Structure Mistakes
The list below reflects practical investigation priority, the order most likely to surface real problems fastest in an inherited environment, not a statistical ranking.
Too many domains. Adding a child domain for a department is rarely the right call in an SMB. It doubles the DC infrastructure requirement and adds a trust relationship that becomes another failure mode. If the driver is administrative separation, a delegated OU usually achieves it. If the driver is a true security boundary, the relevant conversation is about a separate forest.
Deep OU hierarchies. A six-level structure that made sense to the engineer who designed it becomes unmaintainable within twelve months of that engineer leaving. Inheritance through deep nesting is difficult to audit, and Block Inheritance and Enforced flags scattered through the tree make it worse.
OUs used for permissions. Covered above. It fails silently, which is why operators lose the most time here: nothing in the interface indicates the assignment was meaningless.
Objects left in default containers. Accounts created quickly during onboarding land in CN=Users, receive no OU-linked policy, and stay invisible until an audit or a security incident finds them.
Assuming protection is universal. New OUs are protected by default, but inherited ones may not be. The audit takes one command. The recovery takes an evening.
Delegation without ACL review. Delegating permissions on an OU writes Access Control Entries to that OU’s security descriptor. Restructuring the hierarchy or changing group membership later doesn’t clean those ACEs. Privilege drift accumulates quietly.
Frequently Asked Questions
What is the Active Directory hierarchy?
The active directory structure puts the forest at the top, followed by one or more domain trees, then domains, then OUs, then objects such as users, computers, and groups. Sites, subnets, and domain controllers sit alongside this as the physical topology rather than inside it. Most SMB environments only ever see three of those layers in practice: one forest, one domain, and a handful of OUs.
What is the difference between a forest, tree, and domain?
A forest is the outermost boundary and holds the shared schema, configuration, and global catalog namespace. A domain tree is a set of domains sharing a contiguous DNS namespace, such as ad.example.com and europe.ad.example.com. A domain is a directory partition and replication boundary inside the forest. In a single-domain environment all three describe the same thing, which is why the terms get used interchangeably until someone builds a second domain.
Is an Active Directory domain a security boundary?
No. The forest is the security boundary in AD DS. A domain is an administrative, authentication, and replication scope, but administrators who control the forest can reach into any domain within it. If the requirement is true isolation between two organizations, the design question is about a separate forest, not another domain.
What is the difference between an OU and a security group?
OUs scope Group Policy and delegated administration. Security groups control resource authorization. OUs don’t appear in a user’s Kerberos token, so file share, printer, and application permissions cannot reference OU membership. This isn’t a preference; it’s how the authorization model works.
How many forests and domains does a small business need?
Most small and midsize environments should begin with one forest and one domain. Additional domains are justified only by documented requirements such as distinct domain-level administration, replication design, legacy constraints, or complex organizational models. If the requirement is a true security boundary, a separate forest, not merely another domain in the same forest, is usually the relevant design decision.
Are the default Users and Computers containers OUs?
No. CN=Users and CN=Computers are containers, not organizational units, and you cannot link a GPO to them directly.
What happens when an OU is deleted?
The OU and the objects underneath it are deleted and represented in the hidden Deleted Objects container, not moved to LostAndFound. With AD Recycle Bin enabled beforehand, deleted objects keep the attributes needed for a substantially complete restore, and you restore the parent OU before its children. Without Recycle Bin, you’re looking at an authoritative restore from a domain controller backup.
Bottom Line
Most structural problems in Active Directory aren’t design failures. They’re the result of environments that grew without a design: users left in default containers, OUs accumulated without a consistent hierarchy, permissions applied to whatever container was convenient at the time.
A workable active directory structure isn’t complicated. One forest, one domain, a shallow OU tree, security groups for access control, and verified deletion protection before the first user account lands. The layers exist to answer different questions, and the environments that stay maintainable are the ones where each layer is still answering the question it was designed for.
The next step after structure is deployment: How to Install Active Directory on Windows Server 2025 covers the process from ADDS role installation through forest creation.
Active Directory Series
16 articles — Windows Server 2025 · Forest & Domain · FSMO · GPO · Replication · DNS · Backup & Recovery