← Projects

ByteGeist Windows Server / AD Homelab

A multi-VM Windows Server 2022 Active Directory environment I run on VMware Workstation Pro to practice day-to-day Help Desk and Junior SysAdmin work: domain services, DNS, OU and group design, SMB file sharing with role-based access, PowerShell troubleshooting, and the kind of break/fix that shows up in interview questions.

The topology, command output, and configuration details on this page reflect the lab state verified on 2026-10-03.

Windows Server 2022 Active Directory DS DNS SMB & NTFS PowerShell / WinRM VMware Workstation OPNsense
Topology diagram: DC01 (192.168.31.10) and FILE01 (192.168.31.20) on VMnet8/NAT, OPNsense between VMnet8 and VMnet2, WIN11-01 domain-joined client
Verified topology — generated from ipconfig, Get-ADDomain, Get-SmbShare, and VMware vmnetdhcp.conf.

Systems

Four VMs, verified from vmrun and in-guest audits
SystemOperating SystemRoleAddressPurpose
DC01Windows Server 2022 StandardDomain Controller192.168.31.10AD DS, DNS, PDC Emulator, Schema & Domain Naming Master, Global Catalog
FILE01Windows Server 2022 StandardMember server192.168.31.20SMB file services; IT departmental share
WIN11-01Windows 11 EducationDomain client192.168.31.x (NAT)Domain-joined workstation
OPNSENSEOPNsense (FreeBSD)Firewall / routerVMnet8 ↔ VMnet2Segmentation lab; VMnet2 client placement is planned, while current systems remain on VMnet8

File services & permissions

FILE01 — Get-SmbShareAccess and Get-Acl

FILE01 publishes one departmental share and uses the IT Employees security group to grant access — accounts never get rights directly on resources, groups do. The share-level cap is Change; NTFS grants Modify explicitly to BGLAB\IT Employees.

Share IT at C:\Shares\IT

Share-level ACL

AccountTypeRight
BGLAB\Domain AdminsAllowFull
BGLAB\IT EmployeesAllowChange

NTFS ACL

IdentityRightsInherited
BGLAB\IT EmployeesModify, SynchronizeNo (explicit)
NT AUTHORITY\SYSTEMFullControlYes
BUILTIN\AdministratorsFullControlYes
BUILTIN\UsersReadAndExecute + CreateFiles + AppendDataYes
CREATOR OWNERFull on child objectsYes

Hardening note: the inherited BUILTIN\Users entry is broader than the intended IT-only access model. The next ACL change is to disable inheritance and retain only the required administrative and IT group permissions.

How it was verified

PS> Invoke-Command FILE01 {
      Get-SmbShare |
        Where-Object Name -NotIn 'ADMIN$','C$','IPC$' |
        Get-SmbShareAccess
      (Get-Acl C:\Shares\IT).Access
    }

Run from DC01 as a Domain Admin via WinRM, output captured to a transcript on the host (not inside the VM) so no sensitive data lives on a shared share.

Validation & fixes applied

Real problems found & resolved during the audit

Problem: PDC was using the local CMOS clock

The PDC Emulator is the authoritative time source for a Windows forest. If it drifts, Kerberos tickets outside the 5-minute skew window fail — a classic "I can't log in" root cause. w32tm /query /source returned Local CMOS Clock.

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: Source: time.windows.com,0x9, Stratum 5.

Problem: stale dcdiag SystemLog failure

A past unexpected shutdown left an entry that dcdiag flagged on every run. I confirmed the stale shutdown event was the source, cleared the lab System log, and re-ran dcdiag /q. In a production workflow, I would export the log before clearing it to preserve evidence.

# Production-safe sequence:
wevtutil epl System C:\Temp\System-before-clear.evtx
wevtutil cl System
dcdiag /q

Verified: dcdiag /q now silent (clean).

Client domain restoration (completed)

WIN11-01's NIC was moved from a bridged physical-LAN adapter to the lab NAT network, DNS was pointed at DC01, and the machine account trust was repaired. Verified domain authentication and DC discovery:

PS> Test-ComputerSecureChannel -Verbose
VERBOSE: The secure channel between the local computer and the domain ad.bytegeist.lab is in good condition.
True
PS> nltest /dsgetdc:ad.bytegeist.lab
DC: \\DC01.ad.bytegeist.lab
Address: \\192.168.31.10
Flags: PDC GC DS LDAP KDC TIMESERV ... DNS_DC DNS_DOMAIN DNS_FOREST
The command completed successfully
PS> whoami
bglab\administrator

Verified: secure channel healthy, DC01 reachable as PDC / GC / KDC / DNS.

Security note: this repair transcript was captured from a built-in Administrator maintenance session. A separate named administrative account and non-privileged daily workstation sign-in are the preferred next hardening step.

Skills demonstrated

Why this project matters for IT roles
  • Windows Server 2022 — installed, promoted to a DC, operate day-to-day.
  • Active Directory — domain / forest design, OUs, users and groups, FSMO awareness, Global Catalog.
  • DNS — AD-integrated primary zones, reverse zones, understanding why the client's DNS must point at the DC.
  • SMB & NTFS — share creation, share-level vs. NTFS permissions, and role-based access through groups. The current IT folder still inherits BUILTIN\Users permissions; disabling inheritance and applying explicit ACLs is a documented hardening task.
  • PowerShell — Get-AD*, Invoke-Command, Get-SmbShareAccess, Get-Acl, w32tm, Test-ComputerSecureChannel.
  • Troubleshooting — recognizing Local CMOS Clock as a future Kerberos failure; diagnosing a broken secure channel as a bridged-NIC / wrong-DNS fault and restoring it with Test-ComputerSecureChannel -Repair.
  • Virtualization & networking — VMware Workstation Pro, VMnet subnetting, OPNsense placement, bridged vs. NAT NIC implications.
  • Honest audit documentation — problems (PDC time source, bridged client NIC) recorded with the exact fix applied, not hidden.

Want to see the full audit log?

Phases, verified command output, problem-and-fix table, security notes.