Active Directory Home Lab 2026 — Windows Server 2022 Setup | CyberHawk Threat Intel

An Active Directory home lab is a small, isolated Windows domain running entirely inside virtual machines on your own computer. At its core sits a domain controller (DC) — a Windows Server that stores the directory database (NTDS.dit), authenticates users via Kerberos and NTLM, and answers DNS. Around it you add domain-joined clients and member servers, exactly as a real network would. Because it is fully isolated, you can run malware, dump credentials, and detonate exploits without any real-world risk.

A minimum viable lab is just two VMs:

Whether you are heading into red team, blue team, or IT administration, a working AD lab is the single most reused piece of infrastructure in your career. It is the prerequisite for nearly every other tutorial we publish — Kerberoasting, BloodHound, DCSync, Mimikatz, LLMNR poisoning, GPO abuse, and detection engineering in Sentinel or Splunk all assume you have a domain to point them at.

Windows Server 2022 with the Desktop Experience needs at least 2 GB RAM and 32 GB disk per Microsoft's baseline; in practice give the DC 4 GB and 60 GB so it does not thrash. These are per-VM figures for a lab, not production sizing.

All of the operating systems here are available as free evaluation media directly from the vendors. Server and Windows 11 evaluations run 180 days and 90 days respectively, which is more than enough for a lab, and both can be rearmed. Download only from official sources.

Decide your addressing and names before you build. AD depends entirely on DNS: every domain member must use the DC as its DNS server, or nothing works. We use a private 10.10.10.0/24 range on an isolated virtual switch, with the DC holding a static IP that also serves as the DNS server for the whole domain.

Install VirtualBox and the Extension Pack, then create the DC VM. VirtualBox has a headless VBoxManage CLI that makes VM creation scriptable — useful once you have done it by hand once. The commands below create a 4 GB / 2–vCPU VM named DC01 on an internal network called adlab.

Boot the VM from the ISO and step through Windows Setup. The one choice that matters: pick an edition ending in (Desktop Experience) — the plain edition installs Server Core with no GUI, which is harder for a first lab. Choose a Custom install onto the empty 60 GB disk and set a strong local Administrator password.

• 1
  Select language/keyboard → Install now.
• 2
  Edition: choose Windows Server 2022 Standard (Desktop Experience).
• 3
  Accept the license → choose Custom: Install Windows only.
• 4
  Select the 60 GB disk → Next. Windows copies files and reboots.
• 5
  Set the Administrator password (e.g. P@ssw0rd!Lab2026 for a lab).
• 6
  Install VirtualBox Guest Additions: Devices menu → Insert Guest Additions CD → run the installer → reboot.

Build the DC VM through the New Virtual Machine wizard, then isolate its NIC on a LAN Segment so the vulnerable domain never touches your physical network. The steps below produce the same 4 GB / 60 GB DC as Method 1.

• 1
  File → New Virtual Machine → Typical → point to WS2022_EVAL.iso.
• 2
  Guest OS: Windows Server 2022. Name it DC01, 60 GB disk, store as a single file.
• 3
  Customize Hardware → Memory 4096 MB, Processors 2.
• 4
  Network Adapter → LAN Segment → Add a segment named adlab → assign it.
• 5
  Finish, boot, and install Windows Server exactly as in Method 1, Step 02.
• 6
  Install VMware Tools (VM menu → Install VMware Tools) and reboot.

Rather than installing Windows again for every machine, build one "golden" Windows 11 VM, sysprep-generalise it, then use linked clones to spin up clients cheaply. Linked clones share the base disk, so five clients cost only their deltas — huge disk savings on a laptop.

• 1
  Right-click the powered-off golden VM → Manage → Clone.
• 2
  Choose Create a linked clone → name it WKS01.
• 3
  Ensure the clone's NIC is on the same adlab LAN Segment.
• 4
  Boot, finish OOBE, rename, then domain-join (Section 08).

Create an internal-only Linux bridge with no physical uplink — the Proxmox equivalent of VirtualBox's Internal Network. VMs attached to it are isolated from the outside world. Then upload the Windows ISOs to local storage.

Proxmox's qm CLI provisions VMs in one shot. Windows guests need the VirtIO driver ISO mounted as a second CD during install (for the network and disk drivers), or you can use SATA/e1000 for simplicity on a first build. The command below creates VM 101 as DC01 on the isolated vmbr1.

A domain controller must have a fixed IP — clients will hardcode it as their DNS server. Set the static address, point the DC's own DNS at itself, and rename the machine to DC01 before promotion (renaming a DC afterwards is far messier). Find your interface name first with Get-NetAdapter.

After the rename reboot, install the Active Directory Domain Services role and its management tools. This stages the binaries but does not yet make the server a DC — that is the promotion step that follows.

Now promote DC01 into the first domain controller of a brand-new forest called cyberhawk.lab. Install-ADDSForest installs DNS automatically, sets the forest/domain functional levels, and prompts for the Directory Services Restore Mode (DSRM) password. When it finishes, the server reboots as a live DC.

Forward DNS was created during promotion; add a reverse lookup zone so PTR records resolve. It is not strictly required for a domain to function, but many tools and logs expect reverse resolution, and it makes the lab behave like a real network.

DHCP lets clients on the internal network get an address automatically and, crucially, receive the DC as their DNS server via option 006. Install the role, authorize it in AD, and create a scope for the lab subnet.

Organisational Units are how you group objects for delegation and GPO targeting. A realistic lab mirrors a small company: departments for users, plus containers for workstations and servers. Build them with a loop so it is trivial to reproduce.

Populate the domain with users so attacks and detections have something to chew on. The snippet below creates a batch of enabled users in the IT OU, then a security group, then adds them to it. In a real lab you would import a CSV, but this shows the mechanics.

Group Policy is how AD pushes configuration to every joined machine. Create a GPO, link it to an OU, and set a registry-backed value. Enabling command-line and PowerShell logging here is doubly useful — it teaches GPO mechanics and gives your blue-team detections real telemetry to work with.

If you set up DHCP in Section 07, the client gets the correct DNS automatically. If not, set it manually. Then confirm the client can resolve the domain and reach the DC before attempting the join.

You can join through Settings → System → About → Rename this PC (Advanced) → Change → Member of Domain, or in one PowerShell command. The command renames and joins in a single step, prompting for domain admin credentials, then reboots.

After reboot, log in as a domain user (CYBERHAWK\jsmith) at the "Other user" prompt. Confirm the trust from the client, and confirm the computer object appeared in AD on the DC.

BadBlood (by Secframe) fills a domain with thousands of randomised users, groups, computers, OUs, and ACLs — instantly turning an empty lab into something that looks like a real, messy enterprise with attack paths. Run it against a lab you can throw away, never anything real.

Real attack paths run through application servers, not just the DC. Stand up SRV01 as a domain-joined member server and give it services worth attacking — a file share for share-hunting, IIS for web, and optionally SQL Server for a classic privilege-escalation path.

Add a Kali VM on the same internal network to run enumeration and attacks. If you want a ready-made vulnerable forest instead of hand-crafting misconfigurations, the open-source GOAD (Game of Active Directory) project builds a multi-domain lab riddled with real attack paths using Vagrant and Ansible.

Run these periodically to confirm the domain is healthy, especially after adding DCs or reverting snapshots. dcdiag and repadmin are the two workhorse tools every AD admin lives by; time sync is the most common silent killer in a lab that has been paused and resumed.

Nearly every AD lab failure traces back to DNS or time. Work this table top to bottom before assuming anything more exotic.

You now have a working, extensible AD lab. Point the tools you have been reading about at it and start generating attacks and detections.