Forest, domain and OU design

Give each boundary a reason

Domains within a forest share the schema, configuration and global catalog structure. An OU exists within a domain. Sites describe the physical network and can contain DCs from several domains; a domain can span many sites. Microsoft’s logical model.

Each additional forest or domain needs a reason. It brings more operational, replication and recovery work, so an organization chart on its own isn’t enough. Work out who owns the forest, how much administrative autonomy and isolation each group needs, and which systems they’ll depend on. Microsoft’s forest design process starts with those requirements.

Isolation needs a forest decision

The forest is the AD security boundary. A child domain or an empty forest-root domain does not isolate a business unit from a malicious administrator who controls the forest’s directory infrastructure. Separate forests may be appropriate when administrators must be distrusted, schemas must differ, or separation requirements demand them. Distinguish independent data administration from distrust of the directory’s service administrators. Forest design requirements.

A separate forest still needs a design for the systems that administer and connect it. Document trusts, privileged access, identity synchronization and shared dependencies. A trust supplies an authentication path; it does not merge schemas or replicate one forest’s GC into the other.

The old “empty root” model can separate administrative responsibilities, but it adds DCs, monitoring and recovery work. Be clear about the benefit before keeping or introducing it.

Design OUs around delegated work

Start with the operation: who resets which passwords, manages which computer objects, or changes which attributes? Delegate the required rights to groups, then place objects in a hierarchy that supports that ownership.

Review the same hierarchy against Group Policy needs. Workstations and servers may have different policy and administrative owners. A department-only hierarchy can make those distinctions cumbersome.

For a proposed OU, record:

• The objects it will contain and who owns them.
• The administrative groups and exact delegated rights.
• The inherited permissions and GPO links that apply.
• The effect of moving an object into or out of it.

Moving an object changes its administrative and policy context even when its identity remains the same. Review inherited ACLs, protected-account behavior and effective policy before treating an OU move as housekeeping. OUs provide delegated autonomy but do not isolate their objects from forest service administrators. OU ownership and delegation.

Inspect the delegation the design actually created

On an administrative host with the AD module and permission to read the security descriptor, inspect an existing OU against an explicit DC:

$ou = Get-ADObject -Server 'dc1.contoso.com' `
    -Identity 'OU=Workstations,DC=contoso,DC=com' `
    -Properties nTSecurityDescriptor
$ou.nTSecurityDescriptor.Access |
    Select-Object IdentityReference,AccessControlType,ActiveDirectoryRights,
        IsInherited,ObjectType,InheritedObjectType

Look at which ACEs are explicit or inherited, what operation they grant, their object-specific GUIDs and which object classes inherit them. A group with permission to edit an OU may have much more access than the password-reset task in the design document needs. Resolve unfamiliar object/extended-right GUIDs before dismissing an entry, and check who can change the delegated group’s membership.

Check where objects actually land. A new computer in the default Computers container might miss both the delegated OU and its GPO links. Try the provisioning path the helpdesk or deployment system uses as well as manually created pilot objects. Protected accounts also have a separate AdminSDHolder/SDProp ACL lifecycle, so a failed delegated task there may be expected protection.

Place DCs against an outage requirement

A local DC is useful when the business requires local authentication despite a WAN failure. Test the entire workflow: DNS, GC availability, writable-directory operations, credential availability, application dependencies and recovery access.

For an RODC, include password replication policy and the credentials actually cached. A branch with a cached user password can still depend on a remote service or a writable DC.

Set recovery and replication-convergence expectations separately for the domain, configuration/schema, DNS application partitions and GC data. “Replication works” is too broad to tell you whether the design meets them.

Size from the workload

Size from peak authentication and LDAP load, database cache behavior, available memory, CPU, disk latency and network use. Include the expected load while a DC or site is unavailable. Document capacity thresholds separately from incident-alert thresholds; reaching a growth threshold need not mean an immediate outage. Microsoft’s capacity planning guidance makes this distinction and treats capacity planning as continuous work.

The cache starts cold after a restart, so an immediate cache-hit sample is different from a warmed-up production measurement. Separate storage capacity from storage latency. A DIT that fits on disk says little about whether the server can meet an application’s response-time requirement. See DC health and performance for collection pointers.

Test the failure paths before rollout

Use an isolated lab with representative sites, partners and replication schedules. Measure convergence over the longest expected path, then repeat with a DC or link unavailable. Test the restore procedure as well as ordinary sign-in.

Test delegated administration in both directions: the operator should complete the intended task and fail to change objects outside the delegated scope. A successful password reset in the test OU only proves the first half. Repeat those checks in a controlled production pilot, with agreed acceptance and fallback criteria.

Attribution

Adapted from Microsoft Corporation, Infrastructure Planning and Design: Active Directory Domain Services, version 2.1, July 2010, under CC BY 3.0 US. Infrastructure Planning and Design is provided with permission from Microsoft Corporation. The material has been condensed and updated; historical fixed sizing numbers are omitted.