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 it is still the single most attractive target for an attacker. A forest that was clicked together through the wizard in 2014 and never re-architected is a credential-theft playground. This guide stands up a forest the way it should be done in 2026: scripted, replicated, FSMO-placed deliberately, and carved into a tiered administration model that contains lateral movement instead of inviting it.

1. Design decisions before you touch a server

The single most expensive mistakes in AD are made before the first DC is promoted. Get these right on paper first.

Forest and domain count. Default to a single forest, single domain unless you have a hard requirement otherwise. The forest, not the domain, is the security boundary. Multiple domains do not give you isolation; they give you replication complexity and a larger Tier 0 surface. Spin up additional domains only for genuine administrative, replication, or legal separation needs.

DNS namespace. Use a subdomain of a domain you own, e.g. ad.example.com or corp.example.com. Never use a fabricated TLD like .local (mDNS conflicts) and never use your live external zone example.com (split-brain DNS pain). The NetBIOS name should be short and stable.

Functional level. Set the forest and domain functional level to the lowest version of Windows Server you will actually run as a DC. On greenfield in 2026 with Server 2022/2025 DCs, WinThreshold (2016 FL) is the practical floor that unlocks features like the recycle bin and modern claims; raise further only when every DC supports it.

OU strategy. Decide early that you will not administer objects in the default CN=Users and CN=Computers containers. You cannot link Group Policy to a container, only to an OU. Plan an OU tree that separates accounts, servers, workstations, and service accounts, with the tier model baked in (covered in step 5).

Callout: The Users and Computers default containers are not OUs. Redirect new object creation with redircmp and redirusr so nothing important lands somewhere you cannot apply policy.

2. 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). Set the hostname, static IP, and time source before promotion.

Install the role binaries:

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

Then create the forest. Do not pass the DSRM password in plaintext on the command line.

$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

What the parameters actually mean and where people get burned:

The DC reboots and comes up as the forest root holding all five FSMO roles and the global catalog.

3. Replica DCs, sites, subnets, and replication

A single DC is not a deployment, it is an outage waiting to happen. Add at least one replica before you go live.

On the second server (DNS pointing at the first DC, then itself), install the role and run:

$cred = Get-Credential   # EXAMPLE\an account in Domain Admins / Enterprise Admins
$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

Now make replication topology reflect physical reality. The Knowledge Consistency Checker (KCC) builds intra-site and inter-site connections automatically, but only if you define sites and subnets so it knows where DCs and clients live.

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

# Associate IP subnets with each site
New-ADReplicationSubnet -Name "10.10.0.0/16" -Site "HQ-East"
New-ADReplicationSubnet -Name "10.20.0.0/16" -Site "DR-West"

# Tune the inter-site link: interval is in minutes, cost reflects bandwidth
Set-ADReplicationSiteLink -Identity "DEFAULTIPSITELINK" `
  -ReplicationFrequencyInMinutes 15 `
  -Cost 100

Move each DC into the correct site (via the Sites and Services console or by setting the serverReferenceBL/server object location), and clients will start authenticating against a local DC instead of crossing the WAN. Inter-site replication compresses traffic and honors the schedule; intra-site replication is near-immediate via change notification.

4. FSMO roles: placement, transfer, and seizing

There are five Flexible Single Master Operation roles. Two are forest-wide, three are per-domain.

Check current placement:

netdom query fsmo
# or
Get-ADDomainController -Filter * |
  Select-Object Name, OperationMasterRoles

Placement guidance. In a single-domain forest where every DC is a global catalog, the Infrastructure Master role is effectively a no-op and placement does not matter. Keep the two forest roles together on one DC, and keep the PDC Emulator on a well-resourced, reliable DC because it carries the most live load. A common, defensible layout: all five on DC1, ready to transfer to DC2.

Transfer vs. seize. Transferring is graceful and used when both the source and target DC are online (planned maintenance, decommissioning). Seizing is the break-glass operation for when the role holder is permanently dead.

# Graceful transfer (source DC is healthy)
Move-ADDirectoryServerOperationMasterRole `
  -Identity "DC2" `
  -OperationMasterRole SchemaMaster,DomainNamingMaster,RIDMaster,PDCEmulator,InfrastructureMaster

To seize, add -Force. Seizing is one-way:

Move-ADDirectoryServerOperationMasterRole `
  -Identity "DC2" -OperationMasterRole PDCEmulator,RIDMaster -Force

The single-DC gotcha: if you seize roles from a dead DC, that DC must never come back online holding the old roles. Wipe it. The correct cleanup is metadata cleanup (now automatic in ntdsutil when you remove a DC via the GUI or Remove-ADDomainController), which purges the dead server’s objects from the directory. Bringing a “resurrected” former FSMO holder back creates a split-brain that is genuinely painful to untangle.

5. OU structure and delegation for least privilege

Now design the OU tree to support both Group Policy targeting and the tier model. A workable top-level layout:

ad.example.com
+-- Admin
|   +-- Tier0  (DC admin accounts, Tier 0 service accounts, Tier 0 PAWs)
|   +-- Tier1  (server admin accounts, Tier 1 PAWs)
|   +-- Tier2  (helpdesk/workstation admin accounts, Tier 2 PAWs)
+-- Servers   (member servers, sub-OUs by role)
+-- Workstations
+-- Users     (standard user accounts)
+-- Groups
+-- ServiceAccounts  (gMSAs)

Delegate using dsacls or the Delegation of Control Wizard so that, for example, the helpdesk group can reset passwords only inside the Users OU and never touch Admin:

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

The principle: no human account is a permanent member of Domain Admins, Enterprise Admins, or Schema Admins. Those groups stay empty or near-empty, and access is granted just-in-time. Delegated rights are scoped to OUs, not granted at the domain root.

6. The Tier 0/1/2 model

This is the part that actually contains a breach. The model partitions identities and the systems they log into so that a compromised workstation cannot harvest a domain admin’s credentials.

• Tier 0 controls identity: domain controllers, AD CS, the AD database, and anything that can grant Tier 0 (e.g. federation servers, privileged access management). Tier 0 accounts log on only to Tier 0 systems.
• Tier 1 controls enterprise servers and applications: member servers, databases, line-of-business apps. Tier 1 admins manage servers but have no rights to DCs.
• Tier 2 controls user workstations and devices: helpdesk and desktop support.

The hard rule is one-directional: a higher tier may manage lower-tier assets, but a lower-tier credential must never be usable to control a higher tier, and a higher-tier credential must never be exposed on a lower-tier (less-trusted) host. A Tier 0 admin logging into a regular laptop drops their hash where Tier 2 malware can grab it; that one act collapses the whole model.

Privileged Access Workstations (PAWs). Tier 0 admins use dedicated, hardened PAWs that have no internet/email and exist only to administer Tier 0. Enforce this with logon restrictions and authentication policy silos.

Enforce the boundary with authentication policy silos. Silos (Server 2012 R2+, requires Kerberos and the Protected Users group to bite hardest) bind accounts so their Kerberos TGTs are only issued when they authenticate from members of the silo. A stolen Tier 0 TGT replayed from a non-silo machine is rejected.

# Create a silo and a policy that restricts where Tier 0 accounts can authenticate
New-ADAuthenticationPolicy -Name "Tier0-Policy" `
  -UserTGTLifetimeMins 240 `
  -UserAllowedToAuthenticateFrom `
    '{ Enabled = true; Expr = (Member_of_any {SID(<Tier0-PAWs-group-SID>)}) }' `
  -ProtectedFromAccidentalDeletion $true

New-ADAuthenticationPolicySilo -Name "Tier0-Silo" -Enforce

Grant-ADAuthenticationPolicySiloAccess -Identity "Tier0-Silo" `
  -Account "EXAMPLE\t0-admin1"

Set-ADUser -Identity "t0-admin1" -AuthenticationPolicy "Tier0-Policy"
Set-ADUser -Identity "t0-admin1" -AuthenticationPolicySilo "Tier0-Silo"

Reinforce with User Rights Assignment GPOs: on Tier 0 systems, “Deny log on locally / through RDP / as a batch job / as a service” for Tier 1 and Tier 2 groups, and the reverse on lower tiers so Tier 0 accounts are denied interactive logon to workstations and member servers.

7. Hardening: LAPS, Protected Users, AdminSDHolder, legacy protocols

Layer these on once the tier model is in place.

Windows LAPS. Windows LAPS is built into current Windows and Server (and a 2023 update for older supported OSes). It randomizes and rotates the local Administrator password on every domain-joined machine, killing pass-the-hash with a single shared local admin secret. Store secrets encrypted in AD:

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

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

Then configure rotation, complexity, and encryption (encrypt to a Tier-appropriate group) via the Windows LAPS GPO settings.

Protected Users group. Add Tier 0 and high-value admin accounts. Membership forces stronger protections: no NTLM, no Kerberos DES/RC4, no unconstrained delegation, no credential caching, and a non-renewable 4-hour TGT. Validate that those accounts never need NTLM before you add them.

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

AdminSDHolder / SDProp. Protected groups (Domain Admins, Enterprise Admins, etc.) have their ACLs stamped from the AdminSDHolder object every 60 minutes by the SDProp process. This is why custom permissions you set on a privileged account silently revert. The takeaway: audit AdminSDHolder itself for unexpected ACEs (a classic persistence backdoor), and stop fighting SDProp on individual protected accounts.

Disable legacy protocols. Disable SMBv1 everywhere, require SMB signing, and move to eliminate NTLM in favor of Kerberos. Audit NTLM before blocking it:

# Remove SMBv1 on a server
Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol -NoRestart

# Require SMB signing on DCs (also set via Default Domain Controllers Policy)
Set-SmbServerConfiguration -RequireSecuritySignature $true -Force

Set the GPO Network security: Restrict NTLM policies to Audit first, review the operational logs, then move to Deny for accounts that do not need it.

8. Backup and system-state restore

You back up AD by backing up system state on at least one DC per domain. Treat backups as Tier 0 assets and store them offline/immutable.

# 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

For a real disaster (deleted OU, mass object deletion), an authoritative restore is required so the restored objects out-replicate the tombstones. Boot the DC into Directory Services Restore Mode (the DSRM password from step 2), restore system state, then mark the subtree authoritative:

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

For accidental single-object deletion, the Active Directory Recycle Bin (enabled once per forest, irreversible) is far less disruptive than a DSRM restore:

Enable-ADOptionalFeature -Identity "Recycle Bin Feature" `
  -Scope ForestOrConfigurationSet `
  -Target "ad.example.com"

# Later, restore a deleted user
Get-ADObject -Filter 'Name -like "*Jdoe*"' -IncludeDeletedObjects |
  Restore-ADObject

Enterprise scenario

A logistics company we worked with had a “fully tiered” forest on paper, but their nightly backup jobs kept failing across Tier 1 file servers. The root cause was the tier model working correctly against an architecture mistake: the backup service ran as a single domain account that was a member of Domain Admins (a Tier 0 group), and a freshly applied Deny-logon URA GPO on Tier 1 servers blocked Tier 0 accounts from logging on as a batch job. The “fix” the previous team kept reaching for was to exempt the account from the GPO, which would have re-opened the exact lateral-movement path the tiering existed to close.

The correct fix was to stop using a god-account for a server-tier workload. We replaced it with a group-managed service account scoped to Tier 1, granted only the rights the backup agent actually needed, and added it to a Tier 1 group permitted to log on as a batch job. No Tier 0 credential ever touches a member server again.

# Create a Tier 1 gMSA and authorize only the backup servers to retrieve its password
New-ADServiceAccount -Name "gmsa-backup-t1" `
  -DNSHostName "gmsa-backup-t1.ad.example.com" `
  -PrincipalsAllowedToRetrieveManagedPassword "EXAMPLE\Tier1-BackupHosts" `
  -Path "OU=ServiceAccounts,DC=ad,DC=example,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 lesson: 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.

Verify

Health-check the forest before declaring victory and on a schedule afterward.

# Comprehensive per-DC health, run against every DC
dcdiag /v /c /e

# Replication status: failures, latency, and a summary
repadmin /replsummary
repadmin /showrepl
repadmin /queue

# Confirm FSMO placement matches your design
netdom query fsmo

# Confirm SYSVOL/Netlogon shared and DC is advertising
dcdiag /test:netlogons /test:advertising

# Confirm GC and DNS health
dcdiag /test:dns /e /v

dcdiag should pass every test on every DC, repadmin /replsummary should show zero failures and low largest-delta, and netdom query fsmo should match your intended layout exactly.

Deployment checklist

• Single forest / domain decision documented with namespace ad.example.com
• First DC promoted with Install-ADDSForest, DSRM password vaulted
• At least one replica DC online and replicating
• Sites and subnets created; DCs placed in correct sites
• FSMO roles placed per design and verified with netdom query fsmo
• OU tree built with Admin/Tier0/Tier1/Tier2 separation
• Delegation scoped to OUs; Domain Admins/Enterprise Admins/Schema Admins kept empty
• Tier 0/1/2 logon restrictions (Deny logon URA GPOs) enforced
• Authentication policy silos enforced for Tier 0
• PAWs deployed for Tier 0 admins
• Windows LAPS schema extended and rotating
• Tier 0 accounts in Protected Users (after NTLM dependency check)
• AdminSDHolder ACL audited for unexpected ACEs
• SMBv1 removed, SMB signing required, NTLM in audit-then-deny
• System-state backup running on a DC; AD Recycle Bin enabled
• dcdiag /v /c /e and repadmin /replsummary clean

Pitfalls and next steps

The mistakes that hurt most are rarely the deployment commands; they are the operational habits. Watch for: a single DC in production (build two, always), a Tier 0 admin “just checking email” on a PAW or RDP-ing from a laptop, service accounts with Domain Admin rights and a password that has not rotated since the Obama administration, and a resurrected dead FSMO holder. Each one quietly undoes the architecture.

From here, the natural next steps are gMSAs for every service account, an offline/immutable backup of Tier 0, AD CS deployed and hardened (it is a Tier 0 system and a notorious escalation path), and continuous monitoring of Tier 0 group membership and AdminSDHolder changes. Treat the tier model as a living control, not a one-time project: it only works for as long as nobody is allowed to break the one-directional rule.