Building a Nested Active Directory Lab in Proxmox
How to build a self-contained Active Directory environment — a domain controller, a member server, and a client — as isolated VMs on a single Proxmox host, so you can break real AD problems on purpose and rebuild from a clean snapshot in minutes.
A Proxmox Linux bridge with no physical uplink, keeping the lab’s traffic off your real network.
A locked, un-startable base VM you clone instead of reinstalling an OS for every new lab box.
A point-in-time checkpoint of a VM’s disk (and optionally memory) you can revert to in seconds.
What Is a Nested AD Lab?
A nested AD lab, in this context, is not nested virtualization — you don’t need a hypervisor running inside a VM, and no CPU virtualization passthrough is required. “Nested” here means nesting a complete, self-contained Active Directory topology inside a single Proxmox host: a domain controller, a member server, and a client, all as ordinary VMs, wired together on their own private network segment that has nothing to do with your home or office LAN.
Think of it as a diorama of a real on-prem AD environment — small enough to fit on one box, but built from the same pieces (a DC, a domain-joined server, a domain-joined client) that make up the real thing, so problems you hit and fix here transfer directly to production troubleshooting.
Why Build It in Proxmox Instead of a Desktop Hypervisor?
VirtualBox, VMware Workstation, and client Hyper-V all run a lab fine in principle. Proxmox earns its place for a homelab AD environment specifically because of what it does once the lab exists, not just while you’re building it.
Runs on a dedicated box, not your daily-driver laptop — the lab survives reboots, sleep, and you closing your laptop lid.
Build a base Windows Server image once, then clone a new DC or member server in seconds instead of reinstalling an OS.
Checkpoint a VM before a risky change — a domain promotion, a GPO test, a schema extension — and revert instantly if it goes wrong.
The combination matters more than any single feature: a template you clone in seconds, snapshotted right before the risky step, turns “I broke my lab, I’ll rebuild it this weekend” into “I broke my lab, give me two minutes.”
Why a Real Topology Matters
A single VM with AD DS installed on it teaches you almost nothing about how AD actually behaves in production, because most real AD problems live in the gaps between machines: DNS resolution from a client to a DC, Kerberos ticket exchange across a domain join, secure channel health between a member server and its DC, GPO application landing correctly on a client that isn’t the DC itself. None of that exists to test until there’s more than one box.
A DC, a member server, and a client is the smallest topology that still exposes those gaps. It’s enough to genuinely test domain join, Kerberos authentication, Group Policy application, and DNS resolution the way they actually fail in the field — not enough to need a rack of hardware.
Configuration: Isolated Network and VM Sizing
Build an isolated bridge first, before creating any VMs. In the Proxmox web UI, go to the node’s System > Network tab, click Create > Linux Bridge, give it a name (e.g. vmbr1), leave IPv4/IPv6 blank, and — critically — leave Bridge ports empty. An empty bridge-ports field means the bridge has no physical NIC attached, so nothing on it can reach your real network.
# Equivalent /etc/network/interfaces stanza for an isolated bridge
# "bridge-ports none" is what keeps this bridge off any physical NIC
auto vmbr1
iface vmbr1 inet manual
bridge-ports none
bridge-stp off
bridge-fd 0Point every lab VM’s network adapter at vmbr1 instead of the default vmbr0. With no physical uplink, the DC’s DHCP scope, DNS server, and Kerberos traffic all stay inside the lab.
| Role | vCPU | RAM | Disk |
|---|---|---|---|
| Domain Controller | 2 | 4 GB | 64 GB |
| Member Server | 2 | 4 GB | 64 GB |
| Client (Windows 11) | 2 | 4 GB | 64 GB |
These figures track Microsoft’s own published guidance rather than a rule of thumb: Windows Server’s absolute floor is 512 MB of RAM and 32 GB of disk, but Microsoft recommends at least 4 GB of RAM and 64 GB of disk once Desktop Experience is involved — and every role above benefits from having headroom rather than running at the documented minimum.
Commands: Building, Cloning, and Snapshotting
# Create the base Windows Server VM that will become your template
# (install the OS from ISO, patch it, then convert it — don't clone this raw)
qm create 200 --name win2025-template --memory 4096 --cores 2 `
--net0 virtio,bridge=vmbr1 --scsihw virtio-scsi-single `
--scsi0 local-lvm:64 --ide2 local:iso/en-us_windows_server_2025.iso,media=cdrom `
--boot order=scsi0
# After Windows is installed, patched, and generalised, lock it as a template
qm template 200
# Clone the template into your three lab VMs - full clones so each one
# is fully independent once it becomes a domain controller or is joined
qm clone 200 201 --name dc01 --full
qm clone 200 202 --name member01 --full
qm clone 200 203 --name client01 --full
# Enable the QEMU guest agent on each VM (requires a full stop/start,
# not just a reboot, to attach the virtual serial device)
qm set 201 --agent 1
qm set 202 --agent 1
qm set 203 --agent 1
# Snapshot dc01 right before promoting it - this is your instant undo
qm snapshot 201 pre-domain-join --description "Before AD DS install and promotion"virtio-win ISO, update the “PCI Simple Communications Controller” device in Device Manager from its vioserial folder, then run qemu-ga-x86_64.msi from the ISO’s guest-agent folder.
With the VMs cloned, install the AD DS role on dc01 and promote it, then join the member server and client to the new domain:
# On dc01: install the AD DS role
Install-WindowsFeature -Name AD-Domain-Services -IncludeManagementTools
# Promote dc01 to the first DC in a new forest
Install-ADDSForest -DomainName "lab.example.internal" `
-DomainNetbiosName "LAB" -InstallDNS
# On member01 and client01, after they can resolve and reach dc01:
# point their DNS at the DC, then join the domain
Add-Computer -DomainName "lab.example.internal" `
-Credential (Get-Credential) -RestartTroubleshooting Cheat Sheet
| Symptom | Likely Cause | Fix |
|---|---|---|
| Lab VMs have no internet access | Expected — the isolated bridge has no physical uplink by design. | If outbound access is genuinely needed, add a second NIC on vmbr0 to specific VMs, or configure NAT/masquerading on the Proxmox host rather than removing the isolation. |
| Domain join fails with “the domain could not be contacted” | The client or member server’s DNS still points at a public or ISP DNS server instead of the new DC. | Set the VM’s static DNS server to the DC’s IP address before attempting the join — AD relies on its own DNS for domain location. |
| Kerberos errors right after building the lab | Clock drift between the Proxmox host and the guest VMs, common right after a clone or snapshot revert. | Confirm the guest agent is running and the Windows Time service has synced; Kerberos tolerates only a few minutes of skew by default. |
| Second “DC” clone causes replication or SID conflicts | A VM was cloned after being promoted to a domain controller, duplicating its AD database and identity. | Discard the bad clone; always clone from the pre-promotion template, then promote each DC individually. |
| DC behaves oddly after a snapshot revert, but no errors are visible | Normal — Proxmox auto-generates a VM Generation ID (vmgenid) for new VMs, and Windows Server 2012+ domain controllers use a generation ID change to detect the revert and protect themselves automatically. |
No action needed for a single-DC lab; if you ever see this on a multi-DC setup, read USN Rollback Detected — Event 2095 for what the DC does behind the scenes. |
| Cloned VM boots with the same hostname or IP as its source | A full clone copies disk state exactly, including Windows’s machine SID and any static network configuration baked into the template. | Generalise the template with Sysprep before converting it, and set hostname/IP per clone during first boot rather than baking them into the template. |
Final Thoughts
The value of this lab isn’t the three VMs themselves — it’s the fact that breaking them costs nothing. A snapshot before every risky step turns “I’m not sure I want to try this on a real DC” into “let me just try it and revert if it’s wrong,” which is exactly the mindset that builds real AD troubleshooting skill instead of theoretical knowledge.
Keep the template clean and generalised, keep the network isolated, and snapshot before anything that touches AD DS, GPOs, or schema. Everything else in this environment is disposable by design.
qm clone and a snapshot away from being safely disposable, which is the entire point of running the lab in Proxmox instead of on bare metal.
With a working DC, member server, and client in place, a natural next step is Proxmox networking itself — Linux bridges, VLANs, and NIC bonding — for labs that need more than one isolated segment or want to simulate multiple sites.