Building a Virtualized Cybersecurity Lab: Active Directory and DNS Integration

Source: Dev.to

Why Identity Services Matter

After establishing the core networking and firewall layer of my homelab, the next major step was to build the identity foundation that real‑world organizations rely on: Active Directory. Windows Server 2022 provides a fully functional domain environment with integrated DNS, centralized authentication, and the ability to manage devices across the network.

This stage was especially important for me because, although I’m comfortable in Linux and the CLI thanks to my development background, I’ve always wanted to deepen my Windows administration and PowerShell skills. Studying for CompTIA A+, Network+, and Security+ made me aware of how heavily enterprises depend on Active Directory, but building it myself inside a real network pushes that knowledge much further. Completing this part of the homelab means I now have the identity infrastructure needed for future projects in security monitoring, detection engineering, and attack simulation.

Lab Architecture Reminder

Before diving into configuration, here’s the high‑level lab design at this stage.

Current environment includes

• pfSense (router/firewall)
• lab‑LAN internal network
• Windows Server 2022 (Domain Controller + DNS)
• Windows 11 endpoint
• Ubuntu Desktop endpoint
• External Kali ThinkPad (via VPN into pfSense)

With networking complete, the identity layer sits on top of this controlled environment.

Section 1 – Installing Windows Server 2022

Windows Server 2022 required a bit more work due to Secure Boot and TPM expectations. I eventually switched from virt-install to Virt‑Manager for easier overrides, but here’s the CLI version I used first:

sudo virt-install \
  --name winserver2022 \
  --ram 8192 \
  --vcpus 4 \
  --disk path=/var/lib/libvirt/images/winserver2022.qcow2,format=qcow2,bus=virtio \
  --cdrom /var/lib/libvirt/boot/WindowsServer2022.iso \
  --network network=lab-lan,model=virtio \
  --os-variant win2k22 \
  --graphics spice \
  --boot uefi

Tip: Attach the VirtIO driver ISO; Windows needs these drivers to detect storage and network devices during installation.

I also created a LabConfig directory with a few booleans to override TPM and Secure Boot.

Assigning a Static IP (Required for AD)

Active Directory must run on a server with:

• A static IP
• DNS pointing to itself
• A consistent hostname

Inside Windows Server:

This is mandatory because AD DNS integrates tightly with the domain.

Section 2 – Promoting the Server to a Domain Controller

Install AD DS

1. Open Server Manager → Manage → Add Roles and Features.
2. Select Active Directory Domain Services and install.
3. After installation, click Promote this server to a domain controller.

Create Your Domain

1. Choose Add a new forest.
2. Root domain: lab.local.
3. Set the DSRM password.
4. Accept defaults, install, and reboot.

After the reboot, AD DS and DNS come online automatically.

Verify AD Is Working

Open PowerShell and run:

Get-ADDomain
Get-ADForest

If both commands return information about lab.local, AD is healthy.

Section 3 – Configuring DNS for Internal and External Name Resolution

Why DNS Forwarding Matters

AD DNS handles internal queries (e.g., lab.local) but will also receive external queries. Without forwarders, those external lookups fail.

Fixing DNS Forwarding in pfSense

1. Services → DNS Resolver.
2. Enable Forwarding Mode.
3. Set upstream DNS servers (e.g., 8.8.8.8).
4. Save & apply.

Fixing DNS Forwarding in Windows Server

1. Open DNS Manager.
2. Right‑click the server → Properties → Forwarders.
3. Add 10.0.0.1 (pfSense LAN IP).

This forwards unknown queries to pfSense, which then forwards them to the upstream DNS servers.

Testing

nslookup lab.local
nslookup google.com

• lab.local resolves internally via AD DNS.
• google.com resolves externally through the pfSense forwarder.

Both tests should succeed.

Section 4 – Joining Clients to the Domain

A. Joining Windows 11 to the Domain

Requirements

• DNS pointing to 10.0.0.25 (the AD server).
• Network connectivity to the AD server (ping 10.0.0.25).
• System clock synchronized (Kerberos relies on accurate time).

Join the domain

1. Settings → Accounts → Access work or school → Connect.
2. Choose Join this device to a local Active Directory domain.
3. Enter lab.local.
4. Reboot.

Verify

whoami
nltest /dsgetdc:lab.local
ipconfig /all

• whoami should show the domain‑qualified username.
• nltest should return the domain controller information.
• ipconfig /all should list the DNS server as 10.0.0.25.