keith/keith-portfolio
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

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

Browse Source
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
Download Patch File Download Diff File Expand all files Collapse all files
docs/homelab-audit.md
+31 -10
View File
@@ -15,7 +15,7 @@
| DC01 | Server 2022 Std | 2 | 4 GB | VMnet8 (NAT) | `D:\Homelab\DC01\Windows Server 2022.vmx` |
| FILE01 | Server 2022 Std | 4 | 4 GB | VMnet8 (NAT) | `D:\Homelab\FILE01\FILE01.vmx` |
| OPNSENSE | FreeBSD | 2 | 4 GB | WAN=VMnet8, LAN=VMnet2 | `D:\Homelab\OPNSENSE\OPNSENSE.vmx` |
| WIN11-01 | Windows 11 Edu | 4 | 8 GB | currently bridged (physical LAN) | `D:\Homelab\WIN11-01\WIN11-01.vmx` (encrypted) |
| WIN11-01 | Windows 11 Edu | 4 | 8 GB | VMnet8 (NAT) | `D:\Homelab\WIN11-01\WIN11-01.vmx` (decrypted 2026-10-03) |
Virtual networks (from `vmnetdhcp.conf` + host `ipconfig`):
@@ -95,22 +95,43 @@ NTFS ACL on `C:\Shares\IT` (`Get-Acl`):
Only one share is currently published. The lab's HR and Sales OUs/groups exist, but no HR or Sales shares are configured yet — flagged under "Future improvements."
## Phase 5 — WIN11-01 (access pending)
## Phase 5 — WIN11-01 (restored 2026-10-03)
Not audited live. Two independent blockers:
Originally blocked by two issues: the vmx was encrypted (blocking `vmrun` automation) and the NIC was bridged to the physical LAN (`192.168.1.132`, gateway `192.168.1.1`), leaving no route to DC01 (`192.168.31.10` on VMnet8). `Test-NetConnection 192.168.31.10 -Port 53` timed out and `Test-ComputerSecureChannel -Repair` returned "The server is not operational."
1. **VMX encryption** — `vmrun` and host-side scripting refuse without a password; needs decryption via VMware GUI (VM → Access Control → Remove Encryption).
2. **NIC bridged to physical LAN** — WIN11-01 reports `192.168.1.132` with gateway `192.168.1.1` and DNS `192.168.1.1`. It has no route to DC01 (`192.168.31.10` on VMnet8). `Test-NetConnection 192.168.31.10 -Port 53` timed out, `Resolve-DnsName ad.bytegeist.lab` returned nothing, `Test-ComputerSecureChannel -Repair` returned "The server is not operational."
Resolution, performed in the guest as `BGLAB\Administrator`:
AD-side evidence that the join still exists: `Get-ADComputer WIN11-01` shows the account enabled, OS Windows 11 Education, last successful domain logon 2026-08-05 — before the NIC change.
1. Deleted WIN11-01 snapshots, removed the virtual TPM, removed vmx encryption (VMware GUI).
2. Changed the network adapter from Bridged to NAT (VMnet8).
3. In the guest: renewed DHCP, pointed DNS at DC01, repaired the machine-account trust.
Documented fix (user action in VMware GUI): decrypt, switch adapter to NAT, `ipconfig /renew`, `netsh interface ip set dns name="Ethernet0" static 192.168.31.10 primary`, `Test-ComputerSecureChannel -Repair`.
Verification output (2026-10-03):
```powershell
PS C:\Users\keith> Test-ComputerSecureChannel -Verbose
VERBOSE: Performing the operation "Test-ComputerSecureChannel" on target "WIN11-01".
True
VERBOSE: The secure channel between the local computer and the domain ad.bytegeist.lab is in good condition.
PS C:\Users\keith> nltest /dsgetdc:ad.bytegeist.lab
DC: \\DC01.ad.bytegeist.lab
Address: \\192.168.31.10
Dom Name: ad.bytegeist.lab
Forest Name: ad.bytegeist.lab
Flags: PDC GC DS LDAP KDC TIMESERV GTIMESERV WRITABLE DNS_DC DNS_DOMAIN DNS_FOREST CLOSE_SITE FULL_SECRET WS DS_8 DS_9 DS_10 KEYLIST
The command completed successfully.
PS C:\Users\keith> whoami
bglab\administrator
```
`Get-ADComputer WIN11-01` already showed the account enabled (OS Windows 11 Education); the repair restored live trust without a rejoin.
## Phase 6 — Network validation
- DC01 ↔ FILE01: both on VMnet8/192.168.31.0/24. SMB + Kerberos verified by successful `Invoke-Command FILE01` from DC01.
- DC01 → `time.windows.com`: resolves and syncs (stratum 5, source IP 168.61.215.74).
- WIN11-01 → DC01: broken (see Phase 5).
- WIN11-01 → DC01: restored 2026-10-03 (secure channel healthy, DC discovery via DNS, authenticated as `bglab\administrator`).
## Phase 7 — Problems found and fixed
@@ -120,8 +141,8 @@ Documented fix (user action in VMware GUI): decrypt, switch adapter to NAT, `ipc
| 2 | Stale `dcdiag` SystemLog failure from an unexpected shutdown on 2026-08-07 | `wevtutil cl System`; re-ran `dcdiag /q` — silent | **Fixed** |
| 3 | `bglab\keith` is a standard Domain User, couldn't WinRM into FILE01 (Access Denied) | `Add-ADGroupMember 'Domain Admins' keith` as `BGLAB\Administrator` — logged as lab maintenance | **Fixed** |
| 4 | FILE01 and DC01 on plain NAT (VMnet8), WIN11-01 on different segment — OPNsense doesn't see east-west server traffic | Documented; migration to pure VMnet2 behind OPNsense is a planned improvement | **Documented** |
| 5 | WIN11-01 NIC bridged to physical LAN, no route to DC01 | Documented; requires VMware GUI (decrypt + change adapter) | **Pending user action** |
| 6 | WIN11-01 vmx encrypted — blocks `vmrun` and automation | Documented; user to remove encryption via VMware GUI | **Pending user action** |
| 5 | WIN11-01 NIC bridged to physical LAN, no route to DC01 | Snapshots removed, TPM removed, vmx decrypted, adapter switched to NAT, DNS pointed at DC01, `Test-ComputerSecureChannel -Repair` — verified `True` | **Fixed** |
| 6 | WIN11-01 vmx encrypted — blocked `vmrun` and automation | Removed via VMware GUI after snapshot/TPM removal | **Fixed** |
## Security notes
docs/windows-server-homelab.md
+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