Full Diagnostic Tree & Step-by-Step Overview
What specific error message or behavior occurs when attempting to log into the Active Directory domain?
- The trust relationship between this workstation and the primary domain failed
- There are currently no logon servers available to service the logon request
- The time at the primary domain controller is different from the time at the local computer / Kerberos error
- The referenced account is currently locked out or password expired
- Logon succeeds but loads a Temporary Profile or fails Group Policy processing
How did the machine account trust failure manifest on the endpoint?
- Single workstation failed after being offline, restored from VM snapshot, or password desync
- Machine was imaged or cloned without Sysprep resulting in duplicate SID/GUID collision
Fix Broken Machine Account Secure Channel
Solution:
Root Cause: Active Directory Machine Account Password Desynchronization
Active Directory automatically resets machine account passwords every 30 days. If a workstation is powered off during password rotation, restored from an older hypervisor snapshot, or experiences network disruption, the secret stored in the local LSA secrets hive diverges from the Kerberos secret stored on the Domain Controller.
# Step-by-Step Fix:
Verify Secure Channel Status via PowerShell:Log in using local administrator credentials.Open PowerShell as Administrator and test connection: Test-ComputerSecureChannel -Verbose.If output returns False, the secure channel is broken.Repair Secure Channel Without Rejoining Domain:Run the repair command using domain credentials: Reset-ComputerMachinePassword -Credential (Get-Credential).Alternative via PowerShell: Test-ComputerSecureChannel -Repair -Credential (Get-Credential).Fallback: Rejoin Workstation to Domain:If automated repair fails, switch the computer to a Workgroup: Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters' -Name 'Domain' -Value ''.Unjoin domain: Remove-Computer -UnjoinDomainCredential (Get-Credential) -Force.Reboot, then rejoin to AD: Add-Computer -DomainName "yourdomain.com" -Restart.
Resolve Duplicate Computer Name or Machine SID Collision
Solution:
Root Cause: Duplicate Security Identifier (SID) or Hostname Conflict
Cloning disk images or deploying virtual machine templates without running the System Preparation Tool (sysprep) causes multiple machines to share the same Machine SID and Active Directory computer object attributes, corrupting AD trust tokens.
# Step-by-Step Fix:
Check Machine SID and Hostname:Run PowerShell command to verify SID: Get-WmiObject Win32_UserAccount | Select-Object Name, SID.Confirm the hostname does not collide with an existing Active Directory computer object.Run Sysprep to Regenerate System SID:Disconnect the workstation from the network.Open Command Prompt as Administrator: cd C:\Windows\System32\Sysprep.Run generalized sysprep: sysprep.exe /generalize /oobe /reboot.Reset AD Computer Object & Rejoin Domain:On the Domain Controller, open Active Directory Users and Computers (dsa.msc).Locate the affected computer object, right-click, and select Reset Account.Re-connect network cable on endpoint and join domain: Add-Computer -DomainName "yourdomain.com" -Credential (Get-Credential) -Restart.
What is the network status between the endpoint and the Domain Controller?
- Workstation network adapter points to external public DNS (e.g., 8.8.8.8) or router IP
- Workstation DNS is correct, but firewall/VPN is blocking AD RPC, LDAP, or Kerberos ports
Fix Client DNS Pointing to External Nameservers
Solution:
Root Cause: Missing Active Directory DNS Locator SRV Record Resolution
Domain logons require the Windows NetLogon service to query DNS for NetLogon SRV records (_ldap._tcp.dc._msdcs.yourdomain.com). When client network interfaces are configured with public DNS servers (e.g., 8.8.8.8 or ISP DNS), SRV lookups fail, triggering the error 'no logon servers available'.
# Step-by-Step Fix:
Audit Client Network IP Configuration:Open Command Prompt: ipconfig /all.Check DNS Servers field. Remove any public or third-party DNS IPs.Primary and Secondary DNS MUST point strictly to Active Directory Domain Controller IP addresses.Clear Local Resolver Cache and Re-test SRV Resolution:Flush local DNS: ipconfig /flushdns.Test AD DC SRV record lookup via nslookup: nslookup -type=srv _ldap._tcp.dc._msdcs.yourdomain.com.
Query DC Locator Service via Nltest:Validate DC location capability: nltest /dsgetdc:yourdomain.com.Confirm that DC: \\DC-NAME.yourdomain.com and Address: \\192.168.x.x are properly returned.
Fix Firewall / Network Port Restrictions to Domain Controllers
Solution:
Root Cause: Intervening Firewall Blocking Required Active Directory Ports
When connecting via remote VPN or across internal subnets, corporate firewalls or endpoint security software blocking Kerberos (TCP/UDP 88), LDAP (TCP/UDP 389), RPC Endpoint Mapper (TCP 135), or SMB (TCP 445) break domain controller communications.
# Step-by-Step Fix:
Test Port Connectivity from Endpoint to DC:Open PowerShell and run connection tests against your DC IP: Test-NetConnection -ComputerName 192.168.1.10 -Port 88 (Kerberos)
Test-NetConnection -ComputerName 192.168.1.10 -Port 389 (LDAP)
Test-NetConnection -ComputerName 192.168.1.10 -Port 135 (RPC Mapper)
Test-NetConnection -ComputerName 192.168.1.10 -Port 445 (SMB)
Enable Required Ports in Network & Host Firewalls:Ensure firewall rules permit bidirectional traffic for:Kerberos: Port 88 (TCP/UDP)LDAP / LDAPS: Port 389 / 636 (TCP/UDP)RPC Dynamic Ports: TCP 49152-65535 (or RPC Endpoint Mapper Port 135)Global Catalog: Port 3268 / 3269 (TCP)Verify Route and MTU Settings:If using IPsec VPN, lower MTU to prevent packet fragmentation on UDP 88 Kerberos requests: netsh interface ipv4 set subinterface "Ethernet" mtu=1400 store=persistent.
Which Kerberos authentication issue is occurring?
- System clock difference exceeds the maximum allowed Kerberos skew (5 minutes)
- Kerberos ticket request fails with duplicate SPN or max token size limit exceeded
Fix Kerberos Time Skew Desynchronization
Solution:
Root Cause: Windows Time Service Clock Skew Exceeding 5-Minute Limit
The Kerberos v5 protocol uses timestamps to protect against replay attacks. Active Directory Group Policy sets a default maximum tolerance for computer clock synchronization of 5 minutes. If local workstation time diverges beyond 5 minutes from the Domain Controller, authentication fails.
# Step-by-Step Fix:
Check Local Time vs. Domain Controller Time:Compare workstation time with DC time in Command Prompt: net time \\DC-NAME /set /y.Force Resynchronization via W32Time:Stop and restart Windows Time service: net stop w32time
w32tm /unregister
w32tm /register
net start w32time
Force synchronization against domain hierarchy: w32tm /resync /rediscover.
Verify Time Source Hierarchy:Verify client is syncing from domain PDC Emulator: w32tm /query /source.Ensure virtual machine host integration (e.g., Hyper-V Time Synchronization) is not overriding domain time sync.
Resolve Kerberos SPN Mismatch and Large Token Size Limits
Solution:
Root Cause: Service Principal Name (SPN) Duplication or Kerberos Token Bloat
If multiple AD accounts share identical SPNs, Kerberos ticket generation aborts. Additionally, users belonging to hundreds of nested security groups generate massive Kerberos tickets that exceed UDP buffer sizes, causing ticket truncation.
# Step-by-Step Fix:
Locate Duplicate SPNs in Active Directory:Run command on Domain Controller: setspn -X.If duplicates exist, remove invalid SPN assignments: setspn -D HTTP/service.domain.com AccountName.Force Kerberos Protocol to Use TCP Instead of UDP:Set MaxPacketSize registry entry to 1 on workstation to force TCP transport for Kerberos tickets: reg add "HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters" /v MaxPacketSize /t REG_DWORD /d 1 /f.
Increase Maximum Kerberos Token Size:Set maximum token buffer capacity for group-dense accounts: reg add "HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters" /v MaxTokenSize /t REG_DWORD /d 48000 /f.
What specific account credential or lockout pattern is observed?
- Account repeatedly locks out immediately after being manually unlocked
- User account cannot authenticate due to password expiration or account flags
Identify and Resolve Persistent AD Account Lockouts
Solution:
Root Cause: Stale Cached Credentials in Background Tasks, Services, or Mapped Drives
When a user updates their Active Directory password, legacy devices, stored Windows Credential Manager entries, running Windows Services, scheduled tasks, or mobile mail apps attempt authentication using old credentials, triggering repeated account lockouts.
# Step-by-Step Fix:
Identify Lockout Source Domain Controller:Download and launch Microsoft Account Lockout Status (LockoutStatus.exe).Enter locked account username to locate the specific DC receiving bad password attempts.Inspect Security Event Logs on Domain Controller:Open Event Viewer on target DC -> Windows Logs -> Security.Filter log for Event ID 4740 (A user account was locked out).Open event details and locate Caller Computer Name to identify the originating machine IP/name.Purge Stale Credentials on Originating Endpoint:Open Windows Credential Manager (control /name Microsoft.CredentialManager) and clear all Windows/Generic credentials matching domain resources.Check running background tasks: schtasks /query /v and Windows Services (services.msc) for service accounts running under user credentials.
Fix Kerberos Pre-Authentication and Password Policy Failures
Solution:
Root Cause: Expired Password, User Must Change Password Flag, or Encryption Mismatch
Logon attempts fail when Active Directory requires pre-authentication (DONT_REQ_PREAUTH missing/misconfigured), user passwords pass maximum age thresholds, or domain functional levels restrict legacy DES/RC4 ciphers.
# Step-by-Step Fix:
Audit User Account Properties in ADUC:Open dsa.msc on DC, locate user -> Properties -> Account tab.Verify flags: Ensure Account is disabled and Account is locked out are unchecked.Confirm User must change password at next logon is handled properly.Reset User Password & Force AD Replication:Right-click user account and select Reset Password.Force Active Directory replication across all DCs: repadmin /syncall /A /e /P.Ensure Supported Kerberos Encryption Types:In User Account Properties -> Account Options, ensure Use Kerberos DES encryption types for this account is UNCHECKED.Enable AES 128-bit and AES 256-bit encryption support via GPO: Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options -> Network security: Configure encryption types allowed for Kerberos.
What failure occurs after entering valid domain credentials?
- User signs in but receives error 'You've been signed in with a temporary profile'
- Group Policy processing hangs or SYSVOL/NETLOGON shares are missing on Domain Controller
Fix Windows Temporary Profile Logon Errors
Solution:
Root Cause: Registry ProfileList Key Corruption (.bak extension present)
If Windows fails to read the user's NTUSER.DAT file due to file lock or corruption, it creates a temporary profile directory (C:\Users\TEMP) and appends a .bak extension to the user's Security Identifier (SID) key under the registry ProfileList path.
# Step-by-Step Fix:
Open Registry Editor as Local Administrator:Press Win + R, type regedit, and press Enter.Navigate to: HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList.Locate and Resolve Corrupted SID Keys:Search for subkeys ending in .bak (e.g., S-1-5-21-...bak).Verify ProfileImagePath inside the key points to the correct user folder (e.g., C:\Users\username).If a matching key exists WITHOUT .bak (pointing to TEMP), right-click and delete it.Rename the .bak key by removing the .bak extension.Reset RefCount and State Values:Inside the restored key, set RefCount DWORD value to 0.Set State DWORD value to 0.Reboot computer and log in with domain account.
Fix SYSVOL and NETLOGON Share Unavailability on Domain Controller
Solution:
Root Cause: DFSR / FRS Replication Failure into Dirty Shutdown State
Domain Controllers host Group Policy Objects (GPOs) and login scripts in the SYSVOL and NETLOGON shared folders. If DFS Replication (DFSR) halts due to improper shutdown or database corruption, the DC stops publishing SYSVOL, causing domain client GPO processing and logons to fail.
# Step-by-Step Fix:
Verify SYSVOL and NETLOGON Shares on DC:Open Command Prompt on Domain Controller: net share.Verify SYSVOL and NETLOGON appear in the share list.Inspect Event Viewer for DFSR Errors:Open Event Viewer -> Applications and Services Logs -> DFS Replication.Check for Event ID 2213 (DFS Replication paused due to dirty shutdown).Perform Non-Authoritative SYSVOL Sync Restore:Run command to resume DFSR replication as prompted in Event 2213: wmic /namespace:\\root\microsoftdfs path dfsrreplicatedfolderinfo where "replicatedfoldername='SYSVOL Share'" call resumereplication.
Verify Event ID 4604 appears indicating SYSVOL replication successfully initialized and shares are online.