Building a Modern Active Directory Attack-and-Defense Lab

I started Phase 10 of my Cyber Operations Center Engineering Program with an older Active Directory attack-lab outline. Instead of reproducing it exactly, I rebuilt the plan around Windows Server 2025, Windows 11, modern privilege separation and a clear distinction between secure identities and intentionally vulnerable ones.

Getting the domain controller healthy first

The lab domain is corp.lab.test and the domain controller is DC01. The initial promotion was not clean: DNS zones were incomplete and Active Directory Web Services did not come back correctly. I repaired ADWS, rebuilt the AD-integrated domain and _msdcs DNS zones, removed stale NAT registration, re-registered the correct records and validated domain-controller discovery and dcdiag /test:Connectivity.

That troubleshooting mattered more than a perfect install would have. Active Directory depends heavily on DNS, service discovery and the health of several tightly related Windows services, so the repair process forced me to understand the pieces instead of only clicking through a wizard.

Building roles instead of dumping users into Domain Admins

I created separate OUs for users, workstations, servers, service accounts, groups and privileged identities. Global role groups represent employees, SOC analysts, IT admins, server admins, workstation admins and Tier-0 admins. Domain Local groups represent where permissions are actually applied.

The administrative model now separates an everyday IT identity from a server/workstation administration identity and a dedicated Tier-0 identity. The Tier-0 account is marked as non-delegable, belongs to Protected Users, and receives Domain Admin authority through a Tier-0 role group rather than being added directly.

This is deliberately more structured than a tiny lab needs. The point is to learn the reason behind enterprise identity boundaries before I start attacking them.

Secure service identity beside a vulnerable one

I also created two different service-account patterns. A Group Managed Service Account uses a validated KDS root key and lets Active Directory manage the password automatically. Beside it is a clearly labelled lab-only legacy service account with a static non-expiring password and an MSSQL service principal name.

The second account exists specifically for the later Kerberoasting exercise. Keeping it separate from the secure baseline makes the lesson much clearer: the attack is not just "how to get a hash," but why a traditional service-account design creates that attack surface and what a modern managed identity changes.

Password spraying starts with understanding policy

The default domain policy had complexity enabled but only a seven-character minimum and no account lockout threshold. I changed the baseline to a 15-character minimum, 24-password history, 90-day maximum age and a 10-attempt lockout threshold with a 15-minute observation and lockout window.

That means the later password-spray exercise has to respect the defensive policy rather than blindly hammering authentication attempts. The lab is being built so the offensive action, the Windows Security events and the defensive response all connect to one another.

Where Phase 10 goes next

The domain controller is healthy, the core identity model is in place and PowerShell 7.6.6 is installed alongside Windows PowerShell. The next session starts with GPO-based privileged-logon boundaries and hardening. After that I will build the Windows 11 client and Kali attacker, connect Wazuh and Sysmon telemetry, run controlled password-spray and Kerberoasting exercises, write incident-response records and add Greenbone/OpenVAS vulnerability-management practice.

The larger lesson so far is that identity security makes more sense when administration and attack simulation are learned together. I want to know how to build the environment correctly, how common shortcuts break that model, what an attacker sees, and what the defender should be able to detect.

Read the Phase 10 progress record ↗