Skip to main content

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

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.


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.


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


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 


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.


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


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


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.


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!
 


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!
 


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


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


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


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.


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.


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.


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


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


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


No issues here anymore all working perfectly 


How are you binding? Config Profile?


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


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


How are you binding? Config Profile?


We use a Policy


How are you binding? Config Profile?


We bind with the ad binding part of jamf no issues 


Reply