WIN11-01 restored: secure channel verified True, DC discovery via nltest, domain auth as bglab\administrator. Topology diagram and docs updated; pending callouts removed.

This commit is contained in:
Keith Casko
2026-10-03 08:51:50 -04:00
parent 748f6d7bf9
commit 0c19e24c5e
4 changed files with 68 additions and 41 deletions
+7 -7
View File
@@ -18,7 +18,7 @@ Three virtual machines on VMware Workstation Pro 17, plus an OPNsense firewall V
|---|---|---|---|---|
| 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 |
| 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
@@ -84,7 +84,7 @@ Role-based access via group membership: only members of `BGLAB\IT Employees` get
## 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).
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
@@ -112,7 +112,7 @@ Run from DC01 as `BGLAB\Administrator`, output captured to transcripts on the ho
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.
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
@@ -121,11 +121,11 @@ Run from DC01 as `BGLAB\Administrator`, output captured to transcripts on the ho
- 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):
Client restoration (completed 2026-10-03, VMware GUI + guest PowerShell):
- 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`.
- 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