JoeCorp - Initial Deployment
A self-guided exploration into on-premises Windows administration.
Overview
For as long as I've been interested in IT, Active Directory has fascinated me. I wanted to understand how a single login can manage an entire organization's worth of permissions, folders, and security policies. To do that, I built 'JoeCorp': a fully virtualized enterprise environment. I wanted to build a functional environment where I could break, fix, and learn on-prem Windows administration.
This is the foundation for many projects built upon this infrastructure. This post details deploying the initial infrastructure and Active Directory domain.
Architecture
- Networking: pfSense acts as a DHCP server and router for the environment. It's also functioning as a firewall to allow NTP traffic for time synchronization while maintaining an airgapped lab environment.
- Domain Controllers: Two Windows Server 2025 Core VMs (DC01 and DC02). Core reduces attack surface and resource usage while also mirroring production environment best practices.
- File Server: SRV01 acts as the heart of JoeCorp's data, handling mapped shared storage, roaming profiles, and home folder redirection for users.
- Admin Workstation: A Windows 11 VM with RSAT installed to keep management tools separate from standard client systems and servers.
- Domain Clients: Three Windows 11 VMs to explore user experience and group policies.
The Half-Promoted DC
One of the biggest learning experiences starting this project was a total failure during the promotion of DC02. A DNS misconfiguration on pfSense made DC02 hang during the promotion process. My initial troubleshooting attempts to fix the main DNS issue, manually setting the DNS server to DC01 in the pfSense console, and re-running the promotion command were fruitless. AD Users and Computers would see DC02 as a "computer", but not a domain controller, thus being unable to replicate the forest and finish promotion.
- The Fix: Instead of wiping the VM and starting from scratch, I performed a
metadata cleanup within Users and Computers, Sites and Services, DNS Manager, and
ntdsutil. I then joined DC02 as a member first before promotion. - The Lesson: This taught me that in AD, there will often be more than one entry for a single object in different locations. Joining a server as a member first to verify the plumbing (DNS and connectivity) before promotion is a good way to catch issues early.
Group Policy
The real fun started with Group Policy. I've always wanted to see how deep the rabbit hole goes with locking down systems and user accounts and what could be done with it. I used dedicated security groups for specific types of policies to ease management. Employees, Admins, and IT staff each have their own groups to enforce different policies, along with more specialized groups for specific permissions.
The GPOs I implemented include:
- Folder Redirection - Scoped to a 'HomeDrive' security group, this redirects member users' Documents, Desktop, Downloads folders to auto-created network shares on SRV01.
- Mapped Drive - Auto maps a 'Data' network share to all users on login.
- Wallpaper - Sets a special wallpaper for members of the 'Employee' group.
- Lockdown - Scoped to Employees, this disables administrative tools, access to the control panel, and even the C:\ drive to enforce usage of their shared network folders.
- PerfSettings - As my lab is hosted off-site and my dorm network speed isn't the best, I created this GPO to automatically disable UI features such as "View window contents while dragging" via the registry for every user to increase usability on every VM.
The full GPO report can be found here.
Future Roadmap
This is only the beginning for JoeCorp. Now that the foundation is poured, I'm planning to:
- Simulate disasters
- Introduce VLANs and segmentation
- Experiment with automation, like replacing manual user onboarding with PowerShell scripts and Excel
What I Learned
- DNS is king: If AD is acting up, it's almost always a DNS issue.
- Visibility vs. Permission: When creating my lockdown GPOs, I discovered there are two ways to disable access: hiding the tool and disabling the tool. Hiding the tool doesn't disable the tool, and vice-versa.
- Context Matters: Learning the difference between User configuration and Computer configuration and how they apply was a major learning experience.
- Necessary Compromise: I originally planned to keep
this lab completely airgapped. However, I discovered that without periodic synchronization with
a validated time server, the lab would fall apart if I needed to restore a VM from a snapshot
due to clock drift. By allowing outbound connections to only
time.windows.com, I was able to maintain the integrity of the lab while still having access to a reliable time source.