Skip to main content

I am using deploystudio to enroll images to mac, where I also within a script bind the mac to AD.

It works as it should, and I can logon to any mac with any AD user after enrolling an image

But quite often I see mac´s suddenly are not bind to AD anymore. Typically I find the issue, when user try to change password, and that the login password to the mac can not be changed. It is not all mac users it happens for, but some more then other.

I can see the computer object still are in the AD, so it is not because the computer has been removed from the AD. If I un-bind the AD on the Mac - then delete the computer name in AD - and afterwards bind the mac to AD again it works. Sometimes for months, other time maybe some weeks - it is difficult to say specific, as it is mainly when user change AD password every 3 month, the issue pop up

But what is the best way to troubleshoot, if this is a client issue - or AD for some reason just cut the trust relationship with the mac ?.

@rossoneris What are you setting the password change interval to in your AD bind script? You may want to change it to 0 (default is 14).

@StoneMagnet

Is there a way to do this after the devices are bound?

--
TJ

@tthurman sudo dsconfigad -passinterval 0 should do the trick as long as the AD bind is still working

dsconfigad -passinterval 0 after binding, else it will default back to 14 days.

We use config profiles to do the binding for us. This allows us to restrict the computer from the profile (removing it) and then remove the restriction which then performs the rebinding. This should take care of any trust relationship issue (unlike Windows machines, there is not a nice little error message indicating the relationship is broken) and may fix any client issue.

We also don't remove the AD object and just let it re-establish the relationship unless it lives in the tree in a spot that the account we use doesn't have permission.

If the password is broken on the client, I'm not entirely sure rebinding will fix the password issue. Our AD credentials are handled through a web interface that feeds AD so our PW situation may not be the same as yours.

Can see I actually wrote wrong information, regarding it is a script. The AD binding is done in a workflow in deploystudio, when image is installed to mac. I can see the password change interval is set to 360 days in there

But I can not understand why local password rules regarding password change should have influence ? - The AD users have to change password every 90 days according to AD policy - so how can local password rules influence that ?

@rossoneris The -passinterval option is for the machine account, not the user account, and your AD users password policy doesn't apply to it. In theory as long as your Macs check in with AD within the specified interval your binding will remain in effect, but in reality that does not seem to be the case. Setting the interval to 0 so the machine password never expires will greatly reduce the instances of broken trust between your Macs and AD.

We solved some of our AD binding issues by pointing all the macs to our domain controllers instead of apple time for NTP using the commands below in a script. We also use these commands in a script that is made part of a payload free package with a priority of 2. For some reason that makes it run during imaging right before the directory binding in the configuration (it's possible this was a bug and has been/will be fixed). Even after doing all this though we still have issues occassionally :)

Commands to set time server to local DC
systemsetup -setusingnetworktime on
systemsetup -setnetworktimeserver "domainname.local"
ntpdate -u "domainname.local"

Check accuracy of time on domain controllers

We also discovered a few domain controllers that had bad NTP settings and weren't keeping in sync with all the other DCs and would cause intermittent issues.

If you run "w32tm /monitor" from a windows computer it will show you the offset from all domain controllers versus the primary domain controller. That should be able to be run on any domain computer without needing any special rights.

@sbuccola Or just add an entry to your DNS that maps time.apple.com to your internal time server. Extra useful when your network management team blocks external NTP as it works for iOS devices which can't be re-directed to a different network time server.

As I can hear it sounds like a common issue on mac that the binding dissapear. For me it is also by far not all mac´s that lose the connection.
Just thinking if it was a common system setup issue, it would hit all mac´s at one point - but it does not

Is there any way to enable logging for ad bind, to find the reason behind - if the log somehow would give an error code etc? or to run somehow a daily task to very ad bind is OK on a mac, so I know when the bind is lost so I can check logs etc.

Is there any "quick" fix to get the ad bind running again, without having to remove domain and add domain again, as users cannot delete the computer object from AD on their own, before a Bind can be done again

Terms & ConditionsCookie settingsAccessibility statement