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 me 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 as of this stage in the project. (Insert your Draw.io diagram here.)
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.
Process Overview (Optional)
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
Make sure to attach the VirtIO driver ISO, because Windows will need these drivers to detect storage and network devices during installation.
I also needed to create a LabConfig directory with some Booleans in order 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:
Set IP: 10.0.0.25
Subnet: 255.255.255.0
Gateway: 10.0.0.1 (pfSense)
DNS: 10.0.0.25 (itself)
This is mandatory because AD DNS integrates tightly with the domain.
Section 2 – Promoting the Server to a Domain Controller
Install AD DS
In Server Manager:
Manage → Add Roles and Features
Select Active Directory Domain Services
Install
Click Promote this server to a domain controller
Create Your Domain
Choose Add a new forest
Root domain: lab.local
Set DSRM password
Accept defaults
Install → reboot
After reboot, AD DS and DNS automatically come online.
Verify AD is Working
In PowerShell:
If both return information about lab.local, AD is healthy.
Section 3 – Configuring DNS for Internal and External Name Resolution
AD DNS handles internal queries (lab.local), but you also need a path for external queries (google.com).
Why DNS Forwarding Matters
AD DNS will attempt to resolve everything—even external domains—which will fail unless forwarders are configured. This is expected behavior.
Testing the DNS with a Ping to 8.8.8.8 fails until I configured DNS Forwarding in the pfSense Web GUI
Fixing DNS Forwarding in pfSense
Under Services → DNS Resolver:
Enable Forwarding Mode
Set upstream DNS servers (ex: 8.8.8.8)
Save & apply
This allows pfSense to resolve all external domains.
Fixing DNS Forwarding in Windows Server
Open DNS Manager:
Right-click the server → Properties → Forwarders
Add: 10.0.0.1 (pfSense LAN IP)
This forwards unknown queries to pfSense → which forwards them to upstream DNS → out through NAT.
Testing
nslookup lab.local
nslookup google.com
lab.local resolves internally
google.com resolves externally through pfSense
lab.local → resolves internally (AD DNS) ✅
google.com → resolves externally via pfSense forwarder ✅
Section 4 – Joining Clients to the Domain
A. Joining Windows 11 to the Domain
Requirements:
DNS pointing to 10.0.0.25 (the hard coded IP of the AD server)
confirm Network connectivity to AD server (ping 10.0.0.25)
System clock synchronized (Kerberos relies on accurate time)
Join the domain:
Settings → Accounts → Access work or school → Connect
Choose: Join this device to a local Active Directory domain
Enter: lab.local
Reboot
Verify:
whoami
nltest /dsgetdc:lab.local
ipconfig /all
B. Joining Ubuntu Desktop to the Domain
Ubuntu requires packages for Kerberos + SSSD:
sudo apt update
sudo apt install realmd sssd sssd-tools adcli samba-common-bin oddjob oddjob-mkhomedir packagekit
Discover domain:
realm discover lab.local
Join:
sudo realm join --user=administrator lab.local
Verify:
realm list
Allow domain logins:
sudo realm permit --all
Auto-create home directories:
Enable automatic /home creation for domain users:
sudo pam-auth-update --enable mkhomedir
Both Windows 11 and Ubuntu are now fully domain-joined.
Key Takeaways / Lessons Learned
Building out Active Directory as the identity backbone of the lab revealed just how interconnected authentication, DNS, and domain services really are. This stage of the project required careful configuration, validation, and troubleshooting—especially around DNS and domain join workflows. Completing this step gave me a much clearer understanding of how enterprise identity environments operate and why identity services are such a critical point of failure or strength.
- Active Directory and DNS are inseparable—if DNS is not functioning properly, AD will fail in unpredictable ways.
- Static IPs are mandatory for domain controllers and servers to ensure consistent authentication and name resolution.
- DNS forwarding is normal and expected in enterprise environments; AD handles internal zones while forwarding external queries.
- Accurate time synchronization is critical, since Kerberos authentication will break if clocks drift too far.
- Joining Linux systems to AD highlights how identity must work across multiple OS ecosystems.
- Tools like nltest, whoami, realm, and sssd provide invaluable diagnostics for verifying identity behavior.
- This phase showed that identity becomes the central dependency for every layer that follows—logging, access control, monitoring, and detection.
Next Steps / Learning Opportunities
With the identity layer fully established and all clients joined to the domain, the next phase of the project shifts toward visibility and event analysis. Now that authentication and DNS are stable, I can begin focusing on the logs, behaviors, and telemetry that will move this lab from a simple AD deployment to a functional security operations environment.
In the next stage of the homelab build, I’ll begin implementing a full monitoring and detection pipeline. This will include:
- Creating Organizational Units (OUs) and applying Group Policies (GPOs)
- Installing and configuring Sysmon for advanced process and network telemetry
- Setting up Windows Event Forwarding (WEF) to centralize Windows logs
- Deploying Splunk Universal Forwarders across server and endpoint systems
- Aggregating and parsing logs inside the Splunk SIEM
- Running simulated attacks from my Kali machine to test identity and authentication monitoring
- Beginning SOC-style analysis, including search queries, baselining, and detection logic development
With networking, segmentation, and identity now in place, the environment is ready to evolve into a true security engineering and blue-team practice lab. The next blog post will document the start of this visibility phase as I install Splunk and configure log forwarding across the environment.