802.1x authentication broken since the may 2022 Windows Server security updates
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.
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
Page 1 / 1
What is the error message when you try Connect to the Wi-Fi?
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
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.
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.
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.
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... 🤔 🤔
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... 🤔 🤔
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.
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....
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... 🤔 🤔
Would you mind sharing the PS Script you are using ?
Has anyone found a solution for this?
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?
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.
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.
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.
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.
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.
So you have Entra set up as a cloud identity provider? We are still in a hybrid environment only have LDAP integration enabled.
So you have Entra set up as a cloud identity provider? We are still in a hybrid environment only have LDAP integration enabled.
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.
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.
Similar to CourtKPrin's question, where is the second image taken from? I'm assuming it's from your SCEP settings in your 802.1x profile stack but mine looks nothing like yours.
This article explains how to update certificate settings in computer or mobile device configuration profiles to comply with Microsoft's Active Directory strong certificate mapping requirements. These requirements must be met to validate certificates during certificate-based authentication to an Active Directory domain.
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.
Where in Jamf is this screen shot taken from? We dont have the option in any of our instances to add additional SANS like this.
This article explains how to update certificate settings in computer or mobile device configuration profiles to comply with Microsoft's Active Directory strong certificate mapping requirements. These requirements must be met to validate certificates during certificate-based authentication to an Active Directory domain.
Thank you for linking this article. Not sure when Jamf published it, but I've been waiting for Jamf to respond to this issue.
We are unbound Macs that use the Jamf ADCS Connector with the on-prem AD to push user certs for EAP-TLS authentication with the WiFi.
we have ADCS connector in place and certificate authentication were failing as well.
we resolved it by adding a registry key on the DCs ( StrongCertificateBindingEnforcement) under the HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Services\\Kdc subkey ( value 1 for compatibility) while we wait for JAMF to put a more 'user friendly' option.
@a_stonham it is in the certificate settings of the configuration profile once you have AD CS and a Certification Authority certification template configured. Here is a more complete look at the section.
I was able to get it working like this but only after manually name mapping certificates and enabling compatibility mode with the DC reg key like @SutharsanK mentioned.
It is working right now but the logged in user is still prompted to provide credentials for eapolclient. Does anyone know how to fix that with JAMF?
Hello guys, i am also affected by the MS latest security patch Microsoft Active Directory Strong Certificate Mapping Requirements. My devices cant connect to wifi via certificates after the latest patch. My devices are not in domain, also users are local , so when i tried the objectsid Extension attribute it didnt work even though i have cloud idp as azure connected and i guess its because users are local. Do anyone have any idea how to tackle this :)
Hello guys, i am also affected by the MS latest security patch Microsoft Active Directory Strong Certificate Mapping Requirements. My devices cant connect to wifi via certificates after the latest patch. My devices are not in domain, also users are local , so when i tried the objectsid Extension attribute it didnt work even though i have cloud idp as azure connected and i guess its because users are local. Do anyone have any idea how to tackle this :)
Honestly, its time to open a new topic for this. However, I have seen similar issues and even experienced them. In short NPS is not really enterprise grade anymore, and has no real way to map certificates to non-domain bound devices that do not require a ton of scripting and manual interaction from the engineering side. You could lower you policy posture to have a single certificate for all macs and that should work, but machine level certificates will have problems if your macs are not domain bound and Macs should not be domain bound.
Basically this turns in to the right tool for the job, NPS works fine for Domain Bound Windows devices, but you are dealing with Macs and need the right tool for this job.
