802.1x authentication broken since the may 2022 Windows Server security updates

[Loic]

Hello everyone

My context: wi-fi authentication based on 802.1x through a Windows Server (NPS). Computer certificates are deployed by Jamf (Configuraton Profile) and through the Jamf ADCS connector.

Macs are not bound to the Windows domain but a computer object is created for every laptop (it's mandatory with a NPS server).

Everything is working as intended.

As you may know, in may 2022 Microsoft published an important security update that changes the way certificates are validated by domain controlers.

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

A new extension identified by the OID "1.3.6.1.4.1.311.25.2" is now included in certificate templates, but only for the ones that build the subject information from Active Directory.

Unfortunately, certificates issued through the Jamf connector are "offline", meaning that the subject information (CN, DNS name) are supplied in the request (the settings come from Configuration Profile). And Microsoft has not updated this template (yet?). I guess that Jamf will have to modify the Configuration Profile options as well.

As soon as you update your Domain Controlers, Macs are no more able to connect to the wi-fi because their certificates do not include the OID "1.3.6.1.4.1.311.25.2" (and values based on computer object SID).

How do you deal with this restriction, please ?

Do you manually map certificates to object in AD (as referenced in the MS link above) ?

I do not want to bypass the security by tweaking the registry and placing domain controlers in Disabled mode (this option will be removed on February 14, 2023)

I'm stuck at the moment and I'm searching the best solution to keep the automation (certificates deployment) as easy as it is currently.

Best

[BookMac]

What is the error message when you try Connect to the Wi-Fi?

[Loic]

Hello

There's no error message. The connection can't be established

In the NPS server logs, the connection is rejected:
 - Reason-Code : IAS_NO_SUCH_DOMAIN
 - Packet-Type : Access-Reject

[AJPinto]

It sounds like you already know the answer. Microsoft changed something that Apple nor JAMF have any control over and stuff broke. Honesty, I bet you are right that template needs to be updated by Microsoft or you need to update your radius authentication policies.

You may need to contact Microsoft on this and deal with their miserable support process.

[jguz]

Just bumping this up, to see if anyone else has come up with anything. In the same situation as OP except, i have installed the workarounds as I believe that's better than having unpatched DC's. 

[Loic]

Hi @jguz 

I installed the Microsoft patches on all DCs and I'm using a PS script to import the certificate data into the computer objects. All is working well now.

However, I'm still getting event 39 in the DC logs and I can't figure out why... 🤔

[jguz]

Yeah that's the compatibility mode, error code:

No strong mapping (event ID 39) – The certificate has not been mapped explicitly to a domain account, and the certificate did not include the new SID extension.

So I believe you're going to run into issues when full enforcement mode is forced next year. 

[dowens813211]

Would you mind sharing the PS Script you are using ? 

[user-frHfOGKQpA]

Also would like to bump this issue. Did you guys find any solution do this?

Manually mapping the certificate (as mentioned by MS) does work but is not really an option for us, considering the device number and the fact that certificate serial is changing when cert is reissued....

[Thrawnium06]

Has anyone found a solution for this?

[CourtKPrin]

We recently started using EAP-TLS user auth for our Mac and noticed event 39 on the domain controllers. We too use Jamf's connector to deploy the user certs and noticed the certs are missing the expected OID. From what I'm reading, this is the situation with "offline templates". Does Jamf Support have any documentation on this issue when using their connector?

[wsmits]

I have been successful in our test environment by adding the SID from Entra as an Extension attribute and then adding that to the certificate request.

[CourtKPrin]

I'm not familiar with that Input Type menu, where is it in the config profile? Are your Macs joined to the domain? Ours are not.

[wsmits]

Our macs are not bound to the domain.

That input type is in an Extension attribute looking up the On-premises security identifier from Entra.

[KFields]

So you have Entra set up as a cloud identity provider? We are still in a hybrid environment only have LDAP integration enabled.

[wsmits]

Yes, we are using Entra, you could try replacing the "onPremisesSecurityIdentifier " attribute in the extension attribute with the local AD attribute "SID" and try to see it is able to obtain the value.

 https://blog.darrenjrobinson.com/joining-identities-between-active-directory-and-azure-active-direct...