Posted on 10-04-2022 04:43 AM
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
Posted on 10-05-2022 12:30 AM
What is the error message when you try Connect to the Wi-Fi?
Posted on 10-05-2022 03:16 AM
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
Posted on 10-05-2022 05:08 AM
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.
Posted on 12-01-2022 06:13 AM
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.
Posted on 12-02-2022 09:18 AM
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... 🤔
Posted on 12-06-2022 06:22 AM
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.
Posted on 02-22-2023 04:06 PM
Would you mind sharing the PS Script you are using ?
Posted on 02-21-2023 07:57 AM
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....
Posted on 02-05-2024 02:08 AM
Has anyone found a solution for this?