Skip to main content
Question

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


Forum|alt.badge.img+6

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

69 replies

Forum|alt.badge.img+7
  • Contributor
  • 22 replies
  • January 5, 2022

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


Forum|alt.badge.img+6
  • Author
  • Contributor
  • 23 replies
  • January 5, 2022
JG3741 wrote:

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


mm2270
Forum|alt.badge.img+16
  • Legendary Contributor
  • 7880 replies
  • January 5, 2022
cnixon14 wrote:

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.


Forum|alt.badge.img+6
  • Author
  • Contributor
  • 23 replies
  • January 5, 2022
mm2270 wrote:

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. 


mm2270
Forum|alt.badge.img+16
  • Legendary Contributor
  • 7880 replies
  • January 5, 2022
cnixon14 wrote:

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?


Forum|alt.badge.img+6
  • Author
  • Contributor
  • 23 replies
  • January 5, 2022
mm2270 wrote:

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


tfenna
Forum|alt.badge.img+4
  • New Contributor
  • 5 replies
  • January 6, 2022
mm2270 wrote:

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


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.


spalmer
Forum|alt.badge.img+22
  • Valued Contributor
  • 166 replies
  • January 6, 2022

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:

 

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


Forum|alt.badge.img+6
  • Author
  • Contributor
  • 23 replies
  • January 6, 2022
tfenna wrote:

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.


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 


Forum|alt.badge.img+6
  • Author
  • Contributor
  • 23 replies
  • January 6, 2022
spalmer wrote:

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:

 

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


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. 


Forum|alt.badge.img+7
  • Contributor
  • 28 replies
  • January 6, 2022

Following this thread. Same issues.


Forum|alt.badge.img+8
  • Contributor
  • 39 replies
  • January 11, 2022

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


Forum|alt.badge.img+7
  • Contributor
  • 28 replies
  • January 11, 2022

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.


Forum|alt.badge.img+7
  • Contributor
  • 28 replies
  • January 11, 2022
jgarland wrote:

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


AlanSmith
Forum|alt.badge.img+8
  • Valued Contributor
  • 53 replies
  • January 11, 2022
jgarland wrote:

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!


Forum|alt.badge.img+6
  • Author
  • Contributor
  • 23 replies
  • January 11, 2022
jgarland wrote:

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


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
Forum|alt.badge.img+8
  • Valued Contributor
  • 53 replies
  • January 11, 2022
cnixon14 wrote:

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!


spalmer
Forum|alt.badge.img+22
  • Valued Contributor
  • 166 replies
  • January 11, 2022

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.


Forum|alt.badge.img+7
  • Contributor
  • 28 replies
  • January 12, 2022
spalmer wrote:

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.


AlanSmith
Forum|alt.badge.img+8
  • Valued Contributor
  • 53 replies
  • January 24, 2022

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.


Forum|alt.badge.img+7
  • Contributor
  • 28 replies
  • January 24, 2022

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
Forum|alt.badge.img+8
  • Employee
  • 20 replies
  • January 27, 2022

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
Forum|alt.badge.img+8
  • Valued Contributor
  • 53 replies
  • January 27, 2022
ben_julian wrote:

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?


Forum|alt.badge.img+7
  • Contributor
  • 28 replies
  • January 27, 2022

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
Forum|alt.badge.img+8
  • Employee
  • 20 replies
  • January 27, 2022
AlanSmith wrote:

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?


@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


Reply


Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings