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