Identity infrastructure lab report

Active Directory Secure-Channel and DNS Troubleshooting

Recovering a Windows 11 domain client by separating basic IP reachability from DNS-driven Active Directory discovery and stale machine-account state.

Problem statement

Restore a Windows 11 client to a usable domain-authenticated state.

The client could reach the domain controller by IP address, but domain operations continued to fail. The objective was to determine why the Active Directory control plane remained unhealthy even though Layer 3 reachability was present, then recover the client without rebuilding the domain controller.

Identity design

The lab uses two AD identities so later FortiGate FSSO policies can enforce different outcomes. faraz belongs to Domain Users and Forti_Guests. employee_test belongs only to Domain Users.

PowerShell output showing Active Directory group memberships
PowerShell verification of the intended AD group design.
Active Directory Users and Computers showing faraz in Forti Guests
GUI corroboration: faraz is the only member of the Forti_Guests group.

Failure state

The client had a broken domain trust relationship. Initial repair attempts failed. A successful ping to the DC was not enough: Active Directory also depends on DNS host records, LDAP SRV records, and a healthy machine-account relationship.

PowerShell domain join failure showing domain could not be contacted
Failed domain-join attempt from WORKGROUP. The client still could not contact the domain correctly.

Troubleshooting method

  • Validated that the domain controller was healthy enough to continue rather than rebuilding it.
  • Separated ICMP reachability from DNS-driven AD service discovery.
  • Restricted client DNS to the domain controller at 192.168.1.96 and temporarily removed IPv6 router-DNS interference from the test path.
  • Deleted the stale client machine object from the AD Computers container.
  • Verified DNS and domain-controller discovery before rejoining lab.local.
Windows DNS Manager showing public DNS forwarders
The DC forwards public DNS queries upstream while remaining the internal DNS service for the AD lab.
Active Directory Users and Computers showing client machine account
Machine-account context in the AD Computers container. Stale client state was removed before rejoin.

Remediation sequence

  1. Return the client to WORKGROUP.
  2. Delete the stale DESKTOP-IO53IGD machine object in ADUC.
  3. Configure the client to use only the DC for DNS.
  4. Clear cached DNS state and verify the AD DNS records.
  5. Rejoin the domain using LAB\Administrator credentials.
  6. Log in as LAB\faraz and validate the active token.
PowerShell whoami output showing lab faraz
Successful domain-authenticated session: lab\faraz.
PowerShell token output showing LAB Forti Guests enabled
The logged-in Windows token contains enabled LAB\Forti_Guests membership.

Root-cause interpretation

The evidence supports a conservative conclusion: DNS and domain-controller discovery problems, combined with stale machine-account state, were likely contributing factors. The recovery sequence removed both conditions and restored domain authentication. The report deliberately avoids claiming that a single isolated fault was proven as the only cause.

Operational interpretation

  • A successful ping does not prove that Active Directory is healthy.
  • AD clients rely on DNS SRV records to locate services such as LDAP.
  • Domain clients should query the AD DNS server rather than bypass it with public resolvers.
  • Secure-channel failures require attention to identity state as well as transport reachability.
  • The recovered identity design is ready for a later FortiGate FSSO policy lab.