That 0XC000040D error—STATUS_ISSUING_CA_UNTRUSTED_KDC—is a real buzzkill, especially when you're mid-domain-join and the clock's ticking. I've seen this on Windows 10 21H2, Windows 11, and Server 2019. The root cause is almost always one of three things: a time skew, a broken certificate chain for the KDC, or a stale machine account.
Here's the thing: most guides throw a wall of text at you. I'm not doing that. This is a flow. Start with the 30-second fix. If that doesn't work, move to the next. Stop when it's fixed.
The 30-Second Fix: Sync Your Clock
Kerberos is picky about time. If your client's clock is off by more than 5 minutes from the domain controller, the KDC won't trust your ticket requests, and you'll see exactly this error. I know it sounds too simple, but I've fixed production servers with just a time sync.
Open an elevated Command Prompt or PowerShell and run:
w32tm /resync
If that fails, force it against your domain controller directly:
w32tm /config /manualpeerlist:yourDC.yourdomain.com /syncfromflags:manual /reliable:YES /update
net stop w32time && net start w32time
w32tm /resync
Now try the domain join again. If it works, great—you're done. If not, don't waste time digging further into time settings. Move on.
The 5-Minute Fix: Check the KDC Certificate
This error's name gives it away: the KDC certificate isn't trusted. That happens when the domain controller's Kerberos service uses a certificate that your client doesn't have the root CA for. Common triggers? A new CA was rolled out and the old root wasn't pushed to clients, or the KDC cert expired and was replaced with one that's missing the AIA or CRL.
First, verify the cert on the DC. On the domain controller, open certlm.msc, go to Personal > Certificates, and look for one with "Kerberos Authentication" in the Enhanced Key Usage. Check the expiration date and the trust chain. If it's expired or issued by a CA your clients don't trust, that's your problem.
On the client side, make sure the root CA is in the Trusted Root Certification Authorities store. You can check with:
certutil -store Root
If you don't see the root, grab it from a working machine or the CA's web interface (usually http://yourCA/certsrv) and import it:
certutil -addstore Root rootCA.cer
Also, check the CDP (CRL Distribution Point). If the client can't reach the CRL URL, it'll treat the cert as untrusted. Make sure your client can hit that URL in a browser. If it's a firewall issue, you'll need to open it up.
After adding the root or fixing CRL access, retry the join. Saving you five minutes of forehead-slapping: don't skip the CRL check. I've seen certs that look fine but fail because the CRL is unreachable.
The 15+ Minute Fix: Reset the Machine Account
If time and certs are fine, then the KDC might be rejecting you because the machine account in AD is stale or corrupted. This happens when a computer was rebuilt with the same name, or when the account's password (the machine's Kerberos secret) got out of sync.
On the domain controller, open Active Directory Users and Computers, find the computer account, right-click it, and select Reset Account. Then on the client, unjoin the domain (makes it a workgroup), reboot, rejoin. That's the brute-force method, but it works.
If you can't unjoin (maybe you're already stuck), you can do it via PowerShell on the DC:
Reset-ComputerMachinePassword -Server yourDC.yourdomain.com
Then restart the client and try the join again. This resets the machine password without a full unjoin/rejoin.
What If It Still Fails?
Rarely, the issue is a misconfigured service principal name (SPN) for the KDC. Check with:
setspn -L yourDCYou should see krbtgt/YOURDOMAIN and krbtgt/YOURDOMAIN.YOURDOMAIN.COM. If they're missing, that's your smoking gun. Recreate them with:
setspn -A krbtgt/YOURDOMAIN yourDCAnd don't forget to check DNS. If the client can't resolve the DC's SRV records, everything else falls apart. Run nslookup -type=SRV _kerberos._tcp.yourdomain.com and make sure it returns a valid DC.
I've seen this error pop up in a heavily virtualized environment where the DC's clock jumped due to a VM snapshot. If you're using VMware or Hyper-V, disable time sync on the guest and rely on NTP. That's a sneaky one.
Bottom line: work the flow. Time first, certs second, machine account third. You'll fix it faster than hunting through forums. Good luck.