This document is both a technical record and a personal reflection on the process of building a tiered Active Directory domain in a home lab environment. The original goal was to create a secure, enterprise-like architecture with clear separation between Tier 0 (identity and privileged access), Tier 1 (servers), and Tier 2 (workstations), along with Privileged Access Workstations (PAWs) and Authentication Policy Silos.
What started as an ambitious project quickly became a humbling exercise in understanding the limits of rapid automation and the importance of respecting complex system architecture. The journey included significant setbacks, including corruption of the Active Directory database, a domain controller stuck in DSRM, and a point where I was prepared to reinstall the entire operating system on the physical server. Because this is a home lab built for learning, these struggles ultimately proved more educational than a smooth deployment ever could have been.
## The Initial Vision and Early Missteps
I set out to build the domain with a clean tiered structure. The high-level design looked like this:
```text
Domain Root (domainname.local)
├── Tier0
│ ├── Admins
│ ├── ServiceAccounts
│ ├── Computers
│ └── Groups
├── Tier1 (Servers)
│ ├── Servers
│ ├── Admins
│ ├── ServiceAccounts
│ └── Groups
├── Tier2 (Workstations & Users)
│ ├── Users
│ ├── Computers
│ ├── Admins
│ └── Groups
```
Early on, I tried to automate the creation of OUs and groups with PowerShell scripts. While the logic was sound, small errors (typos in SamAccountNames, incorrect OU paths) combined with Active Directory’s built-in protections created a cascade of problems. I spent far too much time fighting the GUI and attempting to force changes instead of verifying each step carefully.
## The Critical Mistake: Forcing Protected Objects
The most significant error occurred when I tried to implement advanced features like PAWs and Authentication Policy Silos. When critical system containers such as CN=Security were missing from the Configuration partition, I attempted to create them manually using commands such as:
```powershell
$configNC = "CN=Configuration,$((Get-ADDomain).DistinguishedName)"
New-ADObject -Type "container" -Name "Security" -Path $configNC -ProtectedFromAccidentalDeletion $true
```
I also bypassed "Protected from Accidental Deletion" flags and used raw ADSI and PowerShell scripts to force schema-related objects into existence. This was fundamentally misguided. These objects are not ordinary containers — they are deeply integrated into the Directory Service engine and must be created natively during domain promotion to establish proper internal references and security descriptors.
## The Breaking Point
These forced modifications created structural inconsistencies in the ntds.dit database. When I restarted services to apply the changes, the Directory Service detected the corruption and dropped the domain controller into Directory Services Restore Mode (DSRM) as a protective measure. At one point, the situation became so unstable that I was preparing to reinstall the entire operating system on the physical server because I could not successfully demote the domain controller.
## The Remediation Process
Recovery required a methodical, complete reset. I first entered DSRM remotely using:
```powershell
bcdedit /set safeboot dsrepair
shutdown /r /t 0
```
In DSRM, I attempted database repair with:
```cmd
esentutl /g "C:\Windows\NTDS\ntds.dit"
esentutl /p "C:\Windows\NTDS\ntds.dit"
ntdsutil
activate instance ntds
files
recover
quit
quit
```
When these repairs failed to restore consistency, I performed a complete demotion, manually deleted the corrupted database and log files:
```cmd
rd C:\Windows\NTDS /s /q
rd C:\Windows\SYSVOL /s /q
```
And then executed a clean domain promotion:
```powershell
Install-ADDSForest -DomainName "domainname.local" -InstallDns -SafeModeAdministratorPassword (ConvertTo-SecureString "YourDSRMPassword" -AsPlainText -Force)
```
Only after this clean promotion did I carefully rebuild the tiered OU structure and PAW configuration, allowing Windows to create all protected objects natively. This methodical approach ultimately averted the full operating system reinstall.
## Final Reflection
Because this is a home lab designed for learning, the failures — particularly the extensive time spent trying to force PAW implementation and the near-reinstall situation — were far more valuable than a smooth, trouble-free deployment would have been.
The experience forced me to slow down, research deeply, and develop genuine respect for Active Directory’s protected architecture. It taught me that "fast" scripting is not always "correct" scripting, and that bypassing native processes creates technical debt that eventually demands far more time to fix.
The hands-on work of entering DSRM, running repair tools, wiping corrupted files, and performing a clean rebuild provided insight I could not have gained any other way. In the end, I broke the domain, but I also fixed it. The rebuilt environment is stronger, cleaner, and far better understood. The lessons learned here — about patience, humility, and respecting system boundaries — will stay with me long after this lab is complete.