May 2022 Windows Updates may cause issues with NPS and RRAS

https://docs.microsoft.com/en-us/windows/release-health/status-windows-10-1607-and-windows-server-2016#2826msgdesc

https://support.microsoft.com/en-gb/topic/kb5014754-certificate-based-authentication-changes-on-windows-domain-controllers-ad2c23b0-15d8-4340-a468-4d4f3b188f16

You may find VPN clients fail to authenticate with certificate based authentication after this months updates particularly to domain controllers.

In the long term some additional AD attributes may need to be added and certificates replaced.

i wonder if this is going to break 802.1x Computer based cert Wi-Fi connnections

Will they ever release a WU that doesn't break something.

Reading around the issue it looks like there will be some additional requirements around user and computer certs. But there is a year before enforcement. This means renewing client certificates or adding AD attributes that align with the certificate. This is due to a vulnerability where it is possible to generate a cert for a DC from a Computer Account.

However updating the domain controllers is somehow breaking certificate authentication for 802.1x and/or Always On VPN connections.

Microsoft’s guidance seems to indicate enforcement mode is enabled by default.

Computer-based certificate WiFi connections broken here. Are other people having that? Our machines are falling back to using a PSK-based connection. I'm assuming that it's since the DCs/CA server did the May update, but I'm not 100% certain. Down the rabbithole I go.

Touch wood no issues here (yet) with our computer-based certificate wifi connections after applying the May 2022 updates. Will report here if we get any. Let us know what you find @jthompson

It seems like if you don't have a SAN with the DNS name of the computer. You may incur issues.

https://directaccess.richardhicks.com/2022/05/16/certificate-based-authentication-changes-and-always-on-vpn/

I can't replicate this in testing.

Microsoft's guidance seems to outline the issue.

Do the May updates need to be applied to both client and server or just server?

I could really do with testing this before I apply the May patches to our servers.

I'm not sure that my broken 802.1x computer cert connections is due to the May update. The problems that I'm seeing look to have started earlier in the month, before the May updates were installed. Seeing lots of event ID 21 on DCs.

The client certificate for the user DOMAIN\Computer$ is not valid, and resulted in a failed smartcard logon. Please contact the user for more information about the certificate they're attempting to use for smartcard logon. The chain status was : A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider.

I think something in my env is broken, separately from this May update stuff.

The few computer certificates that our AD-CS server has issued since installing the update do inlcude the new OID that adds the computer SID into the certificate. DCs and clients all have the certificate of the issuing CA in place, and can't see anything as expired or missing anywhere. Am puzzled.

I'm not seeing any of the events 39, 40 or 41 on the DCs, when I'd presumably expect to. They've definitely installed the May updates and restarted. Maybe connections attempts are breaking before it gets to the stage of generating any of those events.

I'm not sure that my broken 802.1x computer cert connections is due to the May update. The problems that I'm seeing look to have started earlier in the month, before the May updates were installed. Seeing lots of event ID 21 on DCs.

 

 

 

I think something in my env is broken, separately from this May update stuff.

 

The few computer certificates that our AD-CS server has issued since installing the update do inlcude the new OID that adds the computer SID into the certificate. DCs and clients all have the certificate of the issuing CA in place, and can't see anything as expired or missing anywhere. Am puzzled.

 

I'm not seeing any of the events 39, 40 or 41 on the DCs, when I'd presumably expect to. They've definitely installed the May updates and restarted. Maybe connections attempts are breaking before it gets to the stage of generating any of those events.

Am just seeing 6272/3 events but I haven't applied the May updates as yet. Are the clients still connecting but you are seeing errors?

My WiFi broke last week because of it, was set to authenticate as Smartcard or other certificate. Had to do a new NPS Rule and a new GPO profile to make it use Microsoft Protected PEP to make it work and go around all my machines and GPUpdate them to use the new config.

Bugger we are on smart card or other certificate but how did you update the wireless machines did you have to plug them in? Not sure I can do that with hundreds of devices?!

I had to plug in 540 devices to get them working.

What I would say is don't apply the update (if you haven't already) deploy out a new profile with PEAP and a new name via group policy and set that up in NPS and then delete the old one after a week. Then catch the straglers after.

No, our clients aren't connecting. Well, they're connecting using an alternative PSK-based SSID that's available, but they're all failing to connect to the 802.1x SSID.

When they attempt to connect and fail, we see the following error on the client, in the Applications and Services\Microsoft\Windows\WLAN-AutoConfig event log.

Event ID 12013:

[some details of SSID, client FQDN, MAC, etc.]

...

Explicit Eap failure received

Error: 0x8009030C

EAP Reason: 0x8009030C

EAP Root cause String: The authentication failed because the user certificate required for this network on this computer is invalid

 

EAP Error: 0x80420101

On the NPS server audit log, it reports a reason code 16 for each failed connection attempt.

That's still the case even if I reissue a fresh certificate for the computer.

Clients and NPS/DC servers all have the CA cert in trusted root authorities. I've checked the server certs selected for the "Smart Card or other certificate" EAP type in the NPS network policy. Nothing is expired.

Not sure what else to check, but I'm fairly sure it's nothing to do with the May updates.

We've done some updates across the UniFi kit recently, too, but the timing of that doesn't appear to correspond with when we started seeing the problem.

I've checked the server certs selected for the "Smart Card or other certificate" EAP type in the NPS network policy. Nothing is expired.

That is likely to be your problem, I had to change it to PEAP and deploy a new wireless profile to get machine certs to work again.

It seems that Smart Card or other certificate is the method affected here, swap to PEAP and then you should be fine, with them falling back to PSK you should be able to push out a new Wireless network Profile and have the machines pick it up.

My WiFi broke last week because of it, was set to authenticate as Smartcard or other certificate. Had to do a new NPS Rule and a new GPO profile to make it use Microsoft Protected PEP to make it work and go around all my machines and GPUpdate them to use the new config.

Just run a test of doing this and it has worked! Thanks for the tip.

In our case, we should be able to deploy this new SSID without needing to run around, as all our clients already had a PSK-based profile deployed to them that they've been falling back on. That's worked out to be a useful contingency as it happens!

Glad to have been of help, I was going crazy last Thursday with it all, I didn't deploy a new SSID, I just deployed a new wireless profile to the same SSID with mofified settings in NPS.

All of my devices, except for the admin machines, are wireless and are laptops, luckily I had 3 year groups using a user based certificate through Endpoint Manager (formally intune) and a chunk were chromebooks with PSK. So I only had 540odd devices to sort out, if it had been pre-covid times with most of my devices as full domain joined windows, then I would have had at least double if not triple the amount to do.

I've installed the May update on the DCs at one site and so far no issues with our RADIUS secured using smartcard or other cert, though I do need to check the logs for the identified events.

Well you are lucky there if you are doing it that way, ours all refused to connect.

Ok, just checked we have the warnings in event viewer.

The Key Distribution Center (KDC) encountered a user certificate that was valid but could not be mapped to a user in a secure way (such as via explicit mapping, key trust mapping, or a SID). Such certificates should either be replaced or mapped directly to the user via explicit mapping. See https://go.microsoft.com/fwlink/?linkid=2189925 to learn more.

i wonder if this is going to break 802.1x Computer based cert Wi-Fi connnections

It caused our Apple and Android clients to ask for cert approval again. No biggie, once approved (and trusted in iPads), it works just fine.

No other side effects noticed in all 3 DCs.

I’ve tried to replicate issues in a test domain. I can’t break VPN connections using cert auth at machine level. This is using the computer template and mostly default NPS settings. So I’m confused for what the big deal is. Though will be waiting for MS to changes the status on windows health to resolved before applying to DCs.

This is how we use AoVPN so that gives some reassurance - though I can re-deploy the certs from the CA easily enough post update.

This is how we use AoVPN so that gives some reassurance - though I can re-deploy the certs from the CA easily enough post update.

My worry is that I have users who never are on site. So cert renewal must work across the VPN that is using the cert. It may be possible to issue manual certs.