@jgarland I was able to get this to work! Take a look at my reply above in this same thread. Let's give this another shot using LDAPS over port 636 and see if we can't confirm that this is working well before the upcoming cutoff in July. I'll be testing out our standard policy and profile workflows soon as well to ensure we get the same results. If you run into issues please reach out to Support!

Benjamin Julian
Senior Technical Support Engineer
Jamf Technical Support
Support Portal - https://support.jamf.com/
Knowledge Base and Resources - https://docs.jamf.com/technical-articles/
Support Line: 844-411-5263

That's awesome Ben. One question, does our JAMF Pro Server need to be specifically configured to use LDAPS and does this include JamfCloud - which we use?

Ben, while testing, what value did the PacRequestorEnforcement registry key have?

We are currently on port 636 for our ldap server. Still no go.

OK, so after digging a little deeper into settings and talking with our security I have been able to establish that we already use LDAPS to bind via port 636, so those were the conditions under which we were getting the error.
However I also discovered that apparently our AD security level had to be reverted to level 1 as level 2 was causing an issue with our Microsoft Identity Manager system that creates account for staff and students. So until they have resolved that issue, we will be staying at level 1, which will enable me to update all our Macs and get them bound automatically again.
But I will not be able to test any fixes until it goes back to level 2.

Hello again everyone! 👋

Just a quick update for you. Thanks to user @hlans question above, I double-checked my work and soon discovered what you all had already reported: the default behavior at this time for the PacRequestorEnforcement key is one (1) when it is not actually set in the Registry. In order to fully test this, we must add that key and set it to two (2) in order to align with what will be configured during the enforcement phase. After doing that, I can confirm in my own limited testing that I'm getting the same results. I have gone ahead and filed a new internal known issue regarding this in order for us to track the impact and severity, and so that we can get eyes on this change in behavior. I would encourage anyone on this thread to reach out Support to let us know if you too are impacted by this change. Thank you so much for bringing this to our attention well before the upcoming July cutoff!

Benjamin Julian
Senior Technical Support Engineer
Jamf Technical Support
Support Portal - https://support.jamf.com/
Knowledge Base and Resources - https://docs.jamf.com/technical-articles/
Support Line: 844-411-5263

@AlanSmith Nope! With macOS's built-in API's/processes, if we are leveraging LDAPS and enforcing LDAP signing, the Mac will know to switch to 636 of its own accord. That is done via GPO and ensuring a valid LDAPS TLS cert is in place on the DC in the AD DS personal certificate store, which based on your other reply is all good to go.

For the people that experienced this issue, how did the already AD bound Macs react to the PacRequestorEnforcement on 2? Did the bind stay intact?

Yes, fortunately the bind is working properly on those macs that were bound prior to the upgrade from Microsoft.

Yes, can confirm that previously bound Macs continue to work fine after the increase to level 2.
Also if the level gets reduced to 1 again and you then bind Macs successfully, they too continue to work fine when it is reverted back to level 2.

Hello Gyus,

did anyone found a solution for this issue? 

Lacose - it is still in process.  The issue resides with Microsoft who has told us there is a "hotfix" coming in mid March.  I will update this thread if after testing it works. Fingers crossed.

Great thanks for the update, sadly we are still forced to use AD binding so we are a bit nervous!

We are as well, Lacose.  Macs that were bound prior to the change in the PACrequestfile change are working properly and we are using a "workaround" till this issue is resolved. It is also time to start looking at alternatives with Macs.

Just hoping for some progress on this as it could loosely be called 'mid March' now!

They haven't released the hotfix yet. Here is the last schedule MS gave us. It depends on the OS version of the domain controllers:

WIN11, WS2022, WS2019 – 3C (3rd week of March) 

WS2016, WS2012R2, WS2012, WS2008R2, WS2008 SP2 – 4B (2nd week of April)

MDMMAN is correct!

Sounds Great! Can you share the KB numbers when they released it ? Would be great thank you!

Hello @MDMMan and @jgarland , can either of you confirm if that patch is out yet for the 3rd week OS now that we're in the 4th week of march?

We are still not seeing the hotfix and have not heard a response from Microsoft yet. 

Looks like the first round of "hot fixes" from Microsoft is in. There is another set due in mid April,2022.

A couple weeks ago I built an isolated environment with a Windows Server 2019 domain controller and a Mac running Big Sur. I can confirm that, with a big sigh of relief, that these new hotfixes do indeed fix the problem when the PacRequestorEnforcement key is set to 2 (enforced) -- the Mac can join the domain, whereas prior to the patch it couldn't.

Glad to hear it worked in a test environment! We will be testing in our Test Environment later this week on Friday, 3-25-2022.

Thanks for sharing! Great to hear.

Hi Jgarland,

Have you heard any updates from Microsoft about that "hotfix"? I noticed that the they updated their article about CVE-2021-42287 and they pushed back their enforcement until October 11, 2022.