Build an Active Directory Security Lab: Step-by-Step Guide

Why you build your own lab

You will not master Active Directory security by reading about it. The detections in this course fire against events a real domain produces when a real attack runs, and the only way to see a Kerberos 4769 with an RC4 encryption type, or a 5136 writing a delegation attribute, land in a log you can query is to run the thing that produces it on a domain you control. The course ships an in-platform environment, the Northgate corpus and the Incident Lab, and that fallback is useful when you are away from your own machine. But the corpus is a recording. Your lab is the instrument, and this guide builds it.

This is a build guide written for someone who has not stood up a domain before. Follow the steps in order. Each step names the exact screen, the exact button, and what you should see before you move on. Where a step can also be done in one PowerShell line, that line is given in a separate block marked Faster, if you know PowerShell, but you never need it: the click-path is the primary route and it is complete on its own.

You do not build the whole thing at once. Steps 1 to 5 stand up a working domain with one workstation and an attacker, which is everything you need to begin the course. Steps 6 to 9 extend the lab, and because you will have done each action once by then, those steps are written as short deltas rather than full walk-throughs.

The finished lab. Build the core first (Steps 1 to 5), extend later (Steps 6 to 9).

What you need before you start

Download these first. Every one is free for lab use. Save them somewhere you can find them.

• A hypervisor. VMware Workstation Pro (free for personal use from the Broadcom site) is the recommendation. VirtualBox (free, virtualbox.org) works if you prefer it. This guide names VMware screens; VirtualBox has equivalents with slightly different labels.
• Windows Server 2022 Evaluation ISO from the Microsoft Evaluation Center. This is a full 180-day copy, free, no license key needed. You use it for every server.
• Windows 11 Enterprise Evaluation ISO from the same place, for the workstations.
• Kali Linux, the prebuilt VMware image from kali.org (choose the VMware or VirtualBox image, not the installer ISO, it is faster to import).

Your host machine needs at least 16 GB of RAM (about 12 GB is in use while the core lab runs) and roughly 120 GB of free disk for the full seven-machine build. Before you start, reboot into your host's BIOS and confirm CPU virtualization is enabled (it is called Intel VT-x or AMD-V); without it, VMs will not run. On a Windows host, if a VM later refuses to start, the fix is almost always to disable Hyper-V, which takes the virtualization hardware for itself.

A note on names and addresses used throughout: the domain is corp.lab, the network is 10.10.0.0/24, and each machine gets a fixed address (DC01 is 10.10.0.10, and so on). Use these exactly as written and the commands in this guide will match your screen.

Step 1 — Create the isolated lab network

The network comes before any machine, and it is the one thing you must get right for safety. By default a new VM is given internet access, and an attack lab must never reach anything you do not own. You create a private, sealed network and put every machine on it.

1. Open VMware Workstation. From the top menu choose Edit, then Virtual Network Editor. If the settings are greyed out, click Change Settings and approve the admin prompt.
2. Click Add Network. Pick an unused name such as VMnet2 and click OK.
3. With VMnet2 selected, choose Host-only (the option labelled "connect VMs internally in a private network"). This is what seals the lab off from the internet.
4. In the subnet fields, set Subnet IP to 10.10.0.0 and Subnet mask to 255.255.255.0.
5. Untick "Use local DHCP service to distribute IP addresses to VMs." You turn DHCP off on purpose: the domain controllers need fixed addresses you assign by hand, and DHCP would interfere.
6. Click Apply, then OK.

Remember the network name (VMnet2 in this example). Every VM you build in the steps below has its network adapter set to this network, never to NAT or Bridged. You will confirm the network is actually sealed in Step 3, once the first machine is running.

Step 2 — Build the first server VM (DC01)

DC01 is the foundation of the whole lab: the first domain controller, and the machine every other machine joins to. This step builds the empty Windows Server VM. Step 3 turns it into a domain controller.

1. In VMware, choose File › New Virtual Machine. Select Typical and click Next.
2. Choose Installer disc image file (iso) and browse to your Windows Server 2022 Evaluation ISO. Click Next.
3. When asked, name the machine DC01 and choose where to store it. Click Next.
4. Set the disk size to 60 GB, leave "Store virtual disk as a single file" selected, and click Next.
5. Click Customize Hardware. Set Memory to 4096 MB and Processors to 2. Select Network Adapter and change it from NAT to Custom, then pick VMnet2 (the host-only network from Step 1). Click Close, then Finish.
6. The VM powers on and boots the installer. When prompted, choose the edition Windows Server 2022 Standard (Desktop Experience), accept the license, and choose Custom install. Select the 60 GB disk and let it install. This takes a few minutes and the machine reboots on its own.
7. At the end you are asked to set a password for the local Administrator account. Choose a strong password you will remember, you will use it constantly. You are now at the server desktop.

Before going further, install VMware Tools so the display and mouse behave: menu VM › Install VMware Tools, then run the installer inside the guest and reboot.

Step 3 — Give DC01 a fixed address and promote it to a domain controller

This is the step that creates your domain. You do two things: pin DC01 to a fixed IP that points DNS at itself, then run the promotion wizard that builds the corp.lab forest.

Set the fixed IP (GUI):

1. Right-click the network icon in the taskbar and open Network and Sharing Center, or open Settings › Network & Internet. Click Change adapter options.
2. Right-click the Ethernet adapter, choose Properties, select Internet Protocol Version 4 (TCP/IPv4), and click Properties.
3. Choose Use the following IP address and enter: IP address 10.10.0.10, Subnet mask 255.255.255.0. Leave the Default gateway blank (the lab has no gateway; that is what keeps it sealed).
4. Choose Use the following DNS server addresses and enter 127.0.0.1. A domain controller must use itself for DNS. Click OK, then Close.

# Faster, if you know PowerShell (run as Administrator):
Rename-Computer -NewName "DC01" -Restart
# after reboot:
New-NetIPAddress -InterfaceAlias "Ethernet0" -IPAddress 10.10.0.10 -PrefixLength 24
Set-DnsClientServerAddress -InterfaceAlias "Ethernet0" -ServerAddresses 127.0.0.1
# note: your adapter may be "Ethernet" or "Ethernet1"; check with Get-NetAdapter

Add the AD DS role (GUI):

1. Server Manager opens automatically at logon. Click Manage (top right), then Add Roles and Features.
2. Click Next through "Before you begin", leave Role-based or feature-based installation selected, Next. Your server is already highlighted in the server pool, Next.
3. On the Server Roles page, tick Active Directory Domain Services. A box pops up listing supporting features, click Add Features. Click Next through the remaining pages and then Install. When it finishes, Close.

Promote to a domain controller (GUI):

1. In Server Manager a yellow warning flag appears near the top. Click it, then click Promote this server to a domain controller.
2. On the Deployment Configuration page choose Add a new forest. In Root domain name type corp.lab. Click Next.
3. On Domain Controller Options, leave the functional levels at their defaults, ensure DNS server is ticked, and set a Directory Services Restore Mode (DSRM) password (record it). Next.
4. Click Next through the DNS delegation warning (expected, harmless in a lab), the NetBIOS name (it fills in CORP automatically), and the paths pages. On the Review page, Next, let the prerequisites check run, then click Install.
5. The server reboots itself and comes back up as the first domain controller of corp.lab. At the logon screen you now sign in as CORP\Administrator.

# Faster, if you know PowerShell (run as Administrator):
Install-WindowsFeature AD-Domain-Services -IncludeManagementTools
Install-ADDSForest -DomainName "corp.lab" -DomainNetbiosName "CORP" -InstallDns -Force

Confirm the domain is alive. Open Server Manager, or run:

Get-ADDomain | Select-Object Name, DNSRoot
# EXPECT: Name = corp, DNSRoot = corp.lab

Create a few accounts so the domain has identities to work with. In Server Manager choose Tools › Active Directory Users and Computers, expand corp.lab, right-click the Users container, choose New › User, and create an ordinary user (for example j.analyst) and an admin user (for example l.admin). To make l.admin a domain admin, double-click it, open the Member Of tab, click Add, type Domain Admins, and confirm.

# Faster, if you know PowerShell:
New-ADUser -Name "Jane Analyst" -SamAccountName j.analyst -AccountPassword (Read-Host -AsSecureString "pw") -Enabled $true
New-ADUser -Name "Lab Admin" -SamAccountName l.admin -AccountPassword (Read-Host -AsSecureString "pw") -Enabled $true
Add-ADGroupMember -Identity "Domain Admins" -Members l.admin

Finally, in VMware take a snapshot of DC01 (VM › Snapshot › Take Snapshot), name it dc01-clean. A snapshot is a saved state you can return to instantly, so if a later attack breaks something you revert here rather than rebuilding.

Step 4 — Verify the lab is sealed and DNS works

Before adding any more machines, prove two things: the lab cannot reach the internet, and the domain name resolves.

# On DC01. The first MUST fail, the second MUST succeed.
Test-Connection 8.8.8.8 -Count 2
# CORRECT: "could not find host" / no reply. If it SUCCEEDS, the network
# adapter is not host-only. Go back to Step 1 and fix it before continuing.

Resolve-DnsName corp.lab
# EXPECT: an answer pointing at 10.10.0.10

Step 5 — Add the first workstation (WS01) and the attacker (Kali)

With a working domain, add one workstation and the attacker. This completes the core lab you can start the course on.

WS01 (Windows 11):

1. Build a new VM exactly as in Step 2, but choose the Windows 11 Evaluation ISO, name it WS01, give it 4096 MB RAM and 2 processors, disk 64 GB, and set its network adapter to VMnet2. Install Windows 11, and when it asks, create a local account (if the installer insists on a Microsoft account, disconnect it from the network briefly or choose the "domain join instead" / offline option). Install VMware Tools.
2. Give WS01 a fixed address the same way you did for DC01 (Change adapter options › IPv4 Properties): IP 10.10.0.50, mask 255.255.255.0, gateway blank, and DNS 10.10.0.10 (DC01, not 127.0.0.1 this time, and not a public DNS).
3. Join it to the domain. Open Settings › System › About › Domain or workgroup, click Change, choose Domain, type corp.lab, and when prompted enter CORP\l.admin and its password. You will see "Welcome to the corp.lab domain." Reboot.

# Faster, if you know PowerShell (run as Administrator on WS01):
New-NetIPAddress -InterfaceAlias "Ethernet0" -IPAddress 10.10.0.50 -PrefixLength 24
Set-DnsClientServerAddress -InterfaceAlias "Ethernet0" -ServerAddresses 10.10.0.10
Add-Computer -DomainName "corp.lab" -Credential (Get-Credential) -Restart

1. After the reboot, at the logon screen choose Other user and sign in as CORP\j.analyst. That logon writes a 4624 event to DC01's Security log, your first piece of real telemetry. Take a snapshot named ws01-clean.

Kali (attacker):

1. In VMware choose File › Open, browse to the Kali image you downloaded, and import it. Open its Settings, set Memory to 4096 MB, Processors to 2, and the Network Adapter to VMnet2. Kali does not join the domain; it sits on the network as an unauthenticated outsider, which is exactly where a real attacker starts.
2. Boot Kali (default credentials kali / kali), and confirm it is sealed and can see the domain machines:

ping -c2 8.8.8.8        # MUST fail (no internet)
ping -c2 10.10.0.10     # MUST succeed (DC01)
ping -c2 10.10.0.50     # MUST succeed (WS01)
# If a Windows target does not reply, its firewall may block ping; that is
# fine for now, it does not mean the network is broken.

1. Take a snapshot named kali-baseline.

You can now start the course. DC01 is serving the corp.lab domain, WS01 is joined and logging on, and Kali is positioned to attack. The remaining steps extend the lab when a later module needs them, and because you have now done each action once, they are written as short deltas.

Step 6 — Add a second domain controller (DC02)

DC02 makes replication real: a change on DC01 does not appear on DC02 instantly, and later modules need two controllers to show that.

Build a Server 2022 VM as in Step 2, name it DC02, IP 10.10.0.11, DNS pointed at DC01 (10.10.0.10). Add the AD DS role as in Step 3, but on the promotion wizard choose Add a domain controller to an existing domain (not a new forest), enter corp.lab, and supply CORP\l.admin when asked. Reboot. Confirm both controllers exist:

Get-ADDomainController -Filter * | Select-Object Name, IPv4Address
# EXPECT: DC01 and DC02
repadmin /replsummary          # EXPECT: no failures

Step 7 — Add the child domain (DC03)

A child domain, branch.corp.lab, teaches trusts. Promoting a child creates a parent-child trust automatically, and that trust is a path an attacker moves along between domains.

Build a Server 2022 VM, name it DC03, IP 10.10.0.12, DNS pointed at DC01. Add the AD DS role, and on the promotion wizard choose Add a new domain to an existing forest, set domain type to Child Domain, parent corp.lab, new domain name branch. Supply CORP\l.admin. Reboot, then confirm the trust:

Get-ADTrust -Filter * | Select-Object Name, Direction
# EXPECT: a trust between corp.lab and branch.corp.lab

Step 8 — Add the resource server (SRV01)

SRV01 is a member server, not a controller, standing in for the file and application servers an attacker is ultimately after. Build a Server 2022 VM, name it SRV01, IP 10.10.0.20, DNS at DC01. Do not add the AD DS role. Instead join it to the domain the same way you joined WS01 (System › About › Domain or workgroup › Change), enter corp.lab, authenticate as CORP\l.admin, reboot. Snapshot srv01-clean.

Step 9 — Add the second workstation (WS02)

WS02 gives you a second endpoint for practicing lateral movement. Build it exactly as WS01 in Step 5, IP 10.10.0.51, DNS at DC01, joined to corp.lab. Snapshot ws02-clean.

Final check

Run this on DC01 once the machines you need are built. It confirms the lab is working and still sealed.

Get-ADDomainController -Filter * | Select-Object Name, IPv4Address   # your DCs
Get-ADComputer -Filter * | Select-Object Name                       # SRV01 + WS01/02
Get-ADTrust -Filter *   | Select-Object Name, Direction             # child-domain trust
Test-Connection 8.8.8.8 -Count 2                                    # MUST still fail
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624} -MaxEvents 5
# EXPECT: recent 4624 logon events from your workstation sign-ins

If every controller is listed, the trust exists, the internet ping fails, and the Security log is recording 4624s, the lab is ready and the telemetry the course reads first is already flowing.

Tooling comes with the modules

You do not install a toolkit now. A working domain already produces the Windows Security Event Log, the telemetry this course reads first, so the early detection modules have real evidence the moment a workstation logs on. Where a later module needs a specific tool, an auditing utility to find a weakness, or a detection tier beyond the native log, that module tells you what to add and why, at the point you use it. Build the domain, keep your snapshots, and add tooling as the course reaches it.

If you cannot run this lab, on a machine without the memory or disk, the Northgate corpus and the Incident Lab give you the same techniques to practice against a fixed dataset. Use them when you must. But when you can, build the lab, because watching your own domain produce the evidence and then breaking it on purpose is the difference between knowing the detection and knowing the subject.