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
+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