How to Build a Free Active Directory Lab Without Wasting SSD Space

Introduction

If your goal is to pass practical cybersecurity certifications like the OSCP, PNPT, or land a job as a penetration tester, you cannot ignore Active Directory (AD). Over 90% of enterprise networks rely on AD for identity and access management, making it the primary target during any red team engagement or internal assessment.

The best way to master Active Directory hacking is by building your own safe, contained environment. However, many traditional IT guides instruct you to spin up multiple full-sized Windows Server virtual machines, which can easily swallow over 100 GBs of your local storage and drag down your computer’s performance.

In this guide, we are going to build an Active Directory laboratory from scratch on a single PC. Best of all, we will use a clever virtualization design pattern Linked Clones, allowing our entire running infrastructure to occupy less than 40 GB of total space on your SSD.

Prerequisites & Software Downloads

To follow along with this build, you will need to download three components. You can find direct links to the official vendor portals below:

VMware Workstation Pro (or VMware Fusion Pro for macOS): Broadcom recently made the full Pro versions completely free for everyone (including commercial use). Note: You will need to create a quick, free account on the Broadcom support portal to access the download. https://support.broadcom.com/group/ecx/downloads?segment=VC
Windows Server 2022 ISO: Available for free via the Microsoft Evaluation Center under their 180-day trial program. This version is ideal because it remains the most widely deployed Server OS in current corporate environments. https://go.microsoft.com/fwlink/p/?linkid=2195686&clcid=0x409&culture=en-us&country=us
Kali Linux (VMware Architecture Pre-baked Image): Available on the official ‘Get Kali’ website under the ‘Virtual Machines’ section. https://cdimage.kali.org/kali-2026.2/kali-linux-2026.2-vmware-amd64.7z

Step 1: Designing the Isolated Network Switch

Before installing an operating system, we must architect our virtual topology. In cybersecurity home labs, proper network isolation is critical to your OPSEC. Later on, you will fire live exploits and execute aggressive network discovery scans; you must guarantee that no malicious payloads or loud scanning traffic escape into your actual home router or corporate network.

Understanding VMware Network Types

VMware offers three primary network styles, each serving a distinct architectural purpose:

Bridged: The VM connects directly to your physical host network. It requests its own IP address from your local router, appearing as an independent physical device on your local subnet. This mode is particularly useful when you need to run multiple concurrent VPN connections — for example, keeping your corporate VPN active on the host machine while running a completely different client VPN inside the virtual machine.
NAT (Network Address Translation): The VM shares the host system’s IP address through an internal private virtual router. While the VM can freely access the public internet, external devices on your physical network cannot initiate direct incoming connections to it. From the outside world’s perspective, all network traffic from your VM looks as though it originates directly from your host PC, mimicking a standard local process.
Host-Only: The VM is connected to a completely enclosed virtual switch that is entirely air-gapped from your physical network adapter. The virtual machines can communicate with each other and the host machine, but they have zero public internet access. For maximum security, you can even disable the virtual adapter on your host, making the lab environment entirely invisible and isolated from your host operating system. This makes it the perfect sandbox for secure malware analysis and offensive testing.

[ Your Physical Home Network ]
             │
     (Host OS Firewall)
             │
[ VMware Host-Only Switch: 10.10.10.0/24 ]
     ├── DC-01 (10.10.10.10)
     ├── SRV-01 (10.10.10.11)
     └── Kali_Attacker (10.10.10.50)

The Custom Lab Setup

Open VMware Workstation and navigate to Edit > Virtual Network Editor.
Select the VMnet1 (Host-Only) network.
Uncheck “Use local DHCP service to distribute IP addresses to VMs.”
Change the Subnet IP to 10.10.10.0.
Click Apply and save the changes.

Disabling the automated DHCP service within your hypervisor is highly recommended when architecting an Active Directory infrastructure. Active Directory relies fundamentally on stable, unchanging network endpoints, as the Domain Controller (DC) handles critical identity, authentication, and DNS processing for the entire network. If automated DHCP is left enabled, the DC could dynamically receive a different IP address upon a system reboot or lease expiration. This sudden shift would immediately break network routing, prevent member servers from locating the directory schema, and cause authentication services like Kerberos to fail entirely. Managing your IP mapping manually ensures absolute structural stability across the domain.

Technical Note on Default Gateways

In a Host-Only virtual network, your machines reside on an isolated “wire” with no physical router, meaning they communicate directly via Layer 2 protocols without the need for routing. Consequently, you do not need to configure a Default Gateway on your Domain Controller or member servers; in fact, leaving this field blank is a security best practice that further ensures your lab remains air-gapped from the internet. However, it is vital to understand the addressing scheme managed by VMware beneath the surface.

VMware automatically assigns an internal virtual gateway address to facilitate traffic between your host operating system and the guest virtual machines. Depending on your Host OS (Windows, Linux, or macOS), the hypervisor typically reserves the .1 or .2 addresses within your subnet. These specific addresses are not just arbitrary—they are structurally reserved: one is dedicated to the host machine’s virtual network interface, while the other serves as the gateway for VMware’s internal virtual router. Knowing this helps you troubleshoot connectivity issues between your host and your lab, even when you aren’t using the gateway for outbound routing.

While your primary lab environment remains strictly isolated on the Host-Only network, you may eventually need to bridge a specific virtual machine to the internet to download security patches, additional software, or language packs. Rather than altering your stable, static internal network configuration, the best approach is to implement multi-homing. By simply adding a second network adapter to your virtual machine and setting it to NAT mode, you provide that guest with a secondary path to the internet. Windows will treat this as a separate network interface, allowing your lab machines to maintain their permanent, static IP addresses on the internal Host-Only segment while simultaneously using the NAT adapter for external connectivity. This method ensures your environment remains organized and functional without disrupting your carefully established domain trust or static IP topology.

Step 2: Creating the Master Server Blueprint

We will create a single, pristine virtual machine called WinServer_Base that will act as the master read-only engine for our environment.

Right click on the Library and select, “New virtual machine”.
Select Typical installation
Choose iso image of Windows Server 2022
Write the name of machine: BaseWin_Srv
Leave the disk space to be 60GB adn select virtual disk as a single file
Uncheck to automatically power on
Open machine settings. Delete the Floppy Disk drive from the virtual hardware configuration list. Leaving legacy floppy controllers active within modern hypervisors frequently induces licensing errors and setup stalls during Windows Server deployment loops.
Select Host-only network for network adapter
Change memory to 4 GB
During installation, select Windows Server 2022 Standard Evaluation (Desktop Experience). Choosing the Desktop Experience version ensures you get the full graphical user interface (GUI) instead of a minimal command-line Core instance.
Complete the setup loop until you reach the clean desktop interface.

The Purpose of VMware Tools

The moment you log into your new desktop (use VM > Send Key > Ctrl+Alt+Del), go to the top VMware ribbon menu and select VM > Install VMware Tools.

VMware Tools injects paravirtualized guest drivers directly into the operating system kernel. It serves four crucial lab purposes:

Graphics Acceleration & Scaling: Dynamically resizes the Windows display resolution to match your hypervisor window.
Shared Clipboard: Allows smooth copy-paste operations for text, commands, and code files between your Host machine and the VM.
Time Synchronization: Keeps the VM clock perfectly synchronized with the host computer, which is a hard prerequisite for Kerberos authentication inside an Active Directory domain.
Driver Optimization: Improves memory handling and network interface card (NIC) performance.

Once the VMware Tools installation completes, do not make any changes to the network or configurations yet. Reboot the machine.

Step 3: Mastering Snapshots, Sysprep, and Unique SIDs

This is where we execute our disk space optimization hack. To understand why we handle this next step so delicately, we must understand how snapshots and cloning work beneath the hood.

How Snapshots and Linked Clones Work

When you take a virtual machine snapshot, the hypervisor freezes the original virtual disk file (.vmdk) and locks it into a read-only state. All subsequent write operations (new files, registry edits) are diverted into a tiny, newly spawned file called a delta or differential disk.

A Linked Clone takes this concept a step further. Instead of duplicating a massive 20 GB operating system installation to create a second server, a Linked Clone spawns a brand-new virtual machine whose hardware profile points right back to that frozen, read-only snapshot on the master machine.

[ Frozen Base VM Snapshot (Read-Only .vmdk) ]
         ├──> Delta Disk 1 ──> DC-01 VM (Only writes its distinct domain data)
         └──> Delta Disk 2 ──> SRV-01 VM (Only writes its distinct server data)

Because both clones share the exact same underlying base OS files, they only consume a few megabytes out of the gate! However, this architecture creates a vital dependency: you can never delete or alter the base VM template machine. If you destroy the root files, the linked clones lose their baseline data anchors and immediately experience fatal corruption.

The Sysprep Requirement

Before freezing our template snapshot, we must execute a critical Windows administrative process. Every Windows installation generates a unique Machine SID (Security Identifier) to identify itself within a network. If you clone a Windows machine using standard hypervisor tools, the clones retain matching, duplicate SIDs.

If you attempt to join multiple machines with matching SIDs to the same Active Directory infrastructure, the Domain Controller will drop the trust relationship or fail to handle secure authentication requests correctly.

To wipe this footprint:

Inside the WinServer_Base machine, open the Run window (Win + R), type sysprep, and hit Enter.
Launch sysprep.exe.
Set System Cleanup Action to Enter System Out-of-Box Experience (OOBE).
Check the Generalize box. Checking this box is the precise step that instructs Windows to strip its computer name, internal hardware profile, and unique Machine SIDs.
Set Shutdown Options to Shutdown and click OK.

Windows will generalize the image and power down. Once completely off, enter the machine’s hardware settings and delete the CD/DVD drive to leave the blueprint clean.

Finally, right-click the VM in your sidebar, go to Snapshot > Take Snapshot, and label it BaseOS_Sysprep. Your master anchor is now safely locked down.

Step 4: Provisioning Your Active Directory Infrastructure

Now we can deploy our enterprise network infrastructure instantly.

Deploying and Configuring the Domain Controller (DC-01)

Right-click your WinServer_Base machine, select Manage > Clone.
Select the BaseOS_Sysprep snapshot as your baseline, and check Create a Linked Clone. Name it DC-01.
Power the machine on. Because it was generalized by Sysprep, it will boot up believing it is running for the first time, automatically generating a brand-new, unique SID. Set a secure administrator password when prompted.
Once logged in, open your Network Connections. Assign a static IP configuration explicitly:
```
 IP Address: 10.10.10.10
 Subnet Mask: 255.255.255.0
```
Crucial Architectural Rule: Search for About in Settings, click Rename, and rename the computer to DC-01 first, then restart. Why you must change the hostname before domain promotion: If you promote a machine to a Domain Controller before renaming it, changing the hostname afterward becomes a complex administrative operation. The hostname is tied directly to Active Directory Service Principal Names (SPNs), global replication paths, and internal database records. Renaming it post-promotion breaks these bindings and can crash domain replication loops.
After restarting, open Server Manager, select Add Roles and Features, and install Active Directory Domain Services.
Once finished, click the yellow notification flag at the top of Server Manager and select Promote this server to a domain controller.
In the promotion wizard, choose Add a new forest, define your root domain name as cyberlab.local, establish your secure Directory Services Restore Mode (DSRM) recovery password, and select Install. The machine will automatically compile the schema and reboot into a fully active Domain Controller.

Deploying the Member Server (SRV-01)

Go back to WinServer_Base, select Manage > Clone, follow the Linked Clone sequence once more, and name this instance SRV-01.
Boot the machine and adjust its static network properties:

IP Address: 10.10.10.11
Subnet Mask: 255.255.255.0
Preferred DNS Server: 10.10.10.10 👈 This must point directly to the IP of your Domain Controller, or the server will scream into the network void and fail to resolve the directory lookup.

Just like before, open System Properties, change the hostname to SRV-01 and restart the machine.
Once back on the desktop, open System Properties again, click Change, choose Domain, type in cyberlab.local, and authenticate using your Domain Controller’s domain administrator credentials.

Upon seeing the “Welcome to the cyberlab.local domain” confirmation box, your corporate endpoint architecture is synced.

Step 5: Introducing the Offensive Box (Kali Linux)

With our corporate core targets fully deployed, it is time to deploy our penetration testing asset.

Why Pre-baked Virtual Machine Files Over Raw ISOs?

In professional assessment pipelines, security operators prioritize lifecycle automation. Kali Linux is an ephemeral, operational toolbelt—it is the launching platform, not the target.

Installing Kali from a raw .iso image takes 20-30 minutes, requires walking through localization wizards, and forces you to manually compile kernel headers and install open-vm-tools to get hardware acceleration and clipboard syncing working correctly. Pre-baked .vmx virtual machine files are optimized right out of the box by the Offensive Security team. They include pre-compiled hypervisor drivers, custom kernels tuned for wireless injection/virtual networking, and instantaneous deployment.

Deploying Kali

Unzip your downloaded Kali Linux archive. Then move the directory where you other machines are placed.
Right click Library in VMware and “Scan for Virtual Machnies”, and confirm new machine.
If VMware prompts you to upgrade the hardware compatibility, accept the change to ensure your host kernel maps efficiently to the guest.
Rename the VM entry in your hypervisor sidebar to kali-ad.
Open its virtual hardware settings and switch the Network Adapter over to our isolated Host-Only switch. Kali is now sitting on the exact same corporate wire inside our secure virtual network.
Power on the machine, log in with the default credentials (kali/kali), and open network preferences. Set a static IP of 10.10.10.50 with a /24 subnet mask (255.255.255.0). Click save and toggle the network connection off and on to force the interface to bind.

Step 6: Lab Validation & The 36 GB Storage Proof

Let’s test our network routing path to ensure the attacker machine can fully interact with the directory system.

Open a terminal window inside your Kali machine and run a quick ICMP test to the Domain Controller:


ping 10.10.10.10

Once you verify that packets are returning successfully, execute an exploratory Nmap scan against the Domain Controller to confirm its corporate services footprint:


sudo nmap -F 10.10.10.10

Within a few seconds, Nmap will report back with open service sockets on the target interface:

Port 53 (DNS): Resolving domain names across the active tree.
Port 88 (Kerberos): Handling tickets and user authentication requests.
Port 389 (LDAP): Querying objects across the directory schema.
Port 445 (SMB): Facilitating network file sharing protocols.

This specific footprint tells us with absolute certainty that our target is an active, fully functional Windows Domain Controller.

Securing the Live State

Before you launch any tools or modify files, open the VMware menu for both DC-01 and SRV-01 while they are running, navigate to Snapshot > Take Snapshot, and label them DC_Live and SRV_Live.

Active Directory relies on complex, fragile database engines (ntds.dit). If you break the directory topology or trigger a blue-screen loop while conducting testing, you can click this live snapshot to instantly restore both machines back to this exact, working state in under three seconds.

The Ultimate Storage Payoff

If you minimize your virtual machines, open a terminal on your host machine , and check the actual physical size of the directories holding your virtual infrastructure, you will discover an incredible sight: All three running operating systems combined occupy roughly 36 Gigabytes of total space on your SSD.

By leveraging centralized snapshots and generalized Linked Clones instead of redundant independent storage profiles, you save tens of gigabytes of disk space without compromising enterprise fidelity. Your secure, highly optimized hacking lab is officially open.

What Comes Next?

Now that your core infrastructure is fully live, we can begin analyzing, auditing, and exploiting it. In the upcoming articles about Active Directory, we will cover how to use our Kali machine to execute foundational discovery actions, map domain objects, and leverage flaws inside Kerberos and SMB to compromise the entire active directory structure.