Fix LDAP 0X000021A8: logon failure on domain join

LDAP error 0X000021A8 shows up on Windows when the DC rejects your credentials — usually a clock skew or a stale password. Here's how to fix it fast.

You're trying to join a Windows 10 or Server 2019 box to the domain, or maybe you've got an LDAP-bound app that suddenly won't authenticate. The error pops as 0X000021A8 with a message like "The user name or password is incorrect" — but you know the password is right because you just typed it into another machine. I've seen this exact code on a client's finance app last month, and the fix wasn't what they expected.

The root cause is almost always one of two things: clock skew or a stale cached credential. LDAP authentication on a Windows domain relies on Kerberos, and Kerberos has a hard rule — if the client clock is off by more than 5 minutes from the domain controller, it flat-out rejects the ticket. The error code 0X000021A8 is the actual NTSTATUS code for STATUS_LOGON_FAILURE, which is what you see when the DC can't validate your credentials. It's not encrypted, it's not a permissions thing — it's literally "I can't trust what you just sent me."

Here's the thing: most people chase the password reset route, and that's a waste of time if the clock is wrong. A client of mine had a brand-new laptop with a CMOS battery that was dying — every reboot, the time drifted 20 minutes. That one took me 10 minutes to diagnose because I assumed it was a typo in the password. Don't be me.

Step-by-step fix

Check the time and time zone on the client.
Run w32tm /query /status in an admin command prompt. Look at the "Last Successful Sync Time" and the offset. If it says an error, or the offset is more than a few seconds, you've found your problem.
Manually resync the clock.
Stop and restart the time service, then force a resync:
```
net stop w32time
net start w32time
w32tm /resync
```
If the DC is reachable, this should pull the correct time. Verify with w32tm /query /status again.
If time is fine, clear cached credentials.
Sometimes Windows stores an old password in the credential manager, especially if you recently changed the domain password and didn't log off. Open control keymgr.dll (or go to Credential Manager in Control Panel) and remove any Windows credentials for the DC or the domain.
Flush Kerberos tickets.
Run klist purge and then klist to confirm no stale tickets remain. I've had cases where a cached ticket from a previous domain was still hanging around and causing this exact error.
Re-enter the password in the app or join wizard.
After clearing credentials and tickets, try the LDAP bind again. If you're joining the domain, run netdom join or go through the GUI with the exact username in DOMAIN\user format. Avoid using a UPN like user@domain.com unless you know the DC resolves it — some older DCs don't handle UPNs properly for LDAP binds.
Check DNS resolution.
This is the sneaky one. If the LDAP client resolves the DC by name, and DNS returns a wrong IP, you get a timeout or a bad response that shows up as 0X000021A8. Run nslookup yourdomain.com and verify it points to the actual DC. Then run ping -a <DC IP> to see the hostname it thinks it is. Mismatch? Fix your DNS.

That's the core fix. But if you're still staring at the same error after those steps, here's what to check next:

Still failing? Check these

NTP configuration on the DC itself. If the DC's clock is drifting (maybe it's a VM without time sync), then every client will fail. On the DC, run w32tm /query /source — it should say something like "VM IC Time Sync Provider" or an external NTP source. If it says "Local CMOS Clock", that's a problem. Set up a proper time source: w32tm /config /manualpeerlist:pool.ntp.org /syncfromflags:manual /update then restart the service.
Account locked out or disabled. Check the DC event log under Security for event ID 4740 (lockout) or 4725 (disabled). If you have lockout policies set aggressively, a client retrying with bad creds can trigger it.
TLD or encryption mismatch. Newer Windows versions default to LDAP signing (channel binding). If your LDAP app or the client's settings don't match, you can get auth failures that masquerade as logon failures. On the client, try adding LDAP signing require via Group Policy, or disable it temporarily to test. I've seen this on a Windows 10 22H2 machine with an old LOB app that didn't support signing.

I'll leave you with this — in my experience, 70% of these are clock skew, 20% are cached creds, and 10% are DNS. If you've done the steps and still get the error, grab a network trace with netsh trace start and just look at the LDAP bind request. It'll show you exactly which field is failing. But I bet you won't need to — fix the time, clear the creds, and you'll be done in 15 minutes.