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
+18 -8
View File
@@ -85,7 +85,7 @@
<tbody>
<tr><td><strong>DC01</strong></td><td>Windows Server 2022 Standard</td><td>Domain Controller</td><td>192.168.31.10</td><td>AD DS, DNS, PDC Emulator, Schema &amp; Domain Naming Master, Global Catalog</td></tr>
<tr><td><strong>FILE01</strong></td><td>Windows Server 2022 Standard</td><td>Member server</td><td>192.168.31.20</td><td>SMB file services; <code>IT</code> departmental share</td></tr>
<tr><td><strong>WIN11-01</strong></td><td>Windows 11 Education</td><td>Domain client</td><td><em>NIC change pending</em></td><td>Domain-joined workstation</td></tr>
<tr><td><strong>WIN11-01</strong></td><td>Windows 11 Education</td><td>Domain client</td><td>192.168.31.x (NAT)</td><td>Domain-joined workstation</td></tr>
<tr><td><strong>OPNSENSE</strong></td><td>OPNsense (FreeBSD)</td><td>Firewall / router</td><td>VMnet8 &harr; VMnet2</td><td>Segmenting server (VMnet8) and client (VMnet2) networks</td></tr>
</tbody>
</table>
@@ -220,13 +220,23 @@ w32tm /resync /rediscover</pre>
<pre class="lab-code">wevtutil cl System
dcdiag /q</pre>
<p class="status-ok">Verified: <code>dcdiag /q</code> now silent (clean).</p>
<h3 class="h3-sub">Pending (user-side VMware GUI)</h3>
<h3 class="h3-sub">Client domain restoration (completed)</h3>
<p>
WIN11-01's vmx is encrypted and its NIC is bridged to the physical LAN
(192.168.1.132), so it currently can't reach DC01 (192.168.31.10). Fix is a
VMware-side NIC change plus a <code>Test-ComputerSecureChannel -Repair</code>.
Documented honestly rather than papered over.
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:
</p>
<pre class="lab-code">PS&gt; Test-ComputerSecureChannel -Verbose
VERBOSE: The secure channel between the local computer and the domain ad.bytegeist.lab is in good condition.
True
PS&gt; 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&gt; whoami
bglab\administrator</pre>
<p class="status-ok">Verified: secure channel healthy, DC01 reachable as PDC / GC / KDC / DNS.</p>
</div>
</div>
</div>
@@ -244,9 +254,9 @@ dcdiag /q</pre>
<li><strong>DNS</strong> &mdash; AD-integrated primary zones, reverse zones, understanding why the client's DNS must point at the DC.</li>
<li><strong>SMB &amp; NTFS</strong> &mdash; share creation, share-level vs. NTFS permissions, role-based access through groups.</li>
<li><strong>PowerShell</strong> &mdash; <code>Get-AD*</code>, <code>Invoke-Command</code>, <code>Get-SmbShareAccess</code>, <code>Get-Acl</code>, <code>w32tm</code>, <code>Test-ComputerSecureChannel</code>.</li>
<li><strong>Troubleshooting</strong> &mdash; recognizing <em>Local CMOS Clock</em> as a future Kerberos failure; recognizing an Access Denied on WinRM as "not in the server's local Administrators."</li>
<li><strong>Troubleshooting</strong> &mdash; recognizing <em>Local CMOS Clock</em> as a future Kerberos failure; diagnosing a broken secure channel as a bridged-NIC / wrong-DNS fault and restoring it with <code>Test-ComputerSecureChannel -Repair</code>.</li>
<li><strong>Virtualization &amp; networking</strong> &mdash; VMware Workstation Pro, VMnet subnetting, OPNsense placement, bridged vs. NAT NIC implications.</li>
<li><strong>Honest audit documentation</strong> &mdash; the <code>WIN11-01 pending</code> callout stays visible, with the exact fix listed.</li>
<li><strong>Honest audit documentation</strong> &mdash; problems (PDC time source, bridged client NIC) recorded with the exact fix applied, not hidden.</li>
</ul>
</div>
</section>