Fix error 0X000008A6 logon server not found

What this error actually means

I've seen 0X000008A6 on Windows Server 2016, 2019, 2022, and Windows 10/11. The error text says "The logon server was not specified" and it usually pops up when you try to access a shared drive, remote desktop, or run a domain-joined application. The culprit is almost always DNS resolution failing — your machine can't find a domain controller (DC).

Here's the scenario: You're on a domain-joined PC, trying to map a drive to \\server\share. You get this exact hex error. Or you open an app that authenticates against Active Directory. It fails with 0X000008A6. Don't bother checking the time sync first — that's a red herring 80% of the time. DNS is where you start.

30-second fix: check DNS resolution

Open Command Prompt as admin. Run nslookup yourdomain.com — replace with your actual domain name like contoso.local. If it fails or returns wrong IP, your DNS is broken. Also run nslookup %LOGONSERVER% — if that variable is empty, your machine lost trust with the domain.

nslookup yourdomain.com
nslookup %LOGONSERVER%

If nslookup returns an IP but it's not a domain controller IP, your DNS records are stale. Quick fix: flush DNS cache and re-register. Type:

ipconfig /flushdns
ipconfig /registerdns

Then reboot. This fixes maybe 1 in 4 cases. If not, move on.

5-minute fix: check network and firewall

Your machine needs to reach the domain controller on ports 53 (DNS), 88 (Kerberos), 135 (RPC), 139/445 (SMB), 389 (LDAP), and 464 (Kerberos change password). A common mistake: someone blocked outbound traffic on these ports in a third-party firewall like McAfee or Norton. Or more often, Windows Firewall with Advanced Security has a rule disabled.

Run this command to test basic connectivity to a DC:

Test-NetConnection -ComputerName YOURDC -Port 389

If that fails, check your firewall rules. Also run ping YOURDC — if ping works but port 389 doesn't, it's a firewall issue. If ping fails entirely, it's a routing or DNS problem.

One more thing: check if your network adapter has multiple gateways or DNS servers. Run ipconfig /all. You should see only one default gateway and your domain's DNS servers (usually 2). If you see a public DNS like 8.8.8.8 as primary, that's your problem. Windows domain clients must use internal DNS servers that can resolve SRV records for _ldap._tcp.dc._msdcs.yourdomain.com.

nslookup -type=SRV _ldap._tcp.dc._msdcs.yourdomain.com

If that returns no records, your DNS zones are misconfigured. You'll need to fix that on the DNS server side.

15+ minute fix: check machine trust and security

If DNS and network ports are fine, your machine might have a broken trust relationship with the domain. This happens after a domain controller restore, a password reset, or if the machine was offline for too long (over 30 days by default).

First, check if you can still log in with a local admin account. If you can't, boot into safe mode and use the built-in Administrator account. Then run:

Test-ComputerSecureChannel -Verbose

If it returns False, reset the trust:

Reset-ComputerMachinePassword -Server YOURDC -Verbose

If that fails, you'll need to unjoin and rejoin the domain. Do this from the System Properties (sysdm.cpl). Choose "Change" under Computer Name, then select "Workgroup", type a temp workgroup name (like WORKGROUP), reboot, then rejoin the domain. You'll need domain admin credentials.

Also check the machine account password in AD. Use ADSI Edit or Active Directory Users and Computers to see if the computer account is disabled or password expired. Right-click the computer object, go to Properties, check Account tab — the password should not be expired. If it is, reset it from there.

Last resort: check for third-party software that interferes with logon. I've seen VPN clients (especially Cisco AnyConnect and Pulse Secure) block Kerberos traffic. Or antivirus suites that quarantine LSASS. Temporarily disable them to test.

If none of this fixes it, you might have a corrupted system file. Run sfc /scannow and DISM /Online /Cleanup-Image /RestoreHealth. Then reboot and try again.

Note: If you're getting this error on a standalone server (not domain-joined), the error is misleading. It means the local SAM can't handle the authentication. Check if the Local Security Authority service is running. Run services.msc, find "Credential Manager" and "Security Accounts Manager", make sure they're started and set to Automatic.

One final trick: sometimes the issue is a misconfigured hosts file. Check C:\Windows\System32\drivers\etc\hosts. Delete any entries for your domain controller that point to wrong IPs. Also check the LMHOSTS file if you use NetBIOS names.

That's the complete troubleshooting flow. Start with DNS, then network, then trust. You'll fix it in one of those steps in my experience.