DEV Community

Cover image for Every Hacker Should Build This Active Directory Lab
Hafiz Shamnad
Hafiz Shamnad

Posted on

Every Hacker Should Build This Active Directory Lab

#linux #cybersecurity #beginners #showdev

Hey folks, if you're dipping your toes into cybersecurity—whether you're a red teamer plotting simulated breaches, a blue teamer hardening defenses, or just a curious sysadmin wannabe—you've probably heard the hype around Active Directory (AD). It's the beating heart of most enterprise networks, handling authentication, authorization, and a whole lot of "oops, why did that user just get god-mode access?" moments.

But here's the kicker: reading about AD in a book or watching a YouTube tutorial is like learning to swim by watching Olympic highlights. It's dry, it's theoretical, and it doesn't stick. That's why, a few months back, I rolled up my sleeves and built my own AD lab right on my beat-up laptop using nothing but VirtualBox. No fancy cloud credits, no corporate budget—just me, some free ISOs, and a caffeine-fueled weekend.

The payoff? I finally got it. I saw a Windows client pinging the domain controller, slurping up an IP via DHCP, and joining the domain like it was the easiest thing in the world. It felt like casting a spell that actually worked. And when I "accidentally" locked out a test user? Fixing it taught me more about Kerberos tickets than any certification exam ever could.

If you're serious about hacking (ethically, of course), this lab is non-negotiable. It's your sandbox for everything from lateral movement exploits to GPO misconfigurations. In this guide, I'll walk you through every gritty detail—step by step—so you can replicate it without pulling your hair out. Let's turn your laptop into a mini-enterprise and break some (virtual) stuff.

Why Bother with a Home AD Lab?

Before we dive in, quick reality check: AD powers 95% of Fortune 500 companies. If you're aiming for pentesting certs like OSCP or eJPT, or just want to level up your SOC skills, hands-on AD experience is gold. In my lab, I tinkered with domain controllers, user enumeration, and even simulated a Pass-the-Hash attack (spoiler: it worked terrifyingly well).

This setup is lightweight—runs on a mid-range laptop with 8GB RAM—and costs zilch if you snag eval versions. Pro tip: Treat it like a hacker's playground. Break it, rebuild it, repeat.

Lab Blueprint: What We're Building

Two VMs, one internal network, endless chaos potential:

1. Domain Controller (DC) – The Boss Machine

  • OS: Windows Server 2019 (Desktop Experience for that GUI goodness)
  • Roles: AD DS (Domain Services), DNS, DHCP, Routing & Remote Access (RRAS) for NAT
  • Specs: 2 vCPUs, 2GB RAM, 60GB disk
  • IP Setup: Internal: 172.16.0.1/24 (static), NAT for outbound internet

2. Client Workstation – The Gullible Minion

  • OS: Windows 10 Pro
  • Role: Joins the domain, tests auth flows
  • Specs: 2 vCPUs, 2GB RAM, 40GB disk
  • IP Setup: Dynamic via DHCP (172.16.0.x range)

Networking twist: Internal network for VM-to-VM chatter, NAT for the DC to phone home for updates. No host involvement—keeps it isolated and hack-proof.

Tools you'll need:

  • VirtualBox 7.x (free from oracle.com/virtualbox)
  • PowerShell (built into Windows, but we'll script like pros)
  • ISOs: Windows Server 2019 and Win10 eval from Microsoft's site (search "evaluation center")

Step 1: Gear Up VirtualBox

Fire up your browser and grab VirtualBox + the Extension Pack. The pack unlocks USB passthrough and better USB2/3 support—handy if you ever want to "plug in" a virtual thumb drive for some USB-based fun.

Install like any app: Run the EXE, accept defaults, reboot if it nags. Launch it, and boom—you're in the Oracle VM VirtualBox Manager. If you're on a Mac or Linux host, same drill; it plays nice cross-platform.

Pitfall alert: If your antivirus freaks out (looking at you, Windows Defender), add VirtualBox to exclusions. False positives are the worst buzzkill.

Step 2: Snag Those Sweet ISOs

Head to Microsoft's Evaluation Center:

Save 'em to a folder like C:\ISOs. These evals last 180 days—plenty of time to wreak havoc. (Ethical note: Don't deploy in prod; that's a lawsuit waiting to happen.)

Step 3: Spin Up the DC VM

In VirtualBox:

  • New > Name it "DC01", Type: Microsoft Windows, Version: Windows 2019 (64-bit).
  • Memory: 2048MB (slider it up if you've got 16GB+ host RAM).
  • Hard Disk: Create a virtual hard disk now, VDI format, dynamically allocated, 60GB.
  • Processors: 2 CPUs under System tab.

Hit Start later; we'll tweak networking first. This config mimics a beefy server without hogging your laptop's guts.

Step 4: Wire the Network Like a Pro

VM Settings > Network:

  • Adapter 1: Enable, Attached to: NAT (for internet yumminess—updates, pings to google.com).
  • Adapter 2: Enable, Attached to: Internal Network. Name it "LABNET" (customize this; it'll be your isolated bubble).

Under General > Advanced:

  • Shared Clipboard: Bidirectional
  • Drag'n'Drop: Bidirectional

Why two adapters? NAT keeps the DC worldly, Internal keeps lab traffic private. Test it post-install: From the DC, ping 8.8.8.8 should work; client-to-DC pings will too once joined.

Common gotcha: If VMs can't see each other, double-check the Internal Network name matches on both.

Step 5: Breathe Life into the Server

Settings > Storage > Controller: IDE > Empty > Optical Drive icon > Choose the Server 2019 ISO.

Start the VM. Boot menu: Hit Enter on the ISO. Install Windows Server 2019 Standard (Desktop Experience)—the GUI makes life easier for noobs.

Partition: Custom, use the full 60GB. Setup wizard: Local admin password something memorable like P@ssw0rd123!. It'll chug for 10-15 mins. Grab a coffee.

Step 6: First Login Tango

VM boots to login screen? No shortcuts here—VirtualBox doesn't auto-map Ctrl+Alt+Del. Go Input > Keyboard > Insert Ctrl+Alt+Del.

Username: Administrator, password from setup. Desktop loads—welcome to server land. Quick win: Right-click Start > Windows PowerShell (Admin) to feel powerful.

Step 7: Tame the Network Adapters

Search "View Network Connections". You'll see "Ethernet" x2—one with a 169.254.x.x APIPA (no DHCP yet), the other maybe similar.

Right-click each > Status > Details. The NAT one might have a 10.x.x.x from VirtualBox's router.

Rename 'em: Alt+Enter on each > Properties > Alt+Enter on "Local Area Connection" > Description field: "Internet Adapter" and "Internal Adapter".

Why bother? Scripts and docs get confusing with generic names. Trust me, future-you thanks present-you.

Step 8: Lock Down That Static IP

Right-click Internal Adapter > Properties > Internet Protocol Version 4 (TCP/IPv4) > Properties.

  • IP: 172.16.0.1
  • Subnet: 255.255.255.0
  • Default Gateway: Leave blank (no upstream router yet)
  • DNS: 127.0.0.1 (self-hosted, baby!)

Apply. ipconfig in CMD should show it. Ping yourself: ping 172.16.0.1—loopback magic.

Pro tip: 172.16.0.0/24 is RFC 1918 private—safe for labs, won't clash with your home WiFi.

Step 9: Summon Active Directory

Server Manager (pops on login) > Dashboard > Quick Start > Add roles and features.

Wizard: Role-based > This server > Next > Check Active Directory Domain Services > Add features when prompted (includes management tools—yay GPOs!).

Install. It'll download bits if NAT's working. ~5 mins.

Step 10: Crown the King—Promote to DC

Post-install, yellow flag in Server Manager > Click > Promote this server to a domain controller.

  • Deployment: Add a new forest
  • Root domain: myfirstdomain.com (keep it simple; .local works too, but .com feels enterprise-y)
  • DSRM password: Something strong like R3c0v3ryP@ss!
  • DNS: Let it install
  • NetBIOS: MYFIRSTDOMAIN (auto-fills)

Paths: Default. Review, install. Reboot incoming—save your work!

Post-reboot: Login as MYFIRSTDOMAIN\Administrator. DNS is now AD-integrated—test nslookup myfirstdomain.com (should resolve to 172.16.0.1).

Step 11: Populate the Kingdom—Users & OUs

Server Manager > Tools > Active Directory Users and Computers (dsa.msc).

Right-click domain > New > Organizational Unit: "Users", "IT Dept", "Sales" (OUs group users for GPOs later).

New > User: jdoe, full name John Doe, password P@ssw0rd123, uncheck "User must change". Boom—domain citizen.

Scale it: Right-click OU > New > User, rinse. Or... PowerShell time (next step).

Step 12: Bridge to the Outside World—RRAS

Server Manager > Add roles > Remote Access > DirectAccess and VPN (RAS), Routing.

Install. Post-reboot: Server Manager > Tools > Routing and Remote Access.

Right-click server name > Configure > Custom > LAN routing only > IPv4 > NAT.

Right-click NAT > New Interface > Internal Adapter > Public (outbound) > Private (inbound from clients).

Now clients can surf via DC proxy. Test later from client: ping google.com.

Pitfall: If NAT fails, ensure Adapter 1 (NAT) is up and RRAS service running (services.msc).

Step 13: Hand Out IPs Like Candy—DHCP

Server Manager > Add roles > DHCP Server.

Post-install: Authorize (notification flag > Complete DHCP config > domain admin creds).

Tools > DHCP > Right-click IPv4 > New Scope:

  • Name: "Lab Scope"
  • IP: 172.16.0.100 - 172.16.0.200
  • Subnet: 255.255.255.0
  • Exclude: None yet
  • Lease: Default 8 days
  • Router: 172.16.0.1
  • DNS: 172.16.0.1
  • WINS: Skip
  • Activate: Yes

Right-click scope > Scope Options > 006 DNS Servers: 172.16.0.1. Done. Clients will auto-grab.

Step 14: PowerShell Wizardry—Bulk User Creation

Labs need fodder. Open PowerShell as admin on DC:

Set-ExecutionPolicy Unrestricted -Scope CurrentUser
Enter fullscreen mode Exit fullscreen mode

Create users.txt via Notepad:

jdoe,John Doe,IT
asmith,Alice Smith,Sales
bwilson,Bob Wilson,HR
Enter fullscreen mode Exit fullscreen mode

Script it:

$users = Get-Content C:\users.txt
foreach ($u in $users) {
    $parts = $u.Split(',')
    $sam = $parts[0]
    $name = $parts[1]
    $ou = $parts[2]
    New-ADUser -SamAccountName $sam -UserPrincipalName "$sam@myfirstdomain.com" -Name $name -GivenName ($name.Split(' ')[0]) -Surname ($name.Split(' ')[1]) -Path "OU=$ou,DC=myfirstdomain,DC=com" -AccountPassword (ConvertTo-SecureString "P@ssw0rd123" -AsPlainText -Force) -Enabled $true -PasswordNeverExpires $true
}
Enter fullscreen mode Exit fullscreen mode

Run: ./bulkusers.ps1. Instant org chart. Tweak for passwords, emails—go wild.

Step 15: Craft the Client Minion

New VM: "CLIENT01", Windows 10 (64-bit), 2048MB RAM, 40GB disk.

Attach Win10 ISO, install Pro edition. During OOBE: "I don't have internet" > Local account: localuser / LocalP@ss!.

Post-install: Update via NAT if you want, but skip for speed.

Step 16: Ping Pong—Test the Pipes

On client: CMD > ipconfig /release then /renew. Should snag 172.16.0.x from DHCP.

ping 172.16.0.1 (DC)—success? ping 8.8.8.8 (internet via NAT)—double win! nslookup myfirstdomain.com resolves?

If DHCP ghosts you: Ensure scope activated, client on Internal Network "LABNET". Firewall? netsh advfirewall set allprofiles state off temporarily.

Step 17: The Sacred Join Ritual

Client: Settings > System > About > Rename this PC > Change > Domain: myfirstdomain.com.

Reboot prompt? Creds: MYFIRSTDOMAIN\Administrator / password. Welcome screen: "Welcome to myfirstdomain.com".

Pitfall: If it gripes "network path not found", DNS issue—ensure client DNS points to 172.16.0.1 (ipconfig /all).

Step 18: Domain Life—Login & Play

Reboot, login: Other user > MYFIRSTDOMAIN\jdoe / P@ssw0rd123.

CMD: whoami shows domain\user. nltest /dsgetdc:myfirstdomain.com confirms DC contact.

Now explore: From client, access \DC01\C$ (admin share)—file sharing unlocked.


The Aha Moments That Hooked Me

This lab demystified AD's guts: LDAP queries, NTLM vs. Kerberos, the glory of delegated permissions. I learned DHCP reservations for static-ish clients, DNS scavenging to avoid stale records, and why OUs are GPO gateways.

Best lesson? Failure is feature. Misconfigure DHCP? Clients go dark—trace it with Wireshark (install on host, capture on Internal). Locked out? Boot to DSRM, reset via net user.

Top comments (0)