HackBlue

Tools · Active Directory defense · 01 / 23

How to build a small Active Directory lab for security practice

Stand up a domain controller, a member server, and a workstation on an isolated network, seed realistic users and groups, and snapshot it before every exercise.

12 min read · practice only with authorization

A minimal useful design

Three virtual machines are enough: a Windows Server domain controller, a second Windows Server as a file or application server, and a Windows 10 or 11 workstation. Microsoft offers time-limited evaluation editions for exactly this purpose. Put them on a host-only or internal network with no route to your home or work network, and give the DC a static address.

Name the domain something that cannot collide with a real one, such as lab.internal or corp.test. Avoid using a public domain you do not own.

Promote the domain controller

Install the AD DS role and promote the server to a new forest with PowerShell. The DC also becomes the DNS server, so point the other machines’ DNS at it before joining them to the domain. Set the Directory Services Restore Mode password and store it in your lab notes.

Snapshot the DC immediately after promotion. This is the clean state you will return to after exercises that change the directory.

Snippet
Install-WindowsFeature AD-Domain-Services -IncludeManagementTools
Install-ADDSForest -DomainName 'lab.internal' -DomainNetbiosName 'LAB' -InstallDns -SafeModeAdministratorPassword (Read-Host -AsSecureString 'DSRM password')
# after reboot, on each member
Set-DnsClientServerAddress -InterfaceAlias Ethernet -ServerAddresses 192.168.56.10
Add-Computer -DomainName lab.internal -Restart

Lab: seed users, groups, and a few mistakes

Create OUs for Admins, Staff, Servers, Workstations, and Service Accounts. Create a dozen users, a helpdesk group, a service account with a servicePrincipalName, and a separate admin account for yourself. Then deliberately add a few common misconfigurations so later lessons have something to find: a service account with a weak password and an SPN, a user with Kerberos pre-authentication disabled, and a stale account.

Turn on the advanced audit policy on the DC from the Windows family tutorials so every exercise produces events.

Snippet
'Admins','Staff','Servers','Workstations','Service Accounts' | % { New-ADOrganizationalUnit -Name $_ -Path 'DC=lab,DC=internal' }
1..12 | % { New-ADUser -Name "user$_" -Path 'OU=Staff,DC=lab,DC=internal' -AccountPassword (ConvertTo-SecureString 'Lab-Passw0rd!2026' -AsPlainText -Force) -Enabled $true }
New-ADUser -Name svc_sql -Path 'OU=Service Accounts,DC=lab,DC=internal' -ServicePrincipalNames 'MSSQLSvc/srv01.lab.internal:1433' -AccountPassword (ConvertTo-SecureString 'Summer2026!' -AsPlainText -Force) -Enabled $true
Set-ADAccountControl -Identity user7 -DoesNotRequirePreAuth $true

Lab rules

Keep the lab isolated, use evaluation licenses, and never reuse real passwords. Snapshot before each exercise and revert after. Install defensive tools first: Sysmon, log forwarding to a small collector, and PingCastle for health checks.

Treat the lab as the only place where you run collection tools such as BloodHound’s SharpHound, unless your employer has explicitly approved running them in production.

Diagram

Lab build order

  1. Network

    Isolated host-only network, static DC address.

  2. DC

    Install AD DS and DNS, promote, snapshot.

  3. Members

    Point DNS to the DC and join the server and workstation.

  4. Seed

    OUs, users, groups, a service account, and planted mistakes.

Check yourself

1. What must member machines use for DNS before joining the domain?

2. Why snapshot right after promoting the DC?

3. Which domain name is a good lab choice?