Skip to main content
Question

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


Show first post

69 replies

ben_julian
Forum|alt.badge.img+8
  • Employee
  • 20 replies
  • January 27, 2022
jgarland wrote:

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.


@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


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

@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


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?

 


Forum|alt.badge.img+3
  • New Contributor
  • 8 replies
  • January 28, 2022

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


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

@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


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


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

@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


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.


ben_julian
Forum|alt.badge.img+8
  • Employee
  • 20 replies
  • January 28, 2022

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


ben_julian
Forum|alt.badge.img+8
  • Employee
  • 20 replies
  • January 28, 2022
AlanSmith wrote:

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?

 


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


Forum|alt.badge.img+3
  • New Contributor
  • 8 replies
  • January 31, 2022

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?


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

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.


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

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


Forum|alt.badge.img+3
  • New Contributor
  • 6 replies
  • March 9, 2022

Hello Gyus,

 

did anyone found a solution for this issue? 


Forum|alt.badge.img+7
  • Contributor
  • 28 replies
  • March 9, 2022
Lacose wrote:

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.


Forum|alt.badge.img+3
  • New Contributor
  • 6 replies
  • March 9, 2022
jgarland wrote:

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!


Forum|alt.badge.img+7
  • Contributor
  • 28 replies
  • March 9, 2022
Lacose wrote:

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.


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

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.


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


Forum|alt.badge.img+5
  • Contributor
  • 15 replies
  • March 16, 2022
AlanSmith wrote:

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)


Forum|alt.badge.img+7
  • Contributor
  • 28 replies
  • March 16, 2022
MDMMan wrote:

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!


Forum|alt.badge.img+3
  • New Contributor
  • 6 replies
  • March 18, 2022
MDMMan wrote:

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)


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


chlaird
Forum|alt.badge.img+7
  • Contributor
  • 67 replies
  • March 22, 2022
MDMMan wrote:

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)


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?


Forum|alt.badge.img+5
  • Contributor
  • 15 replies
  • March 22, 2022
chlaird wrote:

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. 


Forum|alt.badge.img+7
  • Contributor
  • 28 replies
  • March 23, 2022

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

 

 

Microsoft has released the first set of patches which customers can confirm with Microsoft if they are applicable for their deployment:
In the patch notes the following can be found:
"Addresses an issue that logs Event ID 37 during certain password change scenarios, including failover cluster name object (CNO) or virtual computer object (VCO) password" changes.

WS2022 – KB5011558 https://support.microsoft.com/en-us/topic/march-22-2022-kb5011558-os-build-20348-617-preview-8bb6ded6-7515-44eb-9fa0-e214eb6d7a75

WS2019 - KB5011551 https://support.microsoft.com/en-gb/topic/march-22-2022-kb5011551-os-build-17763-2746-preview-690a59cd-059e-40f4-87e8-e9139cc65de4

WIN11 - KB5011563 https://blogs.windows.com/windows-insider/2022/03/15/releasing-windows-11-build-22000-588-to-beta-and-release-preview-channels/

We still expect the other patches to ship in week two of April.
WS2016, WS2012R2, WS2012, WS2008R2, WS2008 SP2 – 4B (2nd week of April)

Microsoft has also updated the above KB article with a known issues section and suggests the workaround below:

"Microsoft is investigating this issue. In the meantime, temporarily avoid setting PacRequestorEnforcement = 2 on affected environments."

 

Forum|alt.badge.img+4
  • Contributor
  • 12 replies
  • March 23, 2022
jgarland wrote:

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

 

 

Microsoft has released the first set of patches which customers can confirm with Microsoft if they are applicable for their deployment:
In the patch notes the following can be found:
"Addresses an issue that logs Event ID 37 during certain password change scenarios, including failover cluster name object (CNO) or virtual computer object (VCO) password" changes.

WS2022 – KB5011558 https://support.microsoft.com/en-us/topic/march-22-2022-kb5011558-os-build-20348-617-preview-8bb6ded6-7515-44eb-9fa0-e214eb6d7a75

WS2019 - KB5011551 https://support.microsoft.com/en-gb/topic/march-22-2022-kb5011551-os-build-17763-2746-preview-690a59cd-059e-40f4-87e8-e9139cc65de4

WIN11 - KB5011563 https://blogs.windows.com/windows-insider/2022/03/15/releasing-windows-11-build-22000-588-to-beta-and-release-preview-channels/

We still expect the other patches to ship in week two of April.
WS2016, WS2012R2, WS2012, WS2008R2, WS2008 SP2 – 4B (2nd week of April)

Microsoft has also updated the above KB article with a known issues section and suggests the workaround below:

"Microsoft is investigating this issue. In the meantime, temporarily avoid setting PacRequestorEnforcement = 2 on affected environments."

 

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.


Forum|alt.badge.img+7
  • Contributor
  • 28 replies
  • March 23, 2022
cwwirth wrote:

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.


Forum|alt.badge.img+4
  • New Contributor
  • 14 replies
  • March 25, 2022
jgarland wrote:

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

 

 

Microsoft has released the first set of patches which customers can confirm with Microsoft if they are applicable for their deployment:
In the patch notes the following can be found:
"Addresses an issue that logs Event ID 37 during certain password change scenarios, including failover cluster name object (CNO) or virtual computer object (VCO) password" changes.

WS2022 – KB5011558 https://support.microsoft.com/en-us/topic/march-22-2022-kb5011558-os-build-20348-617-preview-8bb6ded6-7515-44eb-9fa0-e214eb6d7a75

WS2019 - KB5011551 https://support.microsoft.com/en-gb/topic/march-22-2022-kb5011551-os-build-17763-2746-preview-690a59cd-059e-40f4-87e8-e9139cc65de4

WIN11 - KB5011563 https://blogs.windows.com/windows-insider/2022/03/15/releasing-windows-11-build-22000-588-to-beta-and-release-preview-channels/

We still expect the other patches to ship in week two of April.
WS2016, WS2012R2, WS2012, WS2008R2, WS2008 SP2 – 4B (2nd week of April)

Microsoft has also updated the above KB article with a known issues section and suggests the workaround below:

"Microsoft is investigating this issue. In the meantime, temporarily avoid setting PacRequestorEnforcement = 2 on affected environments."

 

Thanks for sharing! Great to hear.


Forum|alt.badge.img+3
  • New Contributor
  • 9 replies
  • March 29, 2022
jgarland wrote:

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.


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.


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