Hello, are you able to manually add it to the domain?

No I have tried through the JAMF policy and manually with the same error message

Are you using the same service account credentials to attempt the AD bind in both cases (from the Jamf policy and manually?) If so, then it sounds like an issue with the account. If it doesn't have permissions to join the Mac or perhaps to join the Mac to an existing computer account in AD (if the device had already previously been joined), then it will fail. Although I don't know if it gives that exact error message you're seeing.

I have tried with multiple accounts that have permissions to add machines to the domain. 

OK got it. So what OS is this Mac or Macs on that's giving you this error?

I have tested machines on Monterey and Big Sur

We've started seeing this over the past couple of days too. Both on Big Sur and Monterey.

We don't bind new devices anymore, but still have many that are still bound (in the process of migrating to Jamf Connect).
When those that are still bound inevitably end up with password sync issues, I often find I have to re-bind the device and re-connect Enterprise Connect to get the passwords synced up correctly.

Yesterday I had a remote user with the 5103 error when we attempted a re-bind. 2017 MBP on 11.6.0
I tried switching to a different GlobalProtect VPN gateway and re-running the bind policy, it worked!
What's strange is that we know the other VPN gateway has previously worked just fine with AD binding.

We've also started seeing issues with brand new M1 Pro MacBook Pro's connecting to our 802.1x protected WiFi network. Not sure if it's related, going to speak to the network guys soon.
Neither of these issues existed before the holidays.

We started seeing this issue yesterday as well.

FYI on what I found so far.

I found the following thread in the #activedirectory channel on MacAdmins Slack:
https://macadmins.slack.com/archives/C0AEV1BLP/p1638334080097300

It appears to be related to some recent security changes made by Microsoft:

https://support.microsoft.com/en-us/topic/kb5008380-authentication-updates-cve-2021-42287-9dafac11-e0d0-4cb8-959a-143bd0201041

Our directory services team had me try adding:

to the typical dsconfigad command that I use to bind, but that did not seem to help.  I also tried 

but that did not work either.

Thank you for the info! I am still getting the error on both vpn gateways we have. This issue started over the holidays for us too 

Thank you for the info! This problem seemed to have came up over the holidays. Trying to get a hold of the domain controller logs to see what needs to be changed to get through. 

Following this thread. Same issues.

I also have the same issues. Has anyone come up with a solution yet?

We sent tickets into Apple and Microsoft.  This is a known Apple Issue according to my Apple Support Engineer.

They are working to find a solution.  If experiencing this issue please file tickets with Apple Support (EDU) and with Microsoft.

Further information from Apple revealed that the actual setting has to occur on the Microsoft side. Referencing this KB.https://support.microsoft.com/en-gb/topic/kb5008380-authentication-updates-cve-2021-42287-9dafac11-e0d0-4cb8-959a-143bd0201041

Not sure, what 'setting' Apple are referring to, it looks like MS are tightening up security on their side, so I would have thought Apple need to do the same to comply!

Yes @jgarland  I confirmed with our windows server admin this morning that Enforcement Mode was turned on and PacRequestorEnforcement is the setting that is stopping the join requests to go through! Our ticket with Microsoft and Apple are still open so more updates to follow!

Yes, I had a conversation with our security guy yesterday.
We have ours set to Enforcement level 2, hence ours not binding.
We are going to do a small test and see if changing it to Enforcement level 1 will allow us to bind to AD, and then revert it back to Level 2 and check that everything still functions.
Our Macs that are already bound don't appear to have any issues with it Level 2. 
The problem is I need to re-image/update the whole site before classes start in approx 4 weeks.
Without AD binding it won't be happening!

Our AD admins temporarily set the pacrequestorenforcement registry key to 1 and AD binding is working for us again.  

However, they don't like leaving at that setting since it is less secure so they are still working with Microsoft to try some other things.

Not to mention it sounds like Microsoft is removing the pacrequestorenforcement key and defaulting to the most secure mode in July.

Yep! @spalmer you are correct.  Our Infrastructure Team will not go back as it allows vulnerabilities - and within a large school district it is really up to Apple to come out with an update to the OS to resolve the issue. We are pressing on Apple to work towards a solution - however, that may be slow in coming and July is fast approaching.

Any one got any further responses to this? Currently I am having to get our Network Security guy to set the registry key to level 1 - I then bind the Macs - then he rested the level back to 2. The process only takes about 10-15 mins if that.
If there is any other fix that doesn't involve me having to ask him to do this, I'd love to know.

Not at this time - this is still an issue and escalated on both sides Apple Ticket and Microsoft Ticket. Just checked on it today and it resides with Microsoft right now.  Anyone up for a game of tennis? :)

Hey everyone! :👋

Ben from Jamf Support here. For those following this thread, I'm curious if you are seeing the same error when binding Macs using LDAPS. For anyone who is testing this, can you please let us know if the behavior persists when using port 636 for bindings to the domain controllers? Any difference in using a policy versus a configuration profile?

Thanks!

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

Thanks Ben for joining the discussion. 
We only bind using a policy and to be honest, I set up the policy a few years ago and would have to start from scratch to remember how to do it again, so I'm not sure I can answer any of your questions, but would be definitely interested in hearing from others.
Has anyone at JAMF tried to replicate the issue?

Hi Ben :)

We have not tried a config profile but not sure that would change anything? since it's the dsconfig command that is failing.  We have not tried the port either.

@AlanSmith Yes, that would be me! I successfully updated my DC with the standalone update from Microsoft today and confirmed it was installed. I then did a test bind without Jamf Pro in the mix using `dsconfigad` and was able to successfully bind my Mac to the domain. I will be testing our policy and profile workflows next to ensure I get the same results. I only tested with LDAPS enabled as binding over 389 was deprecated/moved to unsupported by Microsoft back in 2020. I'd encourage you to test again using LDAPS with port 636 to see if you get better results. If you continue to have issues please reach out and file a new ticket with Support so we can assist! Thanks!

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