My Windows "domain-centric" company has abruptly decided to make the switch from Windows 7 to Windows 10, and it has become my job to make their prepared image join our domain with our smart card/token based authentication system. This was an issue for Windows 7, however, it was easy to fix by building a certificate trust chain. I wasn't in charge of setting it up completely on Windows 7, so I'm not sure about the inner workings of the entire Kerberos process.
With Windows 10, however, this has been a nightmare. I've mirrored my entire process from 7 to 10, including all missing certificates (we use netdom to add via command line, with /securepasswordprompt), but no matter what I do, my computers will not join the domain with a smart card. They add without issue using a username/password (without 2FA), but with a smart card, I recieve the following error:
The KDC certificate for the domain controller does not contain the KDC Extended Key Usage (EKU): 22.214.171.124.126.96.36.199: Error Code 0xc0000320. The domain administrator will need to obtain a certificate with the KDC EKU for the domain controller to resolve this error. When using Windows Server Certificate Services create a certificated based on the Kerberos Authentication Template.
My understand is that this specific OID is for server authentication, and the root and CA certificates I have added to the computer account all have the proper purposes assigned to them. I've gone directly to our CA server on the domain and obtained the root certificates, along with CRLs that I didn't have, but the error remains the same. Today, I did more reading and enabled the kerberos debugging registry key, and after attempting to add again, the DC returned
This led me to investigate the encryption methods used between the two machines, Windows 7 has RC4, AES128/256 enabled, and Windows 10 has only AES128/256 and "future types" enabled. Naturally, I turned on RC4, so there would be consistency between the two machines, and I found myself with a new error in the event log:
KDC_ERR_PREAUTH_REQUIRED - this leads me to believe that the encryption methods are now working in conjunction with each other.
Reading online, I discovered that this
KDC_ERR_PREAUTH_REQUIRED error is usually either just a warning, or a "false positive", and can be ignored (once the machine is on the domain). Prior to the domain join, this error signifies the user typed the wrong password (I know for certain my smart card is using the correct PIN), or the encryption key is misconfigured between the machine and the DC. I also disabled
Kerberos pre-authentication required on my account in AD, but when I tried to add the machine it errored with
smartcard logon is required and was not used. I tested this with Wireshark, and I received the same error over 4 frames, in the sequence of
AS_REQ -> KDC_ERR_PREAUTH_REQ -> AS_REQ -> AS_REP.
After all that, I haven't been able to make a different error spit out, so I'm effectively stuck. I attempted to change the time on the Windows 10 machine to hours ahead of the DC, and the DC properly reported that it was unable to join due to a time skew, which I expected to happen, so I know there's some sort of communication going on. I'm able to nslookup/ping the DC by it's FQDN, and I'm unable to ping it by using only it's name. Is there any other method I could use to investigate this problem, or has anyone experienced this before?
After doing a Wireshark capture on joining a Windows 7 machine to the domain, I see the following initial pattern result (cli for client and srv for server):
(cli)AS-REQ (srv)AS-REP (cli)TGS-REQ (srv)TGS-REP (cli)TGS-REQ (srv)TGS-REP
There's a lot more in the above log, but that's the first section that differs. In contrast, on a Windows 10 machine, I see:
(cli)AS-REQ (srv)KRB Error: KRB5KDC_ERR_PREAUTH_REQUIRED (cli)AS-REQ (srv)AS-REP
... and that's where the log stops, with a failure in the event log. I read a post that discussed modifying the registry key
Security Packages under
HKLM\SYSTEM\CurrentControlSet\Control\LSA, to have
kerberos msv1_0 schannel wdigest tspkg pku2u, which is what my Windows 7 machine had. The Windows 10 machine had only two quotation marks, as
"". Adding this doesn't seem to help, though.