Fixing Active Directory error 0X000020DD when joining a domain

You're trying to join a Windows 10 or Server 2022 machine to an Active Directory domain. Midway through, it fails with ERROR_DS_SECURITY_CHECKING_ERROR (0X000020DD). The exact message says: "A security checking error has occurred."

This usually happens right after you enter domain admin credentials. The machine contacts the domain controller, but the security handshake fails. I've seen this most often on new builds where someone skipped the time zone setup, or on servers that were cloned without sysprep.

What causes this error

The root cause is almost always a time difference between the client machine and the domain controller. Active Directory uses Kerberos for authentication. Kerberos requires the client's clock to be within 5 minutes of the domain controller's clock. If it's off by more than that, the security check fails with this exact error.

DNS can also cause it — if the client can't resolve the domain controller's IP correctly, it might talk to the wrong server, which then rejects the authentication. But time is the main culprit.

Step-by-step fix

Step 1: Check the time on the client machine

1. Log into the machine that's failing to join the domain.
2. Right-click the clock in the system tray and pick Adjust date/time.
3. Look at the Time zone first. If it's wrong, change it to match your domain controller's time zone.
4. Under Synchronize your clock, click Sync now. Wait a few seconds.
5. Now open Command Prompt as Administrator (right-click Start, pick Command Prompt Admin or Windows Terminal Admin).
6. Type w32tm /query /status and press Enter. Look for the Source line — should show your domain controller or an NTP server.
7. If it says Local CMOS Clock, the time sync is off. Type w32tm /resync to force a sync.

After Step 1: The machine's time should now be within a few seconds of the domain controller. You can also check the DC's time by pinging it and looking at the timestamp, or just run net time \\DCNAME from the client.

Step 2: Verify DNS resolution

1. On the same client machine, open Command Prompt as Administrator.
2. Type ipconfig /all and look at the DNS Servers line. It should point to an internal DNS server, typically your domain controller's IP. If it's set to 8.8.8.8 or your router, that's a problem.
3. Type nslookup yourdomain.local (replace yourdomain.local with your actual domain name). You should get back an IP address that matches your domain controller. If you get a timeout or incorrect IP, fix the DNS server settings.
4. If the DNS server is wrong, go to Control Panel > Network and Sharing Center > Change adapter settings. Right-click your network adapter, pick Properties, then double-click Internet Protocol Version 4 (TCP/IPv4). Set the DNS server to your domain controller's IP.

After Step 2: Running nslookup again should show the correct IP. No errors.

Step 3: Retry the domain join

1. Open System Properties (right-click This PC, pick Properties, then click Advanced system settings).
2. Click Change under the Computer Name tab.
3. Select Domain, type your domain name, and click OK.
4. Enter domain admin credentials when prompted.

After Step 3: If time and DNS are correct, this should succeed. You'll see a welcome message and be prompted to restart.

If it still fails

Check these things:

• Is the domain controller itself healthy? Log into the DC and run dcdiag /c from an elevated command prompt. Look for any failures in the output, especially time-related ones.
• Is there a firewall blocking Kerberos? Port 88 (UDP and TCP) must be open between the client and the DC. Also port 389 for LDAP.
• Did you clone this machine? If you used a VM template or clone, the machine's SID might conflict. Run sysprep /generalize /shutdown before rejoining the domain. Without sysprep, the duplicate SID can cause weird errors like this one.
• Check the client's event log. Open Event Viewer, go to Windows Logs > System, and filter for source KDC or NETLOGON. Look for error events that mention time skew or authentication failure.

I've seen this error hundreds of times. Nine out of ten, it's the clock. Fix the time, fix the DNS, and you're done. The tenth time, it's a cloned machine or a firewall rule that someone forgot about. Start with time — it's the quickest test and the most common fix.