Building an AD DS Forest the Right Way: Deployment, FSMO, and a Tiered Admin Model

Active Directory is still the identity backbone for the majority of enterprises, and still the single most attractive target for an attacker. A forest clicked together through the promotion wizard in 2014 and never re-architected is a credential-theft playground: one phished helpdesk laptop, one mimikatz run, one over-privileged service account, and the attacker owns every domain controller in the estate. Active Directory Domain Services (AD DS) is the on-premises directory that authenticates users, authorizes access, publishes DNS, and distributes Group Policy — and because it is the root of trust for everything, the way you lay it out matters more than any single feature you turn on.

This guide stands up a forest the way it should be done in 2026: designed on paper before a VM boots, scripted with Install-ADDSForest rather than clicked, replicated across at least two domain controllers, with Flexible Single Master Operation (FSMO) roles placed deliberately, DNS integrated correctly, an OU tree built for least-privilege delegation, and — the part that actually contains a breach — carved into Microsoft’s Tier 0 / Tier 1 / Tier 2 administrative model so a compromised workstation can never harvest a domain admin’s credentials. We cover the design decisions (single vs multi-domain, the forest as the true security boundary, functional levels, the schema), the deployment mechanics (promotion, replica DCs, sites, subnets, site links, DNS), and the hardening (tiering, clean source, Privileged Access Workstations, authentication policy silos, Protected Users, Windows LAPS, AdminSDHolder, legacy-protocol removal) — every option and trade-off, with the exact PowerShell and the dcdiag/repadmin command to prove it worked.

By the end you can justify a single-forest / single-domain design to an architecture review, promote a forest without leaking a DSRM password on a command line, place all five FSMO roles where they belong and seize them when a DC dies, design an OU tree that both targets Group Policy and enforces the tier boundary, and deploy the tiering controls that turn Active Directory from a lateral-movement superhighway into a segmented network an attacker cannot traverse. This is the difference between a forest that works and one that survives the day someone clicks the wrong link.

What problem this solves

The problem is not “how do I install Active Directory” — the wizard does that in ten minutes. The problem is that the ten-minute install produces a flat, monolithic trust boundary in which every domain administrator’s credentials are exposed on every machine they log into, every service account with Domain Admins rights is one stolen password away from forest compromise, and every default (unconstrained delegation, NTLM everywhere, SMBv1, cached credentials on workstations) is the least-secure option. An attacker’s entire playbook against Active Directory — pass-the-hash, pass-the-ticket, Kerberoasting, DCSync, Golden Ticket, unconstrained-delegation abuse, AD CS ESC escalations — depends on a credential from a lower-trust system being usable to control a higher-trust one. That is exactly the property a tiered design removes.

What breaks without this: a helpdesk technician’s workstation is compromised by commodity malware; the attacker dumps LSASS and finds a domain admin’s cached NTLM hash because that admin RDP’d in yesterday to fix a printer; the attacker replays the hash to a domain controller, runs DCSync to steal every credential in the forest including krbtgt, and forges a Golden Ticket for persistent, near-undetectable domain dominance. Every step in that chain is blocked by a single architectural rule — a higher-tier credential must never be exposed on a lower-tier host — enforced by logon restrictions, authentication policy silos, and Protected Users. Tiering does not stop the initial workstation compromise; it stops the compromise from escalating past the tier boundary, which is what turns a contained incident into a full forest rebuild.

Who hits this: essentially every organization running Active Directory, still the overwhelming majority even in a cloud-first world (Entra ID syncs from, or federates back to, an on-premises forest for most of them). It bites hardest on estates that grew organically — the forest that started as one domain, sprouted three more for acquisitions, accumulated two hundred over-privileged service accounts, and has a Domain Admins group with forty members who all log on to their daily-driver laptops. Rebuilding trust boundaries in a live forest is genuinely hard; getting them right on greenfield is cheap. This article gets them right the first time, and gives the migration target for the estates that did not.

To frame the whole scope before the deep dive, here is every design and hardening decision this article covers, the wrong-by-default state it corrects, and the section that handles it:

Learning objectives

By the end of this article you can:

• Justify a single-forest / single-domain design and articulate precisely why the forest, not the domain, is Active Directory’s only true security boundary — and enumerate the handful of legitimate reasons to add a second domain or forest.
• Choose forest and domain functional levels correctly, explain what each level unlocks (AD Recycle Bin, claims, PAM trusts), and know why you can raise but never lower them without a rebuild.
• Promote a forest with Install-ADDSForest and add replica DCs with Install-ADDSDomainController without ever leaking the DSRM password, and explain every parameter and its gotcha.
• Design a sites / subnets / site-links replication topology that matches physical reality so the KCC builds sane connections, clients authenticate locally, and inter-site traffic is compressed and scheduled.
• Place all five FSMO roles deliberately, verify placement with netdom query fsmo, and transfer them gracefully or seize them (one-way, with metadata cleanup) when a role holder dies.
• Build an OU tree that both targets Group Policy and enforces the tier boundary, and delegate granular rights with dsacls so privileged groups (Domain Admins, Enterprise Admins, Schema Admins) stay empty.
• Deploy the Tier 0/1/2 administrative model end to end — clean source, PAWs, authentication policy silos, Protected Users, and User-Rights-Assignment logon-deny GPOs — and explain the one-directional control rule that makes it work.
• Harden the forest with Windows LAPS, AdminSDHolder auditing, SMBv1 removal, SMB signing, and NTLM audit-then-deny, and verify the whole build with dcdiag /v /c /e and repadmin /replsummary.

Prerequisites & where this fits

You should be comfortable with Windows Server administration, PowerShell (scripts, secure strings, Get-/Set- cmdlets), TCP/IP and DNS fundamentals (A/PTR/SRV records, forwarders), and the basic AD vocabulary — users, groups, computers, OUs, GPOs, and the idea of a domain controller. You do not need prior forest-design experience; that is what this article builds. A lab with two Windows Server 2022/2025 VMs (Server Core preferred) lets you follow the hands-on sections.

This is a foundational Servers / Identity article, upstream of almost everything else in the track. Active Directory Domain Services Forest Design and Domain Controller Promotion on Azure IaaS covers the Azure-specific angle and pairs directly with this one. Once the forest exists, Group Policy at Scale: A Maintainable Architecture and Managing GPOs as Code manages the settings the tier model depends on, and Eliminating Static Service Credentials with gMSA and Windows LAPS keeps service accounts and local-admin passwords out of reach. The PKI you will deploy — Building a Two-Tier AD CS PKI: Offline Root and Enterprise Issuing CA — is itself a Tier 0 system inside the boundary this article draws, and Diagnosing AD Replication and FSMO Failures with repadmin and dcdiag is the troubleshooting companion. On-premises AD DS is the source of authority Entra ID connects to; the same least-privilege thinking extends into the cloud via Privileged Identity Management and PAM Architecture: Just-in-Time Access at Scale and the Zero Trust Architecture Blueprint: Identity, Network, and Data Pillars. A quick map of who owns what during a forest build and incident:

Core concepts

Six mental models make every later decision obvious. Internalize these before the deployment commands; each is expanded in its own deep section.

The forest is the security boundary; the domain is not. People add domains believing they get isolation — they do not. Every domain in a forest shares one schema, one configuration partition, one Enterprise Admins group, and automatic two-way transitive trusts, so anyone who compromises the schema or a DC in any domain can pivot to every domain. The only container that stops a compromise spreading is the forest (with, at most, a selective-authentication external trust). Consequence: add a domain for administrative/replication convenience, never for security; add a forest for genuine isolation (a red-forest/ESAE admin forest, a hostile-tenant separation, a regulatory island).

One-directional control is the whole tiering idea. Partition every identity and system into three tiers by what they control: Tier 0 controls identity (DCs, AD CS, the directory database); Tier 1 controls servers and apps; Tier 2 controls workstations. The rule is asymmetric — a higher tier may administer lower-tier assets, but a lower-tier credential must never control a higher tier, and a higher-tier credential must never be exposed on a lower-tier host. A Tier 0 admin who RDPs from their laptop drops their credential where Tier 2 malware can grab it, collapsing the whole model. Tiering is a credential-exposure control first, a permissions control second.

Clean source is the precondition tiering rests on. A system’s security depends on the security of everything that controls it. If a Tier 0 DC is a VM whose host is managed by Tier 2 admins, built from media on a Tier 2 share, or patched by a Tier 2 tool, then Tier 2 effectively controls Tier 0 and the tiering is fiction. Clean source means the build media, management plane, virtualization host, backup system, and accounts that touch a Tier 0 asset must themselves be Tier 0.

FSMO roles are single-master exceptions to multi-master replication. Most objects can change on any DC and replicate out; five operations are too sensitive for concurrent edits and are held by one DC at a time — two forest-wide (Schema Master, Domain Naming Master), three per-domain (RID Master, PDC Emulator, Infrastructure Master). Placement, planned transfer, and emergency seizure are deployment-critical: a lost RID Master eventually stops account creation, a lost PDC Emulator breaks time and password chaining.

Replication follows topology you must describe. The Knowledge Consistency Checker (KCC) builds the connection graph automatically, but intelligently only if you tell it where DCs and clients live via sites (locations), subnets (IP ranges → sites), and site links (WAN paths with cost and schedule). Describe reality and you get near-immediate intra-site replication, compressed scheduled inter-site replication, and local-DC authentication; leave it blank and clients cross the WAN while replication ignores your bandwidth.

The build is proven by tools, not by “it seemed to work.” dcdiag (per-DC health) and repadmin (replication status, latency, queue) are ground truth. A forest is not deployed until dcdiag /v /c /e passes every test on every DC and repadmin /replsummary shows zero failures. Everything here ends at those two commands.

The vocabulary in one table

Pin down every moving part before the deep sections. The glossary at the end repeats these for lookup; this is the mental model side by side:

Design decisions before you touch a server

The most expensive mistakes in Active Directory are made on paper, before the first DC is promoted, and they are effectively permanent — you cannot rename a forest cleanly, lower a functional level, un-extend a schema, or collapse a multi-domain forest without a migration project. Get these right first.

Forest and domain count

Default to a single forest with a single domain; deviate only for a documented hard requirement. Multiple domains do not buy security isolation (the forest is the boundary) — they buy replication complexity, a larger Tier 0 surface (every domain has its own Domain Admins and DCs to protect), cross-domain reference maintenance, and SID-history/trust headaches. Additional trees (non-contiguous namespaces in the same forest) are almost never justified — a naming convenience, not an isolation feature. Reach for a second forest only for genuine isolation: an administrative/red forest for Tier 0 (ESAE), separation from a hostile/untrusted environment, or a regulatory island that must not share a schema or trust.

The decision matrix — match your requirement to the smallest structure that satisfies it:

A note that kills the most common “we need multiple domains” argument: Fine-Grained Password Policies (FGPP), available since the 2008 domain functional level, let you apply different password/lockout policies to different security groups within a single domain. Before FGPP, one-password-policy-per-domain forced multi-domain designs; that reason is gone. Do not carry it forward.

DNS namespace

Choose an internal DNS namespace that is a delegated subdomain of a public domain you own — for example ad.example.com or corp.example.com when your public presence is example.com. This avoids two classic disasters:

Pick a short, stable NetBIOS name (the pre-Windows-2000 down-level name, ≤ 15 characters, e.g. EXAMPLE) that will never need to change — it is baked into SIDs and legacy references and is genuinely hard to alter later.

Functional levels

The forest functional level (FFL) and domain functional level (DFL) set the feature floor, gated by the lowest-version DC you run. On greenfield in 2026 with Server 2022/2025 DCs, set both to Server 2016 (WinThreshold in PowerShell) — the practical, well-supported floor that unlocks the AD Recycle Bin, claims/DAC, PAM trusts, and modern Kerberos. You can raise a level once every DC supports it but never lower it without a rebuild, so raise deliberately and only when no older DC will ever be introduced. The ladder — note Microsoft stopped adding new DFL/FFL features after 2016, so 2019/2022/2025 DCs simply run at the 2016 level:

Two rules that save pain: the AD Recycle Bin cannot be disabled once enabled — enable it (a top safety net), but know it is one-way; and Server 2025 adds new functional levels for the first time in years — do not raise to Win2025 until every DC is Server 2025 and you have a reason, because it is irreversible and locks out older DCs.

The schema

The schema is the blueprint of every object class and attribute, with exactly one schema per forest held on the Schema Master. Extensions (new attributes/classes) are how Exchange, Windows LAPS, and Configuration Manager integrate, performed by adprep (/forestprep, /domainprep) or product tools run as Schema Admins. Two properties make the schema a change-control matter, not a casual operation:

Check the current schema version before any change so you can prove what happened:

# objectVersion of the schema NC tells you the base schema level
Get-ADObject -Identity (Get-ADRootDSE).schemaNamingContext `
  -Properties objectVersion |
  Select-Object objectVersion
# e.g. objectVersion 88 = Server 2019 schema; each newer Server release raises it further

OU strategy (decide it now, build it in step 5)

Decide before promotion that you will not administer objects in the default CN=Users and CN=Computers containers, because you cannot link a GPO to a container — only to an OU (or a site, or the domain root). Plan an OU tree that separates accounts, servers, workstations, and service accounts, with the tier model baked in. This is a design decision now (it dictates your delegation and GPO strategy) and a build step later.

Callout: CN=Users and CN=Computers are containers, not OUs — no GPO link, limited delegation. Redirect default object creation into real OUs with redirusr and redircmp right after promotion so nothing important lands somewhere you cannot apply policy.

Promoting the first DC with Install-ADDSForest

Build the first DC from a clean, fully patched, statically addressed Server Core install where possible — smaller attack surface, fewer patches, no local browser to phish. Set the hostname, static IPv4 address, and DNS client before promotion (promotion makes it a DNS server). Never build a DC from media staged on a lower-tier system — clean source applies from the first byte.

Install the role binaries:

Install-WindowsFeature -Name AD-Domain-Services -IncludeManagementTools

Create the forest. Never pass the DSRM password in plaintext on the command line (it lands in history and transcripts) — prompt for it as a secure string:

$dsrm = Read-Host -AsSecureString -Prompt "DSRM password"

Install-ADDSForest `
  -DomainName "ad.example.com" `
  -DomainNetbiosName "EXAMPLE" `
  -ForestMode "WinThreshold" `
  -DomainMode "WinThreshold" `
  -InstallDns:$true `
  -DatabasePath "C:\Windows\NTDS" `
  -LogPath "C:\Windows\NTDS" `
  -SysvolPath "C:\Windows\SYSVOL" `
  -SafeModeAdministratorPassword $dsrm `
  -NoRebootOnCompletion:$false `
  -Force:$true

Every parameter, what it actually does, and where people get burned:

The DC reboots and comes up as the forest root, holding all five FSMO roles and acting as a global catalog and DNS server. Immediately redirect default object creation and confirm health:

# Redirect new users/computers out of the default containers into real OUs
# (run after you create the OUs in step 5; shown here for sequence)
redirusr "OU=Users,DC=ad,DC=example,DC=com"
redircmp "OU=Workstations,DC=ad,DC=example,DC=com"

# Sanity-check the brand-new DC
dcdiag /v
Get-ADDomainController -Server localhost |
  Select-Object Name, Site, IsGlobalCatalog, OperationMasterRoles

Replica DCs, IFM, and the global catalog

A single DC is not a deployment — it is an outage waiting to happen, and worse, a single point at which an accidental snapshot revert triggers a USN rollback that quietly corrupts replication. Add at least one replica DC before you go live; two is the floor, and for anything beyond a lab you want a DC in each site.

On the second server (static IP; DNS client pointing at the first DC, then adding itself), install the role and promote it into the existing domain:

Install-WindowsFeature -Name AD-Domain-Services -IncludeManagementTools

$cred = Get-Credential   # EXAMPLE\ an account with rights to add a DC
$dsrm = Read-Host -AsSecureString -Prompt "DSRM password"

Install-ADDSDomainController `
  -DomainName "ad.example.com" `
  -Credential $cred `
  -InstallDns:$true `
  -SiteName "Default-First-Site-Name" `
  -DatabasePath "C:\Windows\NTDS" `
  -LogPath "C:\Windows\NTDS" `
  -SysvolPath "C:\Windows\SYSVOL" `
  -SafeModeAdministratorPassword $dsrm `
  -NoGlobalCatalog:$false `
  -Force:$true

Key replica-promotion parameters and choices:

Install From Media (IFM) matters for remote sites: rather than replicating the whole directory and SYSVOL live across a thin link, generate an IFM set from an existing DC, copy it to the new server, and promote from it so only the delta replicates over the wire:

# On an existing DC: create an IFM set (full, includes SYSVOL)
ntdsutil "activate instance ntds" "ifm" "create sysvol full C:\IFM" quit quit
# Copy C:\IFM to the new server, then promote with -InstallationMediaPath C:\IFM

Global catalog placement is a real design lever. A GC holds a partial, read-only replica of every object in the forest and is required for logon (universal-group expansion), UPN resolution, and forest-wide searches. In a single-domain forest, make every DC a GC — no downside, and it removes an entire class of “logons fail because the only GC is down” incidents; in a multi-domain forest GC placement interacts with the Infrastructure Master (below). GC facts worth knowing:

Sites, subnets, and replication topology

The KCC builds the replication graph, but it only makes good decisions if you describe physical reality with three objects: sites (locations), subnets (IP ranges → sites), and site links (WAN paths with cost and schedule). Skip this and every client may authenticate against a random (possibly cross-WAN) DC, and replication ignores your bandwidth entirely.

Create sites, map subnets, and tune the inter-site link:

# Create sites for two physical locations
New-ADReplicationSite -Name "HQ-East"
New-ADReplicationSite -Name "DR-West"

# Associate IP subnets with each site (clients/DCs in these ranges belong to that site)
New-ADReplicationSubnet -Name "10.10.0.0/16" -Site "HQ-East"
New-ADReplicationSubnet -Name "10.20.0.0/16" -Site "DR-West"

# Create/tune the inter-site link: interval in minutes, cost reflects bandwidth (lower = preferred)
New-ADReplicationSiteLink -Name "HQ-DR" -SitesIncluded "HQ-East","DR-West" `
  -Cost 100 -ReplicationFrequencyInMinutes 15

# Move a DC into its correct site
Move-ADDirectoryServer -Identity "DC2" -Site "DR-West"

The three topology objects and how to reason about each:

Intra-site vs inter-site replication behave very differently, and the difference drives your site design:

Two mechanisms worth knowing: site-link bridging is transitive by default (a change can flow A→B→C without a direct A→C link) — disable bridge all site links only for a genuinely non-transitive network you’ll manage manually; and a bridgehead server (the DC per site that handles inter-site replication for a partition) is auto-selected by each site’s ISTG (Inter-Site Topology Generator) — let it, unless you have a specific reason to pin one.

Verify replication after any topology change — this is non-negotiable:

repadmin /replsummary          # zero failures, low largest-delta
repadmin /showrepl             # per-partition inbound replication status
repadmin /queue                # nothing backing up
Get-ADReplicationSubnet -Filter * | Select-Object Name, Site   # every subnet mapped

DNS integration: the plumbing AD lives on

Active Directory cannot function without DNS — clients locate DCs by querying SRV records (_ldap._tcp.dc._msdcs.<domain>, _kerberos._tcp.<site>._sites.<domain>, and friends), so DNS misconfiguration presents as “authentication is broken” even when the directory is perfectly healthy. Integrate DNS the AD-native way: keep zones AD-integrated (stored inside AD, replicated with directory replication, so every DC is a writable DNS server); leave the _msdcs forest-wide locator zone (created as a separate application partition on the first DC) alone; and require secure-only dynamic updates so only authenticated, domain-joined machines can register — stopping a rogue host from hijacking a DC’s name. The DNS design choices that matter for a forest:

The most commonly botched setting is in that table: do not point a DC’s DNS client solely at itself — on boot it can fail to locate replication partners before its own DNS service is ready (the “island” problem). Point each DC’s primary DNS at a peer DC and its secondary at itself.

# Require secure-only dynamic updates on the AD zone
Set-DnsServerPrimaryZone -Name "ad.example.com" -DynamicUpdate "Secure"

# Enable scavenging server-wide and on the zone
Set-DnsServerScavenging -ScavengingState $true -RefreshInterval 7.00:00:00 -NoRefreshInterval 7.00:00:00
Set-DnsServerZoneAging -Name "ad.example.com" -Aging $true

# A conditional forwarder (e.g. to an Azure Private DNS resolver for privatelink zones)
Add-DnsServerConditionalForwarderZone -Name "privatelink.database.windows.net" `
  -MasterServers 10.30.0.4

# Confirm the critical locator records exist
Resolve-DnsName -Type SRV "_ldap._tcp.dc._msdcs.ad.example.com"

For a full high-availability DNS/DHCP treatment (zone replication scopes, DHCP failover, split-scope), see Highly Available DNS and DHCP on Windows Server, End to End.

FSMO roles: placement, transfer, and seizing

Five FSMO roles are single-master exceptions to multi-master replication — two forest-wide, three per-domain. Where they live, and how you move or seize them, is deployment-critical.

Check current placement first:

netdom query fsmo
# or, richer:
Get-ADDomain  | Select-Object InfrastructureMaster, RIDMaster, PDCEmulator
Get-ADForest  | Select-Object SchemaMaster, DomainNamingMaster

Placement guidance

The defensible defaults for a small-to-mid single-domain forest:

The Infrastructure Master ↔ Global Catalog interaction is the classic multi-domain trap: the IM updates renamed/moved cross-domain references, but a GC already holds a partial copy of every object and so a GC-hosted IM sees nothing as “stale” and silently stops (cross-domain members show as SIDs). Rule: in a multi-domain forest where not all DCs are GCs, the IM must sit on a non-GC DC; if every DC is a GC (the single-domain recommendation), it is a no-op.

Transfer vs seize

Transfer is graceful, for when both DCs are online (maintenance, decommission, load balancing); seize is break-glass for a permanently dead holder that will never return.

# Graceful transfer (source DC is healthy) — move some or all roles to DC2
Move-ADDirectoryServerOperationMasterRole -Identity "DC2" `
  -OperationMasterRole SchemaMaster,DomainNamingMaster,RIDMaster,PDCEmulator,InfrastructureMaster

To seize, add -Force — one-way, and dangerous if the old holder ever comes back:

# Seize (ONLY when the old holder is dead and will be wiped)
Move-ADDirectoryServerOperationMasterRole -Identity "DC2" `
  -OperationMasterRole PDCEmulator,RIDMaster -Force

The decision is simple: transfer (no -Force) for anything planned while both DCs are online; seize (-Force) only when the holder is permanently dead, after which you wipe it and run metadata cleanup; and if a holder is merely temporarily down and will return, wait — seizing a returnable DC risks split-brain, and seizing the Schema or RID Master is the riskiest of all.

The resurrection trap. If you seize roles from a dead DC, that DC must never come back online holding the old roles. Wipe it and perform metadata cleanup (now automatic when you remove a DC via Remove-ADDomainController or the console; the manual path is ntdsutil → metadata cleanup), which purges the dead server’s objects from the directory. Resurrecting a former FSMO holder — or reverting a DC from a VM snapshot — creates a USN rollback / split-brain that is genuinely painful to untangle and can silently break replication for weeks. Never snapshot-revert a DC; use VM-GenerationID-aware safeguards on hypervisors that support them and restore from proper system-state backups instead.

Metadata cleanup after an ungraceful DC loss:

# Preferred: remove the dead DC's metadata (run on a healthy DC)
Remove-ADDomainController -Identity "DeadDC1" -ForceRemoval -Server "DC1"
# (If that path is unavailable, ntdsutil "metadata cleanup" is the manual equivalent.)

OU structure and delegation for least privilege

Now design the OU tree to serve both Group Policy targeting and the tier model, and delegate rights so that the built-in privileged groups stay empty. A workable top-level layout:

ad.example.com
+-- Tier0                     (identity control plane)
|   +-- Accounts              (DC admins, Tier 0 service accounts)
|   +-- Groups
|   +-- Devices               (domain controllers moved here, Tier 0 PAWs)
+-- Tier1                     (server control plane)
|   +-- Accounts              (server admins)
|   +-- Groups
|   +-- Servers               (member servers, sub-OUs by role)
|   +-- PAWs                  (Tier 1 admin workstations)
+-- Tier2                     (workstation control plane)
|   +-- Accounts              (helpdesk / desktop admins)
|   +-- Groups
|   +-- PAWs                  (Tier 2 admin workstations)
+-- Users                     (standard user accounts)
+-- Workstations              (standard user devices)
+-- ServiceAccounts           (gMSAs, tier-scoped sub-OUs)
+-- Groups                    (application/resource groups)

Why this shape and not the org chart: structure OUs by administration and policy, not department. GPOs, delegation, and the tier boundary all key off the OU tree, so it should mirror how you administer and secure objects. Departmental OUs (Sales, HR) are fine as a second-level grouping under Users, but the top level must express tiering and object type.

OU-design principles as a checklist:

Delegation with dsacls

Delegate granular rights with the Delegation of Control Wizard (GUI) or dsacls (scriptable, auditable). The canonical example — let the helpdesk reset passwords only inside the Users OU and nowhere near Tier0:

# Grant a helpdesk group password-reset on user objects in the Users OU (inheritable to child objects)
dsacls "OU=Users,DC=ad,DC=example,DC=com" `
  /I:S /G "EXAMPLE\Helpdesk-PWReset:CA;Reset Password;user"

# Also allow forcing a change at next logon (write pwdLastSet) — often paired with reset
dsacls "OU=Users,DC=ad,DC=example,DC=com" `
  /I:S /G "EXAMPLE\Helpdesk-PWReset:WP;pwdLastSet;user"

Common delegations and the exact permission they need:

The governing principle: no human account is a permanent member of Domain Admins, Enterprise Admins, or Schema Admins. Those groups stay empty (or hold only break-glass accounts) and privileged access is granted just-in-time for a change window, then removed. Everyday administration happens through scoped, delegated rights on OUs, not through membership in a god-group. This single discipline shrinks the Tier 0 attack surface more than any other configuration.

The Tier 0 / Tier 1 / Tier 2 administrative model

This is the part that actually contains a breach. The model partitions identities and the systems they log into so a compromised workstation cannot harvest a domain admin’s credentials. Assign every system and every admin account to exactly one tier by what it controls:

The one-directional control rule is the entire mechanism, expressed as an allow/deny matrix of credential logon (which tier’s account may authenticate to which tier’s system):

Read the diagonal carefully: a higher tier may manage lower-tier assets in principle, but you still deny higher-tier accounts logon to lower-tier systems, because the moment a Tier 0 credential authenticates to a Tier 2 laptop its hash/ticket is cached where Tier 2 malware can steal it. Lower tiers are managed with a dedicated account of that lower tier (or agent-based tooling that never exposes the higher credential). Enforcement is therefore deny higher-tier logon downward and deny lower-tier logon upward — a two-way lock yielding one-directional control.

Clean source and PAWs

Clean source is the precondition: everything that can control a Tier 0 asset — the VM host, build media, patch/management tooling, backup system, and the accounts that touch it — must itself be Tier 0. DCs as VMs on a hypervisor whose admins are Tier 1 inverts the model (Tier 1 controls Tier 0); fix it with dedicated Tier 0 hosts (or physical DCs), Tier 0 build/patch tooling, and Tier 0 backup.

Privileged Access Workstations (PAWs) are the clean devices admins use to administer a tier — hardened, dedicated, with no internet browsing and no email (the top two malware vectors), Credential Guard on, application allow-listing, and strict logon restrictions. Tier 0 admins administer Tier 0 only from Tier 0 PAWs, never RDP-ing to a DC from a daily-driver laptop. PAW essentials:

For the workstation-hardening controls that make a PAW resist credential theft (Credential Guard, SMB hardening, lateral-movement defense), see Hardening SMB and Enabling Credential Guard to Block Lateral Movement.

Enforce the boundary with authentication policy silos

Authentication policy silos (Server 2012 R2+, strongest with Kerberos and the Protected Users group) bind accounts so their Kerberos TGTs are only issued when they authenticate from a member of the silo. A stolen Tier 0 TGT replayed from a non-silo machine is rejected by the KDC. Combined with a short TGT lifetime, silos make Golden-Ticket-style persistence and cross-host replay dramatically harder.

# 1) Create the policy: short TGT life + restrict where Tier 0 accounts can authenticate from
New-ADAuthenticationPolicy -Name "Tier0-Policy" `
  -UserTGTLifetimeMins 240 `
  -UserAllowedToAuthenticateFrom `
    '{ Enabled = true; Expr = (Member_of_any {SID(<Tier0-PAWs-and-DCs-group-SID>)}) }' `
  -ProtectedFromAccidentalDeletion $true

# 2) Create the silo (enforced, not audit)
New-ADAuthenticationPolicySilo -Name "Tier0-Silo" -Enforce

# 3) Grant the Tier 0 accounts + the Tier 0 systems membership in the silo
Grant-ADAuthenticationPolicySiloAccess -Identity "Tier0-Silo" -Account "EXAMPLE\t0-admin1"
Grant-ADAuthenticationPolicySiloAccess -Identity "Tier0-Silo" -Account "EXAMPLE\DC1$"

# 4) Assign the policy + silo to each Tier 0 account
Set-ADUser -Identity "t0-admin1" -AuthenticationPolicy "Tier0-Policy"
Set-ADUser -Identity "t0-admin1" -AuthenticationPolicySilo "Tier0-Silo"

Silos vs the other logon controls — they layer, they don’t replace each other:

Reinforce with User-Rights-Assignment logon-deny GPOs

Silos handle Kerberos; User Rights Assignment (URA) GPOs handle interactive/service/batch logon at each machine. Link a GPO to each tier’s device OU that denies logon rights to the wrong tiers:

Note the deliberate asymmetry: Tier 0 accounts are denied logon on Tier 1/2 devices, and Tier 1 accounts on Tier 2 — this is what keeps a higher-tier credential from ever being cached on a lower-trust host. The URA constants are SeDenyInteractiveLogonRight, SeDenyRemoteInteractiveLogonRight, SeDenyBatchLogonRight, and SeDenyServiceLogonRight; manage them as code (see Group Policy at Scale: A Maintainable Architecture and Managing GPOs as Code) so the boundary is version-controlled, not clicked once and forgotten.

Hardening: LAPS, Protected Users, AdminSDHolder, legacy protocols

Layer these on once the tier model exists — they reduce the credential material an attacker can steal and remove the legacy paths they abuse.

Windows LAPS

Windows LAPS (built into current Windows/Server, and back-ported via a 2023 update to older supported OSes) randomizes and rotates the local Administrator password on every domain-joined machine, storing it encrypted in AD (or in Entra ID). This kills pass-the-hash across machines via a shared local-admin secret — the single most common lateral-movement technique — because every machine’s local admin password is unique and rotating.

# Extend the schema for Windows LAPS (Schema Admin, once per forest)
Update-LapsADSchema

# Delegate each managed device's right to update its own LAPS password on its OU
Set-LapsADComputerSelfPermission -Identity "OU=Workstations,DC=ad,DC=example,DC=com"

# Read a machine's current LAPS password (as a delegated reader)
Get-LapsADPassword -Identity "WKS-014" -AsPlainText

Then configure rotation, complexity, and encryption to a tier-appropriate group via the Windows LAPS GPO settings — encrypt Tier 0 device passwords so only Tier 0 admins can read them. For the full LAPS + gMSA credential-hardening story, see Eliminating Static Service Credentials with gMSA and Windows LAPS.

Protected Users

Add Tier 0 and other high-value admin accounts to the Protected Users global group. Membership forces stronger protections that shut down the most common credential-theft techniques — but validate first that those accounts never need the disabled features (NTLM, RC4, delegation), because membership is unforgiving:

Add-ADGroupMember -Identity "Protected Users" -Members "t0-admin1","t0-admin2"

AdminSDHolder and SDProp

Protected groups (Domain Admins, Enterprise Admins, Schema Admins, and others) have their ACLs periodically re-stamped from the AdminSDHolder object by the SDProp process (every 60 minutes by default). This is why custom permissions you set on a privileged account silently revert. Two operational consequences:

Audit the template for backdoor ACEs — a classic attacker persistence trick:

# Dump the AdminSDHolder ACL and look for ACEs you didn't put there
$adminSDHolder = "CN=AdminSDHolder,CN=System,DC=ad,DC=example,DC=com"
(Get-Acl "AD:$adminSDHolder").Access |
  Select-Object IdentityReference, ActiveDirectoryRights, AccessControlType |
  Sort-Object IdentityReference

Disable legacy protocols

Remove the protocols attackers rely on. Audit before you block — NTLM and SMBv1 removal can break legacy apps, so measure the dependency first, then enforce:

# Remove SMBv1 (audit access first!) and require SMB signing on a DC
Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol -NoRestart
Set-SmbServerConfiguration -RequireSecuritySignature $true -Force

# Disable the Print Spooler on domain controllers (mitigates PrintNightmare & spooler relay)
Set-Service -Name Spooler -StartupType Disabled
Stop-Service -Name Spooler -Force

Set the GPO Network security: Restrict NTLM policies to Audit first, review the operational event logs to find what still uses NTLM, then move to Deny for the traffic that does not need it. Rushing straight to Deny breaks legacy line-of-business apps and generates a self-inflicted outage.

Backup and forest recovery

You back up AD by backing up system state on at least one DC per domain — treat those backups as Tier 0 assets and store them offline/immutable so ransomware cannot encrypt them alongside production.

# Install the backup feature, then take a system-state backup to a separate volume
Install-WindowsFeature Windows-Server-Backup
wbadmin start systemstatebackup -backupTarget:E: -quiet

Three distinct recovery scenarios need three distinct procedures — do not confuse them:

Enable the AD Recycle Bin now (irreversible, but a fantastic safety net) and know the two restore paths:

# Enable the AD Recycle Bin (once per forest; CANNOT be disabled)
Enable-ADOptionalFeature -Identity "Recycle Bin Feature" `
  -Scope ForestOrConfigurationSet -Target "ad.example.com"

# Later: restore an accidentally deleted user
Get-ADObject -Filter 'Name -like "*Jdoe*"' -IncludeDeletedObjects | Restore-ADObject

Authoritative restore for a mass deletion (boot the DC into Directory Services Restore Mode using the DSRM password from promotion, restore system state, then):

ntdsutil
  activate instance ntds
  authoritative restore
  restore subtree "OU=Users,DC=ad,DC=example,DC=com"
  quit
quit

Forest-level recovery from a compromise is a rehearsed runbook, not an improvisation — the full process (isolated recovery environment, krbtgt double-reset, trust rebuild, validation) is covered in Active Directory Forest Recovery: Building and Testing a Ransomware-Ready Recovery Runbook.

Architecture at a glance

Picture the finished forest as three concentric concerns stacked on one directory, read from the outside in.

The outer ring is topology and location: two sites, HQ-East (10.10.0.0/16) and DR-West (10.20.0.0/16), each holding at least one DC that is also a global catalog and DNS server. The HQ-DR site link (cost 100, 15-minute schedule) carries compressed, scheduled inter-site replication; inside each site, change-notification replication keeps DCs near-instantly consistent. Clients resolve _ldap._tcp.dc._msdcs.ad.example.com and, because their subnet is mapped to a site, are steered to a local DC for Kerberos rather than crossing the WAN. The forest-root DC anchors the two forest-wide FSMO roles and, in this single-domain design, the three domain roles sit alongside them on the best-resourced DC, ready to transfer to a healthy peer.

The middle ring is structure and policy: ad.example.com carved into an OU tree whose top level is the tier model — Tier0, Tier1, Tier2, plus Users, Workstations, ServiceAccounts. GPOs link to those OUs to push hardening and, critically, the User-Rights-Assignment logon-deny rules that stop a Tier 0 account from ever authenticating to a Tier 2 laptop. Delegation is scoped to these OUs with dsacls, so the helpdesk can reset passwords in Users while Domain Admins, Enterprise Admins, and Schema Admins sit empty, filled only just-in-time.

The inner core is the trust and containment boundary: the forest as the security perimeter, and inside it the Tier 0/1/2 partition enforced by three reinforcing controls — authentication policy silos (the KDC refuses a Tier 0 TGT except from a Tier 0 PAW or DC), Protected Users (no NTLM/RC4/caching, a 4-hour TGT), and URA logon-deny GPOs — wrapped in credential-hygiene layers (Windows LAPS, clean source for Tier 0 build/patch/backup, and legacy protocols removed). The flow to trace: an admin authenticates from a Tier 0 PAW → the KDC (satisfied by the silo) issues a short-lived TGT → the admin administers a domain controller → and at no point is a Tier 0 credential exposed on a lower-trust host, because every logon path across a tier boundary is explicitly denied. That single property — topology-aware DCs, an OU-and-GPO structure, and the tiered trust core together — turns Active Directory from a lateral-movement superhighway into a segmented boundary an attacker cannot cross.

Real-world scenario

Meridian Logistics — a freight forwarder, ~4,000 employees across a Mumbai HQ and a Pune DR site — ran a “fully tiered” forest on paper: single forest/domain (ad.meridianlog.com), four DCs (two per site, all GCs), functional level 2016, Tier 0/1/2 documented, URA GPOs in place, a consultant’s sign-off eighteen months old. Textbook — on paper.

The gap surfaced mundanely: nightly backup jobs across the Tier 1 file servers started failing after a routine GPO tightening, ticketed as “permission denied — logon as batch job.” The on-call engineer’s first instinct — which would have quietly re-opened the exact hole the tiering existed to close — was to exempt the backup account from the new Deny-logon GPO. Fortunately the change went through review.

The root cause was the tier model working correctly against an architecture mistake. The backup agent ran as svc-backup, a member of Domain Admins (a Tier 0 group) — a convenience set up years earlier so “backups can touch anything.” The tightened URA GPO on the Tier 1 server OU now denied SeBatchLogonRight to Tier 0 accounts, exactly as it should: a Tier 0 credential must never run as a batch job on a Tier 1 host. Exempting it would have punched a permanent hole loading a Tier 0 credential into a service process on every file server — precisely the path a Kerberoast or LSASS-dump exploits to reach a DC.

The correct fix was to stop using a god-account for a server-tier workload. The team created a Tier 1 gMSA (gmsa-backup-t1) retrievable only by the backup servers, granted it only the rights the agent needed (read on the file-server data, SeBatchLogonRight on Tier 1 servers via a Tier 1 GPO, nothing on any DC), and removed, disabled, and audited svc-backup.

# Tier 1 gMSA: only the backup hosts may retrieve its password
New-ADServiceAccount -Name "gmsa-backup-t1" `
  -DNSHostName "gmsa-backup-t1.ad.meridianlog.com" `
  -PrincipalsAllowedToRetrieveManagedPassword "EXAMPLE\Tier1-BackupHosts" `
  -Path "OU=ServiceAccounts,DC=ad,DC=meridianlog,DC=com"

# On each backup server: install and validate before reconfiguring the service
Install-ADServiceAccount -Identity "gmsa-backup-t1"
Test-ADServiceAccount  -Identity "gmsa-backup-t1"

The backup jobs ran green that night on a Tier 1 identity, and no Tier 0 credential touches a member server in the estate any more. The numbers afterward: Domain Admins dropped from nine standing accounts to zero (two vaulted, monitored break-glass accounts granted JIT); service accounts with Tier 0 rights fell from fourteen to zero; and a purple-team exercise that had previously reached DCSync from a compromised file server in under an hour was stopped at the Tier 1 boundary. The lesson on the wall: when a tier boundary breaks a workload, the workload is almost always over-privileged — re-scope it down, never punch a hole in the tier.

Advantages and disadvantages

A deliberately designed, tiered forest costs real effort — the honest trade-off:

The design is right for essentially every production forest — the alternative is a flat trust boundary a single phished laptop can escalate to forest compromise. It bites hardest during adoption: admins resent multiple accounts and PAWs, legacy apps surface NTLM/RC4 dependencies, and the discipline erodes the first time someone RDPs to a DC “just this once.” Every disadvantage is manageable with JIT tooling, an audit-first legacy-protocol rollout, and monitoring of the one-directional rule. On a genuinely tiny estate the full PAW/silo apparatus can be scaled down, but the OU/tiering structure and LAPS/legacy-protocol hardening still apply and still pay off.

Hands-on lab

Stand up a two-DC forest, build the tier-aligned OU structure, place and verify FSMO roles, and apply the first tiering control — all in a lab (two Windows Server 2022/2025 VMs; Server Core preferred). Nothing here costs money beyond the VMs; tear them down at the end.

Step 1 — Prepare the first server (DC1). Static IP, hostname, DNS pointing to itself for now.

Rename-Computer -NewName "DC1" -Restart   # if not already named
# After reboot, set a static IP (adjust interface/addresses to your lab)
New-NetIPAddress -InterfaceAlias "Ethernet" -IPAddress 10.10.0.10 -PrefixLength 16 -DefaultGateway 10.10.0.1
Set-DnsClientServerAddress -InterfaceAlias "Ethernet" -ServerAddresses 10.10.0.10

Step 2 — Install the role and promote the forest.

Install-WindowsFeature -Name AD-Domain-Services -IncludeManagementTools
$dsrm = Read-Host -AsSecureString -Prompt "DSRM password"
Install-ADDSForest -DomainName "ad.example.com" -DomainNetbiosName "EXAMPLE" `
  -ForestMode WinThreshold -DomainMode WinThreshold -InstallDns:$true `
  -SafeModeAdministratorPassword $dsrm -Force:$true

Expected: the server reboots and comes up as the forest root. After reboot, confirm:

Get-ADDomainController -Server localhost |
  Select-Object Name, IsGlobalCatalog, OperationMasterRoles
netdom query fsmo   # all five roles on DC1

Step 3 — Create the tier-aligned OU structure and redirect defaults.

$dn = "DC=ad,DC=example,DC=com"
"Tier0","Tier1","Tier2","Users","Workstations","ServiceAccounts","Groups" | ForEach-Object {
  New-ADOrganizationalUnit -Name $_ -Path $dn -ProtectedFromAccidentalDeletion $true
}
# Redirect default user/computer creation into real OUs
redirusr "OU=Users,$dn"
redircmp "OU=Workstations,$dn"
Get-ADOrganizationalUnit -Filter * | Select-Object Name   # verify OUs exist

Step 4 — Prepare and promote the second DC (DC2). On the second VM: static IP, DNS pointing at DC1, then promote as a replica.

# On DC2 (10.10.0.11), DNS pointing at DC1 first:
Set-DnsClientServerAddress -InterfaceAlias "Ethernet" -ServerAddresses 10.10.0.10,127.0.0.1
Install-WindowsFeature -Name AD-Domain-Services -IncludeManagementTools
$cred = Get-Credential   # EXAMPLE\Administrator
$dsrm = Read-Host -AsSecureString -Prompt "DSRM password"
Install-ADDSDomainController -DomainName "ad.example.com" -Credential $cred `
  -InstallDns:$true -SiteName "Default-First-Site-Name" `
  -SafeModeAdministratorPassword $dsrm -NoGlobalCatalog:$false -Force:$true

Expected: DC2 reboots and joins as a second DC + GC. Confirm both DCs see each other:

Get-ADDomainController -Filter * | Select-Object Name, Site, IsGlobalCatalog

Step 5 — Verify replication is healthy.

repadmin /replsummary            # expect zero failures
repadmin /showrepl               # inbound replication succeeding on all partitions
dcdiag /s:DC2 /test:Replications  # DC2 replication test passes

Step 6 — Practice a graceful FSMO transfer and confirm.

# Move all five roles to DC2, then move them back — proving the transfer works both ways
Move-ADDirectoryServerOperationMasterRole -Identity "DC2" `
  -OperationMasterRole SchemaMaster,DomainNamingMaster,RIDMaster,PDCEmulator,InfrastructureMaster
netdom query fsmo   # now all on DC2
Move-ADDirectoryServerOperationMasterRole -Identity "DC1" `
  -OperationMasterRole SchemaMaster,DomainNamingMaster,RIDMaster,PDCEmulator,InfrastructureMaster
netdom query fsmo   # back on DC1

Step 7 — Apply a first tiering control (deny Tier 2 accounts on Tier 0 devices). Create a demo Tier 2 group and a GPO that denies it interactive logon on the Tier 0 devices OU (link and edit via GPMC or PowerShell/DSC — here we just create the group and OU wiring to prove the structure).

New-ADGroup -Name "Tier2-Admins" -GroupScope Global -Path "OU=Tier2,DC=ad,DC=example,DC=com"
# In production: a GPO linked to the Tier0 devices OU sets
# "Deny log on locally / through RDP / as batch / as a service" = Tier2-Admins, Tier1-Admins
Get-ADGroup -Filter 'Name -like "Tier*"' | Select-Object Name, DistinguishedName

Validation checklist. You now have a two-DC, single-domain forest with a tier-aligned OU tree, redirected default containers, verified FSMO placement, healthy replication, and a proven transfer path. What each step demonstrated:

Teardown. In a lab, demote the DCs (which cleans their metadata) or simply delete the VMs:

# On each DC, to cleanly demote (last DC needs -LastDomainControllerInDomain):
Uninstall-ADDSDomainController -DemoteOperationMasterRole -Force
# Or just delete the lab VMs from the hypervisor.

Common mistakes & troubleshooting

The mistakes that hurt most in Active Directory are rarely the deployment commands — they are the operational and design errors that quietly undo the architecture. Scan the table, then read the detail for the ones that bite hardest.

The expanded reasoning for the highest-impact entries:

2. Replication failing after a snapshot restore (USN rollback). A DC reverted to an earlier state (VM snapshot restore) has Update Sequence Numbers (USNs) that conflict with what partners already saw — partners believe they hold every change up to a number the DC has now “un-made,” so they stop pulling from it and it is silently orphaned. Confirm via Directory Services event 2095 (“A USN rollback occurred”) and repadmin /showrepl errors. There is no safe repair: forcibly demote, metadata-clean, and re-promote cleanly — and never snapshot-revert a DC; use VM-GenerationID-aware hypervisors and system-state backups.

4. “No RID pool available” — cannot create new principals. The RID Master is unreachable, so DCs cannot obtain a fresh RID block when their local pool runs low and account/group/computer creation stops. Confirm via netdom query fsmo, Directory Services event 16645, and dcdiag /test:RidManager. Bring it back online; if permanently dead, seize the RID role and wipe the dead holder (a resurrected RID Master risks duplicate SIDs).

8. Authentication breaks after a DNS change (the island / SRV problem). Clients and DCs locate each other via SRV records; a DC that points its DNS client only at itself can fail to find replication partners on boot, or a change dropped critical _msdcs records. Confirm via dcdiag /test:DNS and Resolve-DnsName -Type SRV "_ldap._tcp.dc._msdcs.ad.example.com". Point each DC’s primary DNS at a peer (secondary at self), then ipconfig /registerdns and Restart-Service Netlogon to re-register.

10. A Tier 0 credential ends up cached on a lower-tier host. The one-directional rule was broken — a Tier 0 admin interactively logged on (RDP, runas) to a Tier 1/2 system, leaving their hash/ticket where lower-tier malware can steal it; the single most damaging operational lapse. Confirm via EDR/Security logs showing a Tier 0 account’s logon type 2/10 on a lower-tier device. Enforce silos + URA deny-logon GPOs so it’s technically impossible, immediately reset the exposed Tier 0 credential, and retrain on PAW usage.

Best practices

• One forest, one domain by default. Add a domain only for a documented hard requirement, and a second forest only for genuine isolation (admin/red forest, hostile-estate separation). The forest is your only real security boundary — respect it.
• Never run a single DC in production. Two is the floor; one DC per site is the target. A single DC makes every patch, reboot, and hardware fault an outage, and a single snapshot revert a USN-rollback disaster.
• Promote with scripts, not the wizard. Install-ADDSForest/Install-ADDSDomainController are repeatable, reviewable, and part of your disaster-recovery runbook. Never type the DSRM password in plaintext.
• Make every DC a GC in a single-domain forest. Zero downside, and it removes an entire class of “logons failed because the only GC was down” incidents.
• Describe your topology to the KCC. Create sites, map every subnet, and cost/schedule site links to match physical reality — otherwise clients authenticate across the WAN and replication ignores your bandwidth.
• Place FSMO deliberately and document the seizure procedure. Keep the two forest roles together; keep the PDC Emulator on your best DC; know exactly which roles you’d seize and that the dead holder gets wiped.
• Structure OUs by administration and policy, not by department. Tier at the top level, separate accounts from devices, keep the tree shallow, and enable protect from accidental deletion on OUs.
• Keep Domain Admins, Enterprise Admins, and Schema Admins empty. Grant privileged access just-in-time; do everyday work through scoped OU delegations, not god-group membership.
• Enforce the one-directional tier rule technically, not by policy alone. Silos + Protected Users + URA deny-logon GPOs, so a broken rule is impossible, not merely against the rules.
• Give Tier 0 admins PAWs and clean source. Dedicated, hardened, no-web/no-email workstations, and a Tier 0 build/patch/backup supply chain — otherwise a lower tier controls Tier 0.
• Roll out Windows LAPS and enable the AD Recycle Bin early. Unique rotating local-admin passwords kill lateral movement; the Recycle Bin turns a mass deletion into a Restore-ADObject.
• Audit before you deny legacy protocols. SMBv1 removal and NTLM Deny break legacy apps — measure the dependency (Restrict-NTLM Audit mode) first, then enforce.
• Prove it with dcdiag and repadmin, on a schedule. The build isn’t done until dcdiag /v /c /e and repadmin /replsummary are clean, and health-checking is a recurring job, not a one-time task.

Security notes

• Treat Tier 0 as the crown jewels, end to end. Domain controllers, AD CS, Entra Connect/ADFS, the AD database, and their backups, hosts, and build/patch tooling are all Tier 0. A gap anywhere in that supply chain (a Tier 1 hypervisor hosting DCs, a Tier 2 file share holding build media) collapses the boundary — clean source is not optional.
• Assume workstations are compromised and design so it doesn’t matter. The whole point of tiering is that a Tier 2 compromise cannot reach Tier 0. Enforce it with silos, Protected Users, and URA deny-logon GPOs so no Tier 0 credential is ever exposed below Tier 0.
• Empty the privileged groups; grant JIT. Standing membership in Domain Admins/Enterprise Admins/Schema Admins is the highest-value target in the forest. Keep them empty (bar vaulted, monitored break-glass accounts) and elevate just-in-time — a pattern the cloud analogue Privileged Identity Management and PAM Architecture: Just-in-Time Access at Scale formalizes.
• Audit AdminSDHolder for backdoor ACEs regularly. An extra ACE on the template silently grants persistence over every protected object every hour via SDProp — a classic, quiet attacker foothold.
• Kill the credential-material attackers need. Windows LAPS (no shared local-admin secret), Protected Users (no NTLM/RC4/caching), and Kerberos-first (audit-then-deny NTLM) remove the raw material for pass-the-hash, pass-the-ticket, and Kerberoasting.
• Require signing and channel binding on DCs. LDAP signing + channel binding and SMB signing block relay attacks against domain controllers; disable the DC Print Spooler (PrintNightmare / spooler relay).
• Protect the krbtgt account and rotate it correctly. The krbtgt hash is the key to Golden Tickets; after any suspected Tier 0 compromise, reset it twice (with replication between resets) as part of the forest-recovery runbook — never a casual single reset.
• Immutable, offline Tier 0 backups. Ransomware targets backups first. A system-state backup that ransomware can encrypt is not a recovery plan; store Tier 0 backups offline/immutable — see Active Directory Forest Recovery: Building and Testing a Ransomware-Ready Recovery Runbook.

The security controls that map to specific attacks, so you can prioritize:

Cost & sizing

Active Directory has no per-object licensing — the cost is Windows Server licenses, the compute/storage the DCs run on, and operational effort. The main drivers: the number of DCs (floor two per domain, plus one per site big enough to justify local auth, each sized so any one can carry that site’s full load — over-provisioning wastes licenses, under-provisioning risks WAN latency and outages); DC sizing (memory- and disk-IO-bound, caching NTDS.dit in RAM — modest vCPU with enough RAM for the database and SSD for NTDS.dit/logs matters far more than cores); Tier 0 infrastructure (dedicated hosts, build/patch tooling, and backup — the price of clean source, budgeted explicitly rather than “borrowed” from Tier 1); PAWs (one per admin per administered tier — cheap insurance against a Tier 0 theft that would otherwise mean a rebuild); and backup/recovery (immutable/offline Tier 0 storage plus the time to rehearse the runbook). A rough sizing picture for a mid-size single-domain forest (two sites, ~4,000 users):

There is no free tier here in the cloud sense — but a lab is nearly free: two evaluation-edition Windows Server VMs on any hypervisor (or free-tier-adjacent cloud VMs you delete after) let you build and tear down the entire forest for the cost of a few hours of compute.

Interview & exam questions

1. Why is the forest, not the domain, Active Directory’s security boundary? All domains in a forest share one schema, one configuration partition, one Enterprise Admins group, and automatic transitive trusts, so a compromise of the schema or any DC can pivot to every domain — only a separate forest (with at most a selective-auth trust) truly isolates. You add a domain for administrative/replication convenience, never for security.

2. When would you create a second domain, and when a second forest? A second domain only for a documented hard requirement that OU delegation and Fine-Grained Password Policies can’t satisfy. A second forest for real isolation: an administrative/red forest for Tier 0 (ESAE), separation from a hostile/unknown estate (selective-auth trust), or a regulatory island that must not share a schema or trust.

3. What do functional levels control, and why can’t you lower them? They set the feature floor (AD Recycle Bin at 2008 R2+, authentication policy silos at 2012 R2+) gated by the lowest-version DC. Raising is safe once every DC supports the level; lowering would undo behavior the directory has committed to, so it needs a rebuild. On greenfield, pick the highest level every DC supports.

4. Name the five FSMO roles, their scope, and the impact if each is unavailable. Forest-wide: Schema Master (schema writes — no impact except extensions can’t run) and Domain Naming Master (add/remove domains). Per-domain: RID Master (RID pools — loss eventually stops new-object creation), PDC Emulator (time, password/lockout urgency, GPO edit target — loss causes time skew and GPMC/lockout issues), and Infrastructure Master (cross-domain reference cleanup — irrelevant if every DC is a GC).

5. Explain the Infrastructure Master / Global Catalog interaction. A GC already holds a partial copy of every object forest-wide, so a GC-hosted IM sees nothing as stale and silently stops updating cross-domain references (members show as SIDs). In a multi-domain forest where not all DCs are GCs, put the IM on a non-GC DC; if every DC is a GC (the single-domain recommendation), the IM is a no-op.

6. Difference between transferring and seizing an FSMO role? Transfer is a graceful handover when both DCs are online (maintenance, decommission), no cleanup needed. Seize (-Force) is break-glass for a permanently dead holder — one-way, and the dead DC must be wiped and metadata-cleaned, never resurrected (or you get duplicate roles and replication conflicts, worst for RID/Schema Master).

7. What is a USN rollback and how do you fix it? Reverting a DC to an earlier state (a VM snapshot restore) makes its Update Sequence Numbers conflict with what partners already replicated, so partners stop pulling and it’s silently orphaned. Confirm via Directory Services event 2095; fix by forcibly demoting, metadata-cleaning, and re-promoting — and never snapshot-revert a DC.

8. Explain the one-directional control rule of the tiered admin model. A higher tier may manage lower-tier assets, but a lower-tier credential must never control a higher tier and a higher-tier credential must never be exposed on a lower-trust host. So you deny Tier 0 accounts logon to Tier 1/2 systems and deny lower tiers logon upward — one-directional control enforced by a two-way logon lock.

9. How do authentication policy silos contain credential theft? A silo makes the KDC issue an account’s Kerberos TGT only when it authenticates from a silo member (e.g. a Tier 0 PAW or DC), so a stolen TGT replayed from a non-silo host is rejected. With a short TGT lifetime and Protected Users, this makes pass-the-ticket and Golden-Ticket persistence far harder (requires 2012 R2+ FL, strongest with Kerberos).

10. What does Protected Users enforce, and what must you check first? Members lose NTLM, RC4/DES (AES only), long-term credential caching, and unconstrained delegation, and get a non-renewable 4-hour TGT. Before adding an account, verify it never needs NTLM/RC4/delegation and can always reach a DC (no cached-logon dependency), or you break its workflows.

11. Why do custom permissions on a Domain Admins member keep reverting? SDProp re-stamps protected objects’ ACLs from the AdminSDHolder template every ~60 minutes (marking them adminCount=1), so per-object ACE changes revert. Manage access at the group/OU level instead, and audit AdminSDHolder for unexpected ACEs — an extra ACE there is a persistence backdoor over every protected object.

12. How does Windows LAPS reduce lateral movement, and where are passwords stored? It randomizes each machine’s local Administrator password to a unique, rotating value, eliminating the shared secret that lets an attacker pass-the-hash from machine to machine. Passwords are stored encrypted in AD (or Entra ID), readable only by delegated/tier-appropriate principals — the most effective control against local-admin lateral movement.

These map primarily to AZ-800 / AZ-801 (Windows Server Hybrid Administrator) — deploy and manage AD DS in on-premises and cloud environments, identity infrastructure — and to the classic on-prem identity objectives. The security/tiering content aligns with SC-300 (Identity and Access Administrator) thinking and Microsoft’s Enterprise Access Model / Securing Privileged Access guidance. A compact mapping for revision:

Quick check

1. You need different password policies for two groups of users. Does that justify a second domain? Why or why not?
2. In a single-domain forest where every DC is a global catalog, does Infrastructure Master placement matter? Why?
3. A domain controller was restored from a VM snapshot and replication is now failing with Directory Services event 2095. What happened, and what’s the fix?
4. A Tier 0 admin RDPs into a Tier 1 file server to check something. Why is that a problem even though a higher tier is “allowed” to manage a lower tier?
5. You add a service account to Protected Users and it immediately stops working. Name two likely reasons.

Answers

1. No. Since the 2008 domain functional level, Fine-Grained Password Policies (FGPP) let you apply different password/lockout policies to different security groups within a single domain. The old “one password policy per domain” limitation — which used to force multi-domain designs — no longer applies. Stay single-domain and use FGPP.
2. No, it doesn’t matter. The Infrastructure Master’s job (updating stale cross-domain references) is a no-op when every DC is a GC, because a GC already holds a partial replica of every object forest-wide and never sees a reference as “stale.” The IM only needs careful placement (on a non-GC DC) in a multi-domain forest where not all DCs are GCs.
3. A USN rollback: the snapshot restore reverted the DC’s Update Sequence Numbers to an earlier state, so replication partners (which already saw higher USNs) refuse to pull changes from it and it’s silently orphaned. The fix is to forcibly demote the rolled-back DC, run metadata cleanup, and re-promote it cleanly — and to never snapshot-revert DCs (use system-state backups and VM-GenerationID-aware hosts instead).
4. Because the moment a Tier 0 credential authenticates to a lower-trust host, its hash/ticket is cached there where Tier 2/1 malware can steal it — collapsing the whole model. “A higher tier may manage a lower tier” means with a dedicated lower-tier account or agent-based tooling, never by exposing the Tier 0 credential on the lower-tier machine. That’s why URA deny-logon GPOs deny Tier 0 accounts logon on lower-tier systems.
5. Likely reasons: (a) the account needs NTLM (or Kerberos RC4/DES), which Protected Users blocks — common for legacy apps or services; and/or (b) the account relied on cached credentials / a specific delegation, both of which Protected Users removes (no long-term caching, no unconstrained delegation). Validate an account’s NTLM/RC4/delegation/caching dependencies before adding it.

Glossary

• Active Directory Domain Services (AD DS) — the on-premises directory service that authenticates users, authorizes access, and publishes DNS and Group Policy; the root of trust for a Windows estate.
• Forest — the top-level Active Directory container and the only true security boundary; all its domains share one schema, configuration partition, and Enterprise Admins group, with automatic transitive trusts.
• Domain — a partition of a forest with its own accounts and policies; an administrative/replication unit, not a security boundary.
• Tree — a set of domains in a forest sharing a contiguous DNS namespace; a naming convenience, rarely needed.
• Schema — the forest-wide definition of every object class and attribute, held on the Schema Master; extensions (Exchange, LAPS) are additive and effectively irreversible.
• Functional level (FFL/DFL) — the feature floor set by the lowest-version DC; unlocks features (AD Recycle Bin, authentication policy silos) and can be raised but never lowered without a rebuild.
• Domain controller (DC) — a server holding a writable replica of a domain; the thing you promote, place FSMO roles on, and protect as Tier 0.
• Global catalog (GC) — a DC that also holds a partial, forest-wide index of every object; required for interactive/UPN logon and forest-wide searches.
• FSMO (Flexible Single Master Operation) — the five single-master roles (Schema Master, Domain Naming Master — forest-wide; RID Master, PDC Emulator, Infrastructure Master — per-domain) that are exceptions to multi-master replication.
• KCC (Knowledge Consistency Checker) — the process on each DC that builds the replication connection topology from your sites, subnets, and site links.
• Site / subnet / site link — a well-connected physical location; an IP range mapped to a site; and a WAN path (with cost and schedule) between sites, respectively — the objects that describe topology to the KCC.
• OU (Organizational Unit) — an administrative container inside a domain that can be linked to a GPO and delegated; unlike the CN=Users/CN=Computers containers, which cannot be GPO-linked.
• AdminSDHolder / SDProp — the ACL template for protected groups, and the process that re-stamps protected objects’ ACLs from it hourly (marking them adminCount=1); an extra ACE on it is a persistence backdoor.
• Tier 0 / Tier 1 / Tier 2 — the administrative model partitioning systems and admin accounts into identity-control, server-control, and workstation-control planes, enforcing one-directional control.
• Clean source — the principle that everything controlling a Tier 0 asset (host, media, tooling, backup, accounts) must itself be Tier 0; the precondition tiering rests on.
• PAW (Privileged Access Workstation) — a dedicated, hardened, no-web/no-email workstation used to administer a single tier.
• Authentication policy silo — a construct that makes the KDC issue an account’s Kerberos TGT only when it authenticates from a member of the silo, blocking stolen-ticket replay from other hosts.
• Protected Users — a group whose members lose NTLM, RC4/DES, credential caching, and unconstrained delegation, and get a non-renewable 4-hour TGT — shutting down pass-the-hash and weak-crypto downgrade.
• Windows LAPS — the built-in solution that randomizes and rotates each machine’s local Administrator password to a unique value stored encrypted in AD/Entra ID, killing shared-local-admin lateral movement.
• DSRM (Directory Services Restore Mode) — a boot mode using a per-DC local admin password (set at promotion) required for authoritative restores.
• USN rollback — the corruption state when a DC is reverted to an earlier point (e.g. a VM snapshot restore), causing replication partners to orphan it; fixed only by forced demotion and re-promotion.

Next steps

You can now design, deploy, and harden a forest that contains a breach instead of amplifying it. Build outward:

• Next: Group Policy at Scale: A Maintainable Architecture and Managing GPOs as Code — how to author and version the tiering, hardening, and LAPS GPOs the model depends on.
• Related: Eliminating Static Service Credentials with gMSA and Windows LAPS — remove the over-privileged service accounts and shared local-admin secrets that undo tiering.
• Related: Building a Two-Tier AD CS PKI: Offline Root and Enterprise Issuing CA — deploy the PKI that is itself a Tier 0 system and a notorious escalation path.
• Related: Diagnosing AD Replication and FSMO Failures with repadmin and dcdiag — the troubleshooting playbook for when replication or a role holder misbehaves.
• Related: Active Directory Forest Recovery: Building and Testing a Ransomware-Ready Recovery Runbook — the rehearsed process for recovering the whole forest after a compromise.
• Related: Hardening SMB and Enabling Credential Guard to Block Lateral Movement — the endpoint controls that make PAWs and member servers resist credential theft.
• Related: Privileged Identity Management and PAM Architecture: Just-in-Time Access at Scale — extend just-in-time, least-standing-privilege thinking into the cloud identity plane.