Unable to add Server. Authentication server failed to complete the requested operation. (5103)

[cnixon14]

I have a policy that joins a computer to the domain automatically when it is enrolled. This policy worked up until today and now I am receiving the same error message on all new Macs. I searched the error code and it says that 5103 usually means that the hostname is too long for AD but our hostnames are all 10 characters long... Has anyone run into this issue before? We tested windows machines and they work fine so I am not sure if this issue is from the AD server side or MacOS. Here is the error message.

 

Thank you to anyone with suggestions

[JG3741]

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

[cnixon14]

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

[mm2270]

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.

[cnixon14]

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

[mm2270]

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

[cnixon14]

I have tested machines on Monterey and Big Sur

[tfenna]

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.

[cnixon14]

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 

[spalmer]

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-e...

Our directory services team had me try adding:

-packetencrypt require -packetsign require

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

-packetencrypt ssl -packetsign require

but that did not work either.

[cnixon14]

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. 

[jgarland]

Following this thread. Same issues.

[Andixon]

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

[jgarland]

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.

[jgarland]

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-e...

[AlanSmith]

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!

[cnixon14]

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!

[AlanSmith]

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!

[spalmer]

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.

[jgarland]

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.

[AlanSmith]

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.

[jgarland]

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? :)

[ben_julian]

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

[AlanSmith]

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?

[ben_julian]

@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

[AlanSmith]

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_julian]

@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.

[AlanSmith]

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.

[jgarland]

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.

[ben_julian]

@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

[jgarland]

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

[hlans]

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

[ben_julian]

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

[hlans]

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?

[jgarland]

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

[AlanSmith]

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.

[Lacose]

Hello Gyus,

did anyone found a solution for this issue? 

[jgarland]

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.

[Lacose]

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

[jgarland]

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.