6

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): 1.3.6.1.5.2.3.5: 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 KDC_ERR_ETYPE_NOTSUPP.

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?

update: Changed PREAUTH_FAILED to PREAUTH_REQUIRED.

update2:

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.

Y. Park
  • 61
  • 1
  • 4

1 Answers1

1

We had the same issue and resolved it by re-issuing the domain controller certificates with the required KDC EKU. Our domain controller certificates now have four EKU's: Client, Server, KDC, and Smart Card. We also had to tweak the SAN's for our domain controller certificates.

If you don't want to do that, you may want to experiment with disabling the "Require strict KDC validation" setting on the client to see if it helps. This does seem to be a not too well documented change in behavior from Windows 7, or at least it is not consistent with how the setting is documented in the group policy settings spreadsheet/documentation.

https://technet.microsoft.com/en-us/library/hh831747.aspx

"Strict KDC validation is a more restrictive set of criteria which ensures all of the following are met:

  • The domain controller has the private key for the certificate provided.

  • For domain-joined systems, the certification authority (CA) that issued the KDC’s certificate is in the NTAuth store.

  • For non-domain-joined systems, the root CA of the KDC’s certificate is in the Third-Party Root CA or Smart Card Trusted Roots store.

  • KDC’s certificate has the KDC EKU.

  • KDC certificate’s DNSName field of the subjectAltName (SAN) extension matches the DNS name of the domain.

For non-domain-joined smart card sign on, strict KDC validation is required.

To disable this default behavior, disable the Group Policy setting Require strict KDC validation."

More information:

What's New in Kerberos Authentication
https://technet.microsoft.com/en-us/library/hh831747(v=ws.11).aspx

Strict KDC Validation default changes

"For non-domain-joined smart card sign on, strict KDC validation is required.

"To disable this default behavior, disable the Group Policy setting Require strict KDC validation."

Greg Askew
  • 34,339
  • 3
  • 52
  • 81
  • Thanks, I'll give the strict KDC validation setting a shot. My section doesn't control our domain controllers, so it's difficult for us to have changes made on them if/when they are required. I assumed the issue would be something to do with the local policy settings, since the process worked perfectly on Windows 7. – Y. Park Apr 06 '16 at 09:39
  • Okay, since I can't seem to edit my previous comment, I attempted to manually enable the strict KDC validation on the local machine's policy, but nothing affected the joining process. For reference, on Windows 7 this was set to `Not Configured`, as it was by default when I checked this morning. I also updated the original post, changing the error that I listed `PREAUTH_FAILED` to `PREAUTH_REQUIRED`. – Y. Park Apr 06 '16 at 12:03
  • Not sure why you enabled it, I mentioned *disabling* the setting. – Greg Askew Jul 07 '16 at 15:10