Kdc Certificate Could Not Be Validated Windows Hello

[Edelmar Easley]

Igot some users with Win10, that got this error "KDC certificate could not be validated issue." if they try to logon with Face/PIN (WHFB). It seems to be related that if they wait a couple of minutes until DirectAccess or wifi is connected is working fine.

No issues in eventlog on DCs.

The CRL is public internet facing and working both external/internal for the users.

Related to -US/08361cfd-0c9b-4481-9cc7-00920e374b01/kdc-certificate-could-not-be-validated-error?forum=winserversecurity

Cleanup any Root Certificates that point to non existing CAs within you Local Certificate Store certlm.msc only leaving your active CA server, these can be found in your Trusted Root Certification Authorities and Intermediate Certification Authorities.

We have recently setup 802.1x auth and are using EAP-TTLS auth method. We seem to have it working with our Windows 10 clients at this stage of testing, but I keep getting this popup window titled Ethernet Authentication "Can't verify the server's identity".

I think there is a step we missed when setting up our certificate infrastructure. Do we need to register a certificate for each of our ExtremeControl RADIUS servers (we have 15 total) with our certificate authority (internal active directory domain controller). I know just enough about certificates to be dangerous, but I "think" the client get this message because the server is not "registered" with our CA and therefore the client can't verify the RADIUS servers identity. Just need some guidance on why this is happening and what would stop it. Also, if someone has setup their windows environment to use 802.1x with ExtremeControl servers and EAL-TTLS, please let me know if there is some step-by-step guide out there to follow. Thank you.

Hello,

There are are a few considerations that you may be running into. As Robert indicated above you're using a certificate that cannot be validated and should be replaced with a more appropriate certificate.

One consideration that you may be running into is that the client supplicant needs to be configured with server identity parameters in addition to certificate validation.

Even if you have a commercially signed certificate installed in the RADIUS server, if an end system does not have supplicant configurations for server identity it will prompt a "Trust Anchor" or similar server identity message.

Example seen for wireless:

-networks.my.site.com/ExtrArticleDetail?an=000100189

Thank you for the replies. I will work with my team to get these RADIUS servers setup with our internal CA in our windows domain. I do have multiple RADIUS servers (one at each of 12 sites and 2 at the Data Centers for backups). I will get all of them added to our CA since it will depend on which switch and location the user will use for RADIUS. This is just for wired so far, I still have wireless 802.1x to setup and test.

I would need to test it in the lab to be 100% but, I'm assuming that if that profile is manually created on the client you'll be OK. The problem with certificate validation/server identity trust is typically seen when Windows tries to setup the wireless profile on initial connection.

You appear to be using the default self-signed untrusted certificate that ships with Extreme Control. This certificate is not trusted by any device so the warning presented to clients to 'verify' if they wish to Connect or Disconnect is valid.

I have Accounting enabled on the Windows Server (which is now a DC running Server 2016. I had been running 2012 R2 but decided to wipe it and install 2016 afresh as though maybe RADIUS worked better!). The NPS Account log shows this when I click the Test button:

I joined this forum purely to post this reply, hopefully it helps your case. I was dealing with this problem today, and got to the point where I had the exact same issue above. My Windows 10 wifi would not authenticate, but my iPhone wifi would authenticate and work fine with the username and password once you trust a cert.

I solved this on my Windows 10 machine by connecting to the SSID, and not ticking "use my Windows user account" at the prompt, and instead I typed in my username and password without the domain prefix. A new message will appear asking you to confirm the expected domain it found, then it connects. Who knew.

Yes, I have a certificate selected in NPS > Network Policies > My Meraki Policy > Constraints > Auth Methods > Microsoft PEAP > (Edit), issued by the server I installed the CA role on. I suspect it could be failing to do with this? I think at some point I created a Group Policy to deploy that certificate to client PC's, perhaps something is amiss with that but I can't seem to get enough info from any logs.

Thanks, I did come across that thread previously (with all the Spanish screenshots!) but I think I need to get the Test button working from the Meraki dashboard > Access Control for SSID first, before I then troubleshoot client PC's, would you agree?

Okay I'll give it a go. Our clients are all Windows 10. At the moment when I try to connect to the Radius SSID it prompts me for credentials, with a tickbox to 'use my Windows user account', which if I tick fills in the boxes with my AD credentials. It check network requirements after clicking OK, but the credentials prompt just comes back again.

Interesting to read your post, i'm in pretty much the same boat. So I can sympathize with your struggles, I'm dealing with almost the same thing. One thing I wanted to mention is to be sure that your NPS Network Policy is configured per the Meraki Documentation for 802.1X authentication (in addition to having your RADIUS Clients portion configured) since I found it needed both in order to test from the Meraki Dashboard. Check the following:

So, i've gone through much of what you've already outlined and get the same interesting behavior. Macs and Apple IOS devices can successfully authenticate against AD using RADIUS, but only after they "Trust" the AD CS certificate used on our Domain.

I'm at a loss. I think this is a certificate issue on the windows end stations, but i am not sure how to fix this. I'd like to avoid having to push out a GPO to get this going. We have a large traveling workforce that doesn't always get GPO updates in a timely manner because they are off the domain most of the time.

I was able to get this resolved / working. Make sure that Wireless > Access Control > 802.11r is set to "Adaptive" (not Enabled). I think at one point we had turned this on. The tooltip description of what 802.11r made me think it only applied to old systems, not the Windows 10 computers we were having problems with.

802.11r technology reduces overhead when a client roams from one AP to another, delivering a more seamless transition. "Enabled" will activate 802.11r for devices that support it, though some legacy clients may not be able to join the network. "Adaptive" enables a custom version of 802.11r just for Apple iOS devices. Very few devices will have compatibility challenges with the "Adaptive" mode.

I was really hopeful with your suggestion on 802.11r, however I don't seem to have an 802.11r section in my dashboard! Searching for it just takes me to the Access Control page but the nearest thing to that on the page is 802.11w.

I've opened my AD user properties, navigated to the Dial-in tab, changed Network Access Permission to 'Control access through NPS Network Policy', then rebooted my laptop but no joy. I then changed it to 'Allow access' but still no joy. I made these changes on my local domain controller, but I'll try again in an hour or so in case it's referring to another DC for some reason.

With my user profile in AD set to 'Allow access' under the Dial-in tab, and the computer account having always been set to 'Control access through NPS Network Policy', I now see in Event Viewer on the NPS server:

I'm looking at your NPS logs and its definitely trying to authenticate a computer account (as opposed to a user security group), is this by design? You will need to have a matching NPS policy which allows the AD computer group(s) under NPS > Policies > Network Policies > (policy name) > Properties > "Conditions" Tab.

Note that when using conditions in NPS that all conditions have to be true. So when you want to match on Windows Groups (and assuming whatever needs access is not in both groups) you have to put both of those groups into a single condition.

If I change it to an OR condition, which I have previously tried, and set the condition to Windows Groups, when attempting to connect it just hangs on 'Verifying and connecting' on the laptop for a minute or so, then eventually ask for credentials. I tick the box for 'Use my Windows user account' and click OK, it checks for network requirements, then prompts for credentials again, and at no stage does anything get logged in the NPS event log.

Consequently if you create an NPS policy and list each as seperate conditions it can never match, as the user will never be in the "Meraki Staff Group" AND the "Meraki Computer Group" at the same time.

Next you said there was a big delay when you had this configuration. This is another seperate problem. Is the CA certificate that issued the certificate being used for the PEAP authentication in NPS trusted by the clients as a root authority? Also this certificate can not be self-signed.

3a8082e126