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

Loic
New Contributor III

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

9 REPLIES 9

BookMac
Contributor

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

Loic
New Contributor III

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
Honored Contributor II

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
New Contributor III

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
New Contributor III

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
New Contributor III

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. 

Would you mind sharing the PS Script you are using ? 

user-frHfOGKQpA
New Contributor

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
New Contributor II

Has anyone found a solution for this?