keith-portfolio/docs/windows-server-homelab.md

Windows Server / Active Directory Homelab

Objective

Build a self-contained Windows Server 2022 Active Directory environment to practice the day-to-day tasks a Help Desk / Junior SysAdmin role actually asks for: domain join, user and group management, OU design, SMB file services, NTFS permissions, DNS, time synchronization, and the troubleshooting loop when something breaks.

Everything on this page is from the real lab on my workstation. Nothing is fabricated.

Architecture

Three virtual machines on VMware Workstation Pro 17, plus an OPNsense firewall VM that sits between the server segment and a separate client segment. A Windows Server 2022 domain controller runs AD DS, DNS, and PDC Emulator duties for the forest; a member server runs SMB file services; a Windows 11 client is domain-joined.

Systems

System	OS	Role	Address	Purpose
DC01	Windows Server 2022 Standard	Domain controller	192.168.31.10	AD DS, DNS, PDC Emulator, Schema Master, Global Catalog
FILE01	Windows Server 2022 Standard	Member server	192.168.31.20	SMB file services
WIN11-01	Windows 11 Education	Domain client	192.168.31.x (DHCP, VMnet8)	Domain-joined workstation
OPNSENSE	FreeBSD / OPNsense	Firewall / router	VMnet8 ↔ VMnet2	Separates server and client segments

Active Directory

• Forest / Domain: ad.bytegeist.lab
• NetBIOS: BGLAB
• Forest and Domain functional level: Windows2016
• FSMO roles: all five held by DC01.ad.bytegeist.lab
• Global Catalog: DC01

Verified with Get-ADDomain, Get-ADForest, and Get-ADDomainController.

DNS

AD-integrated primary zones on DC01:

• ad.bytegeist.lab
• _msdcs.ad.bytegeist.lab
• Three default reverse-lookup zones

Clients resolve the domain through DC01. The PDC Emulator (DC01) now synchronizes time externally from time.windows.com, pool.ntp.org, and time.nist.gov — a fix I applied during this audit (see Problems and Fixes).

Organizational units

ad.bytegeist.lab/
├── ByteGeist/
│   ├── Groups
│   ├── Servers
│   ├── Workstations
│   └── Users/
│       ├── HR
│       ├── IT
│       └── Sales
└── Domain Controllers

Users and groups

Seven lab user accounts distributed across HR, IT, and Sales OUs. All are lab accounts — no production identities or real personal data.

OU	Users
HR	jwilson, ldavis
IT	bsmith, kcasko, sjohnson
Sales	mbrown, tmiller

Seven global security groups under OU=Groups,OU=ByteGeist:

Accounting · Help Desk · HR Employees · IT Employees · Management · Sales Employees · VPN Users

Groups are the access-control building block the lab uses — accounts never get rights directly on resources; groups do.

File services

FILE01 publishes one departmental share:

Share	Path	Share-level ACL	NTFS ACL
IT	C:\Shares\IT	Domain Admins = Full; IT Employees = Change	IT Employees = Modify (explicit); SYSTEM / Administrators = Full (inherited); Users = ReadAndExecute + CreateFiles + AppendData

Role-based access via group membership: only members of BGLAB\IT Employees get write access to the IT share, with a conservative share-level cap at Change (no share-level Full for regular users). HR and Sales shares aren't published yet; they're planned work.

Client domain join

WIN11-01 is a domain-joined Windows 11 Education client on the lab NAT network (VMnet8). After the NIC was moved off a bridged physical-LAN adapter and DNS was pointed at DC01, the machine-account secure channel was repaired and verified: Test-ComputerSecureChannel returns True, nltest /dsgetdc:ad.bytegeist.lab locates DC01 (PDC/GC/KDC/DNS flags), and domain authentication succeeds (bglab\administrator). Full before/after detail is in the audit log.

Networking

• VMnet8 (NAT, 192.168.31.0/24) — hosts DC01, FILE01, and OPNsense's WAN interface.
• VMnet2 (host-only, 192.168.254.0/24) — OPNsense LAN segment, intended home for domain clients.
• OPNsense is the lab's router/firewall between those segments. The current topology still has servers on VMnet8 rather than behind OPNsense's LAN — honest trade-off I kept so audit traffic stays uncomplicated during build-out.

Validation tests

Run from DC01 as BGLAB\Administrator, output captured to transcripts on the host:

• Get-ADDomain, Get-ADForest, Get-ADDomainController — forest/domain/role data.
• Get-ADOrganizationalUnit -Filter * — OU inventory.
• Get-ADUser -Filter * + Get-ADGroup -Filter * — identity inventory.
• Get-ADComputer -Filter * -Properties OperatingSystem, LastLogonDate — domain members and freshness.
• Get-DnsServerZone — zone list.
• dcdiag /q — DC health (silent = healthy after the SystemLog fix).
• repadmin /replsummary — replication (clean on a single-DC forest).
• w32tm /query /source and /status — time hierarchy, verified moving from Local CMOS Clock to time.windows.com (stratum 5).
• Invoke-Command FILE01 { Get-SmbShare | Get-SmbShareAccess ; Get-Acl } — share and NTFS evidence.
• Test-ComputerSecureChannel on FILE01 → True.

Problems found

1. PDC time source was Local CMOS Clock. On a Windows forest the PDC Emulator is the authoritative time source; every member chains off it. If it drifts, Kerberos tickets outside the 5-minute skew window fail — a classic Help Desk "I can't log in" root cause.
2. Stale dcdiag SystemLog failure from an unexpected shutdown on 2026-08-07.
3. My daily account (keith) was a standard Domain User and couldn't WinRM into FILE01 for remote auditing (correct behavior — only Domain Admins are in the server's local Administrators by default).
4. WIN11-01's NIC had drifted to bridged mode, severing its path to DC01.
5. Topology placement: DC01 and FILE01 sit on NAT (VMnet8) rather than behind OPNsense's LAN, so OPNsense doesn't see server-to-server east-west traffic. Honest reality, not a bug.

Fixes performed

• Set external NTP on the PDC: w32tm /config /manualpeerlist:"time.windows.com,0x9 pool.ntp.org,0x9 time.nist.gov,0x9" /syncfromflags:manual /reliable:yes /update, Restart-Service W32Time, w32tm /resync /rediscover. Verified: w32tm /query /source now returns time.windows.com,0x9, stratum 5.
• Cleared the stale System event log (wevtutil cl System); re-ran dcdiag /q — clean.
• Added keith to Domain Admins as a documented lab-maintenance action so future audits run as my daily account instead of needing an Administrator sign-in each time. Lab-only elevation; this account has no production use.

Client restoration (completed 2026-10-03, VMware GUI + guest PowerShell):

• Removed WIN11-01 snapshots, virtual TPM, and vmx encryption.
• Switched WIN11-01's network adapter from Bridged to NAT (VMnet8).
• Renewed DHCP, pointed DNS at 192.168.31.10, ran Test-ComputerSecureChannel -Repair — returns True; nltest locates DC01 with full PDC/GC/KDC/DNS flags.

Security considerations

• Lab is isolated behind VMware NAT. No inbound exposure to the host network or the internet.
• Audit transcripts live on the host under D:\Repos\ad-lab\transcripts\, not inside a VM.
• No passwords, DSRM, krbtgt, or SIDs are captured in any artifact linked from the portfolio.
• Lab AD is deliberately separate from any production or hybrid identity; nothing in ad.bytegeist.lab has internet-facing roles.

Skills demonstrated

Windows Server 2022 administration · Active Directory Domain Services · DNS · OU and group design · users and groups · SMB file services · NTFS and share permissions · PowerShell (Get-AD*, Invoke-Command, w32tm, Get-SmbShareAccess, Get-Acl) · VMware Workstation Pro 17 · network segmentation with OPNsense · WinRM remoting · structured troubleshooting · writing honest audit documentation.

Future improvements

• Move DC01 and FILE01 behind OPNsense (VMnet2) so firewall rules actually see server-side traffic — foundation for the Net+/Sec+ firewall drills in my opnsense-lab-networking skill.
• Publish HR and Sales shares with the same RBAC pattern already proven on the IT share.
• Add a first GPO (desktop wallpaper or password policy) linked to OU=Users,OU=ByteGeist.
• Enable the AD Recycle Bin and run user-delete / restore drills.
• Build out baseline / baseline-post-drills snapshots on all three VMs for repeatable break/fix practice.