How to Create an Active Directory Homelab (Locally Hosted)

Today I’m building a locally hosted Active Directory environment to test attacks that need user interaction or specific misconfigurations without paying for cloud. Full control over VM configs, snapshots, and network. Easy to break and reset.

Prerequisites

• VMware Workstation Pro or VMware Player
• Minimum 16 GB RAM (works, but tight). 4 GB for DC, 2–4 GB for each Win10 VM.
• ~120 GB free storage (100 GB is possible, but you’ll feel it fast)
• Windows Server 2022 (or 2019) evaluation ISO
• Windows 10 Enterprise evaluation ISO
• (Optional) Kali VM on the same virtual network

Tip: Take a snapshot at the end of each major step. Saves hours later.

Grab the ISOs

1. Windows 10 Enterprise ISO
   Go here and fill out the form:
   https://info.microsoft.com/ww-landing-windows-10-enterprise.html
   
   
   
   Pick language → 64-bit.
   


2. Windows Server 2022 (or 2019) ISO
   https://info.microsoft.com/ww-landing-windows-server-2022.html
   Fill out the form → Download.
   
   
   
   Pick language and 64-bit.
   
   Downloads are ~10 GB total.

Create the Domain Controller VM (DC01)

File → New Virtual Machine → Custom.

Leave default hardware compatibility.

I will install the operating system later.

Guest OS: Microsoft Windows. Version: Windows Server 2022 (or 2019 if that’s your ISO).

Firmware: UEFI.

Processors: 1 vCPU.

Memory: 4096 MB (4 GB).

Network: NAT (simple and works with internet).

If you want complete isolation, use Host-only and add a second NIC later for internet.

I/O controller: default. Disk type: recommended (NVMe is fine).

Create a new virtual disk.

Size: 60 GB for the DC is comfortable. Split into multiple files.

Name the disk file and choose storage location.

Before power-on: Edit VM → CD/DVD (SATA) → Use ISO image file → select the Windows Server ISO.

Note: Don’t add a Floppy device.

Install Windows Server on DC01

Boot the VM, Press any key to boot from ISO.

Language, time, keyboard → Next.

Install.

Edition: Windows Server 2022 Standard Evaluation (Desktop Experience).

Accept license → Next.

Custom: Install Windows only.

Select the drive → Next.

Install runs.

Set Administrator password (ex: Steve123!).

Log in. Server Manager opens.

Snapshot here (baseline OS).

Give DC01 a static IP and correct DNS

Kerberos needs time + DNS right or nothing works.

• For NAT: set the Default Gateway to your NAT network gateway (VMnet NAT IP), and DNS to the DC’s own IP once DNS is installed (for now you can leave DNS blank or temporary to the VMnet gateway; we’ll fix after promotion).
• For Host-only: no gateway needed unless you add a second NIC.

Control Panel → Network → Adapter → Properties → IPv4:

• IP: 192.168.222.131 (example; use your subnet)
• Mask: 255.255.255.0
• Gateway: 192.168.222.2 (example VMnet NAT gateway)
• DNS: leave blank for now; we’ll switch to 192.168.222.131 after DNS is installed

Keep the DC’s clock in sync. Time skew breaks logons.

Promote DC01 to a Domain Controller (adds AD DS + DNS)

Open PowerShell as Administrator:

Install-WindowsFeature AD-Domain-Services -IncludeManagementTools

Install-ADDSForest -DomainName corp.test -DomainNetbiosName CORP -InstallDNS `
  -SafeModeAdministratorPassword (Read-Host -AsSecureString "DSRM") -Force

When asked for the DSRM password, use something you’ll remember (can match the local admin you set earlier).

Server will reboot. After reboot, sign in with CORP\Administrator.

Now switch the DC’s primary DNS to itself (192.168.222.131 in the example) and remove any other DNS.

Create two domain users (Skeleton, Spider)

Open dsa.msc (Active Directory Users and Computers).

corp.test → Users → Right click → New → User.

Create Skeleton (logon: skeleton). Set password (ex: Password1!) and check Password never expires (lab only).

Repeat for Spider. (Optional) Create OUs: CORP\Workstations, CORP\Users, and move objects.

Create the Windows 10 workstations (MS01, MS02)

New VM → Custom.

Compatibility default → I will install later.

Guest OS: Microsoft Windows → Windows 10 and later x64.

Name: MS01. Choose location.

Firmware: UEFI.

CPU: 1, RAM: 2 GB is okay; 4 GB is nicer.

Network: NAT (same network as DC).

I/O controller default. Disk: NVMe (default).

Create a new virtual disk (not “network” disk).

Disk size: 40–60 GB, Split into multiple files.

Customize Hardware → CD/DVD (SATA) → Use ISO image → Windows 10 ISO.

Clone for MS02
Right-click MS01 → Manage → Clone → From current state → Create a full clone → name it MS02.

Install Windows 10 on MS01/MS02

Boot MS01 → Press any key → Windows Setup.

Install now → Accept license → Custom → select drive → Next.

OOBE screens (region, keyboard, privacy). For domain testing, don’t use Microsoft account. Use the “Domain join instead” link if it shows, otherwise create a local user and we’ll join later.

Repeat the same on MS02. Install VMware Tools on both (VM → Install VMware Tools → Typical). Reboot later if you want.

Rename the computers before join: MS01 and MS02 (System Properties → Computer Name → Change). Reboot.

Point the workstations at the DC for DNS

On MS01 (as local admin), open PowerShell (Admin) and set DNS to the DC:

Get-DnsClientServerAddress | ft InterfaceAlias,InterfaceIndex,ServerAddresses

# choose the right interface; examples below:
Set-DnsClientServerAddress -InterfaceAlias "Ethernet0" -ServerAddresses 192.168.222.131
# or, if you prefer by index:
Set-DnsClientServerAddress -InterfaceIndex 3 -ServerAddresses 192.168.222.131

Use the actual IP of DC01. Repeat on MS02.

If DNS doesn’t point to the DC, domain join will fail. Always fix DNS first.

Join MS01 and MS02 to the domain

Settings → Accounts → Access work or school → Connect → Join this device to a local Active Directory domain.
Domain: corp.test (NetBIOS: CORP). Use CORP\Administrator or another domain user with join rights. Reboot when asked.

Note: Use the DC Administrator credentials you created when setting up the DC.

Repeat on MS02.

First domain logon test

On MS01 login screen: Other user → CORP\Skeleton (enter password you set).
On MS02: CORP\Spider.
If you get “The trust relationship…” errors, check time sync and DNS.

Quick validation

• On DC01, run Active Directory Users and Computers and verify both computer objects exist under Computers (or your Workstations OU).
• On MS01/MS02, run:

whoami
nltest /dsgetdc:corp.test
klist

You should see the domain and a Kerberos TGT.

Optional hardening/loosening (lab flavor)

• Disable WPS and change Wi-Fi if you’re using wireless bridging (lab stability).
• Turn Windows Defender real-time off on a lab box if you’re testing malware behaviors (leave it on if you’re testing detection).
• Enable RDP on MS01/MS02 and allow domain users.
• Create a few shares (CIFS), stand up IIS or SQL service accounts, etc.
• Build a basic OU/GPO structure and push some common misconfigs (LLMNR/NetBIOS settings, weak local admin password policy, unconstrained/RC4 for a service user, printer bug conditions).

Topology I’m using (example)

• DC01 – Windows Server 2022, 192.168.222.131, DNS + AD DS, Domain: corp.test (NetBIOS: CORP)
• MS01 – Windows 10 Enterprise, joined to CORP, user: Skeleton
• MS02 – Windows 10 Enterprise, joined to CORP, user: Spider
• Network – VMware NAT (vmnet8 in many installs). If you isolate with Host-only, add Kali to the same segment.

Done

You now have 1 DC + 2 workstations, two low-priv users, clean domain. From here, wire up whatever you want and break it safely. If your Kali VM lives on the same NAT/Host-only network, you’re ready to test enumeration, lateral movement, printer bug, relays, credential abuse, etc. Take snapshots before each experiment and after each “good state”.