# 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 ![ByteGeist AD homelab topology](../assets/images/homelab-topology.svg) 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 | (NIC change in progress) | 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 in AD as a domain-joined Windows 11 Education client, last successful domain logon 2026-08-05. Its NIC is temporarily bridged to the physical LAN, which currently prevents the client from reaching DC01 (fix is a VMware-side NIC change plus a secure-channel repair — documented 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 drifted to bridged mode**, which severed 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. Pending (user-side VMware GUI action, not scripted): - Decrypt WIN11-01's vmx (VM → Access Control → Remove Encryption). - Switch WIN11-01's network adapter from Bridged to NAT. - `ipconfig /release && /renew`, point DNS at `192.168.31.10`, `Test-ComputerSecureChannel -Repair`. ## 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.