When I first started in cybersecurity, I could run Nmap scans and play with Metasploit, but real enterprise environments were a different beast. I quickly learned that understanding Windows domains is crucial.
After months of building this cybersecurity lab—this is episode five of my series—I can tell you that a proper Windows domain changes everything. Instead of just running tools against random VMs, you’re testing against an environment that mirrors what you’d find in a real company.
Once this lab is set up, you can safely test everything from basic privilege escalation to advanced persistent threats without the risk of getting fired or arrested.
Why a Windows Domain Matters
Understanding Windows domains is crucial for anyone serious about cybersecurity. Most enterprise environments run on Active Directory, and if you don’t understand how these systems work, you’re missing a huge piece of the puzzle.
A proper Windows domain gives you:
- Realistic Attack Surface: Test real-world attacks like Kerberoasting and Golden Ticket attacks
- Integration with Security Tools: Works seamlessly with Wazuh, Nessus, and Metasploit
- Learning Laboratory: Perfect for Windows administration and incident response practice
What We’re Actually Building
Before we dive into the technical details, let’s visualize our setup:
-
The Star of the Show: Windows Server 2022 Domain Controller - This server is the brain of our network. It handles user authentication, manages network resources, and enforces security policies across the entire domain. Think of it as the bouncer, librarian, and traffic cop of your network all rolled into one.
-
The Supporting Cast: Windows 10 Workstation - This is a standard Windows 10 machine joined to our domain, meaning it follows the domain controller’s rules. Users log in with domain accounts, get their mapped drives automatically, and adhere to the security policies you’ve set up.
-
The Network That Ties It All Together - We’ll run everything on a clean 10.10.20.0/24 network (VLAN 20 for networking pros). Our domain controller will have a static IP at 10.10.20.10, and it will handle DHCP for clients in the 100-120 range—clean, organized, and professional.
Prerequisites and Downloads
First, you’ll need a few downloads from the Windows Evaluation Center:
- Windows Server 2022 ISO (180-day trial)
- Windows 10 ISO (180-day trial)
- VirtIO drivers for Proxmox (to ensure your VMs work properly)
I’m running this on Proxmox, which has been rock solid for this lab. If you’ve been following my previous episodes, your network infrastructure should already be in place.
The Journey Begins: Building Our Domain Controller
Creating the Virtual Machine
I’m setting this up as VM ID 209 with the name “prod-DC” (because naming conventions matter!). The specs are generous enough for a lab environment:
- 2 CPU cores
- 4GB RAM
- 64GB storage
- Connected to our lab network (vmbr2 with VLAN tag 20)
Pro Tip: Don’t skip TPM and EFI storage. Modern Windows expects these, so enable them to avoid headaches later.
The Installation Process
Windows Server installation is much faster than it used to be, but there are still a few key points to remember:
Driver Drama: Windows won’t see your virtual disk initially. During installation, click “Load driver” and point to the VirtIO drivers. Navigate to the viostor → w2k22 → amd64 folder, and your disk will appear.
Version Selection: Select “Windows Server 2022 Standard (Desktop Experience)”. Trust me, you don’t want to manage Active Directory from the command line if you don’t have to.
Server Configuration
Once Windows is installed, it’s time to turn this generic server into a proper domain controller:
-
Network Configuration: Set a static IP (10.10.20.10). Domain controllers must be reliable and predictable.
- Role Installation: Use Server Manager to add three key roles:
- Active Directory Domain Services
- DNS Server (AD needs DNS to function)
- DHCP Server (we’re taking over IP assignment)
- Promoting to Domain Controller: This is the big moment. We’re creating a new forest since this is our first domain controller. I’m using the domain name “jaro.local” to avoid conflicts with real internet domains. The server will reboot, and you’ll have a fully functional Active Directory domain.
Building Our User Environment
Creating Users and Groups
This is where the environment starts to feel real. Create a few key accounts:
- jobrien: A regular domain user
- jaroadmin: A domain administrator account (you should never use the built-in Administrator for daily tasks)
- Shared Folder Access: A security group for managing file access
Using the security group is crucial. Instead of assigning permissions to individual users, you add them to a group. It’s simple, scalable, and secure.
DHCP Configuration
In real enterprise environments, you want your domain controllers handling DHCP because they can integrate DHCP with DNS and Active Directory. Disable DHCP on your firewall and configure a scope on your domain controller:
- Range: 10.10.20.100 to 10.10.20.120
- Gateway: 10.10.20.254 (your pfSense firewall)
- DNS: Points to your domain controller
Group Policy Implementation
Group Policy lets you configure settings once and have them apply automatically to users or computers. We’ll set up a simple but effective policy to automatically map a network drive for users in the “Shared Folder Access” group. When they log in, a G: drive will appear—no manual mapping required.
The Windows 10 Client: Bringing It All Together
Building the Workstation
The Windows 10 VM setup is almost identical to the server setup: same VirtIO driver dance, same network configuration, but it will get a DHCP address from our new domain controller.
Domain Join Process
This is the moment of truth. Will it work?
- Open System Properties
- Click “Change” next to the computer name
- Select “Domain” and enter “jaro.local”
- Enter our domain admin credentials
- Cross your fingers…
And it works! “Welcome to the jaro.local domain”—some of the most satisfying words in IT.
Testing the Setup
After the reboot, log in with your domain user account (jaro\jobrien). Everything should work:
- The user authenticates against the domain controller
- The G: drive appears automatically, thanks to Group Policy
- Network connectivity and DNS resolution work perfectly
This is the moment when all the pieces come together and you realize you’ve built something genuinely useful.
What This Gets You
- Realistic Attack Surface: A proper Windows domain lets you test real-world attacks, such as Kerberoasting, Golden Ticket attacks, and lateral movement.
- Integration with Security Tools: This domain works seamlessly with tools like Wazuh (for monitoring security events), Nessus (for credentialed scans), and Metasploit (for Windows-specific modules).
- Learning Laboratory: Beyond just testing attacks, this is a perfect environment for learning Windows administration, Group Policy management, and incident response.
What’s Next?
This setup is just the beginning. You can:
- Add more workstations to the domain
- Implement more complex Group Policies
- Set up additional servers with different roles
- Practice attack and defense scenarios
Final Thoughts
Building this Windows domain has been one of the most rewarding parts of creating this lab. It transforms what was a collection of individual tools into a cohesive, realistic environment. The beauty of having your own lab is that you can break things, fix them, and learn from every mistake without real-world consequences.
This Windows domain will serve you well, whether you’re studying for certifications, preparing for penetration tests, or just satisfying your curiosity. Now, go forth and break things responsibly!