STATUS_CANT_ACCESS_DOMAIN_INFO (0XC00000DA) Fix

Quick Answer (for the impatient)

Run ipconfig /flushdns && nltest /sc_verify:yourdomain.com from an elevated command prompt. If that fails, nltest /sc_reset:yourdomain.com usually fixes it. Still broken? Reset the computer account with netdom resetpwd /s:yourDC /ud:domain\admin /pd:*.

Why You're Seeing 0XC00000DA

This error means the workstation lost its trust relationship with the domain controller. The local machine can't reach a domain controller to validate your credentials. The culprit here is almost always one of three things: DNS records pointing to the wrong server, a stale computer account password, or the machine's secure channel timing out after a long power-off period. I've seen this most often after a network team changes DNS servers without telling anyone, or after a laptop sits in a drawer for six months and comes back to life.

Step-by-Step Fix

Step 1: Verify the Obvious

1. Check network connectivity — can you ping the domain controller by FQDN? ping dc01.yourdomain.com
2. Check DNS: nslookup yourdomain.com should return the DC's IP. If it doesn't, your DNS servers are wrong.
3. If you're off the corporate network, connect via VPN first. The domain controller must be reachable.

Step 2: Flush DNS and Reset the Secure Channel

Open command prompt as Administrator.

ipconfig /flushdns
nltest /sc_verify:yourdomain.com

If nltest returns ERROR_ACCESS_DENIED or RPC_S_SERVER_UNAVAILABLE, run the reset:

nltest /sc_reset:yourdomain.com

This forces the machine to renegotiate the secure channel. In 8 out of 10 cases, this alone fixes it.

Step 3: Reset the Machine Account Password

If step 2 fails, the computer account password is out of sync. You'll need domain admin credentials. Run:

netdom resetpwd /s:yourDC /ud:yourdomain\adminuser /pd:*

Replace yourDC with the name of any domain controller, yourdomain\adminuser with a domain admin account. It'll prompt for the password. No output means success.

Step 4: Rejoin the Domain (Nuclear Option)

When the above fails — and it rarely does — you unjoin and rejoin. Back up any local data first. Go to System Properties > Computer Name > Change. Unjoin, restart, then rejoin with domain admin creds. This is a last resort because it breaks local profiles.

Alternative Fixes (When Main Steps Fail)

• Check time sync: Run w32tm /query /status. If it's off by more than 5 minutes, Kerberos won't work. Fix with w32tm /resync.
• Reboot the DC: I know, sounds dumb, but I've had DCs with hung LSASS processes that block secure channel resets. Reboot the DC if you can.
• Check for duplicate SPNs: Run setspn -Q HOST/machineName on the DC. Duplicates cause auth failures.

Prevention Tips

• Never change DNS servers without updating DHCP: Point all clients to internal DNS that can resolve the domain.
• Enable automatic machine account password reset: Group Policy > Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options > "Domain member: Maximum machine account password age" — set it to 30 days. The default is 30, but somebody always sets it to 0 (never) and breaks things.
• Use a VPN client that connects before login: For laptops, configure DirectAccess or Always On VPN. Without it, roaming users hit this error constantly.

Real-world trigger: A user moved desks, plugged into a different switch port that was on a VLAN with no route to the domain controller. DNS worked for internet but not for the internal domain. Flushed DNS, fixed the VLAN, problem gone.