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

cnixon14
New Contributor III

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.

 Image from iOS (1).jpg

Thank you to anyone with suggestions

69 REPLIES 69

JG3741
New Contributor III

Hey folks, just curious to ask if anyone who has tested the hotfix on their domain controllers are running Windows Server 2019?

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

MDMMan
New Contributor III

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)

jgarland
New Contributor III

MDMMAN is correct!

Lacose
New Contributor II

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?

MDMMan
New Contributor III

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

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.

jgarland
New Contributor III

Read below - I posted our status further down in the community thread.

jgarland
New Contributor III

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

WS2019 - KB5011551 https://support.microsoft.com/en-gb/topic/march-22-2022-kb5011551-os-build-17763-2746-preview-690a59...

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

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

 

cwwirth
New Contributor III

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.

jgarland
New Contributor III

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.

vagabon
New Contributor III

Thanks for sharing! Great to hear.

jgarland
New Contributor III

After performing testing in our test environment, unfortunatly the hot fix had issues with installing on the DC.  Our Infrastructure team is taking the logs and errors back to Microsoft for evaluation and next steps. At this time, no still no fix for AD Bind.

Lacose
New Contributor II

We tested it on our 2022 Dcs, we instaledl it on all 3 dcs we still cant bind the mac to the AD if its a completly new one (no ad objekt) if i create an object manually i can bind it with all enforcements enabled 

JG3741
New Contributor III

Hello folks, just curious to ask if anyone tried applying the hot fixes onto their domain controllers running 2019 Windows Server ?

BBanner
New Contributor

I didn't see this mentioned anywhere here but I ran into this issue and for me, the problem was actually DNS.  The only way I was pointed into the right direction, was I checked the network setting on the Mac, and noticed that the WINS NetBIOS name was coming up incorrect from what the computer name of the Mac should be.

It turns out, that while on the VPN, the IP assigned previously belonged to another Windows device, and was still in the Windows DNS.  The Mac and/or VPN see the name associated with DNS and attempt to use that instead of the actual computer name of the Mac.  Since this name already belongs to a Windows device in AD, the join fails.

To fix this, I simply deleted the DNS entries on my Windows Domain Controller associated with the IP that the Mac was getting.  After a reboot, the Mac was then no longer getting an incorrect name for WINS on the network page.  The bind then worked.

MathiasO
New Contributor II

Hey Guys, some more Informations here?
Is there a new Hotfix from Microsoft? Did someone could test it?

Still gotta set the RegKey with Serveradmins and it is still anoying.
Thanks!
 

nssabol
New Contributor II

Hello Mathias and All - in my testing, it appears the 2022-04 Microsoft Updates for Windows Server resolve the issue across versions. At least for Domain Controllers running Server 2016. After installing the OS-appropriate update (list) below and setting PacRequestorEnforcement = 2 on Domain Controllers, macOS devices can bind to and authenticate against Active Directory. Prior to installing these updates, I was able to reproduce the bind issue that started this thread.

Sort of looking for a sanity check too - are others having the same experience?

Thank you all - excellent post and replies!

Best,

-Neil

jgarland
New Contributor III

Jeffco is testing this morning - I will post results here.

jgarland
New Contributor III

We were able to test in our test environment - the AD Bind and it is working in TEST.

The April patches seem to be working for us.  I will post again once those patches have been applied to the Production Environment.

AlanSmith
Contributor

I do not have access to a test AD environment and am not privy to what in any patches have been applied to our Production AD server, however I do know that actual hardware server was moved from one location to another over Easter weekend and so has been restarted recently.
Last Friday 22 April I was able to bind, via policy, a new M1 iMac running Monterey. Then today I was able to bind an Intel iMac running Catalina without any changes in security to our AD.

I am fairly certain we are running a Windows 2019 server for our AD. I will confirm and edit accordingly once I know!


Edit: Confirmation, we are running one Windows 2016 and two Windows 2019 Servers for our on site AD instances and yes, they have had all recent patches and as such we can now bind automatically with the RegKey set to 2 - highest security setting.

jgarland
New Contributor III

Hi AlanSmith -

Some considerations here - your server may not have been hardened yet by Microsoft updates - the actual change is due to happen mid July and with that if the April patches are applied to your server prior to July you might never see the issue.

jgarland
New Contributor III

Using the above KB articles - and applying the April Microsoft patches - resolved the issue with being unable to bind in our environment.

lmrosbro
New Contributor III

Is this still an issue for folks? We are past the enforcement phase and we can still bind our Macs. 

Lacose
New Contributor II

No issues here anymore all working perfectly 

Yeah, as per the edit on my post above. Everything seems to be back to a working state as far binding is concerned!

lmrosbro
New Contributor III

How are you binding? Config Profile?

We use a Policy

Lacose
New Contributor II

We bind with the ad binding part of jamf no issues