Best practice for BINDING a Mac

[mconners]

Hey Everyone,

A quick question for you.

With JAMF Pro, there are a multitudes of methods to bind a Mac to AD. We are currently binding at Casper Imaging time via NetBoot and the first run script, using the accounts tab and selecting the appropriate binding. Just the built in process via Casper Imaging. A person could also bind using a configuration profile. You can also bind using a policy. Others are using scripts.

The question is, does it matter HOW you bind the Mac to AD as long as the computer object is created in AD into the correct OU?

Just curious as we are seeing some strange things happening with our laptops and I wonder if the WAY we are binding could cause a problem or not.

Mick

[alexjdale]

I prefer a scripted method using dsconfigad, personally. We also use Casper binding in one of our workflows as part of a trigger policy. I haven't seen any difference between the two.

The method shouldn't matter as long as the args are the same. What strange things are you talking about?

[mconners]

Thanks @alexjdale with our laptops and after they have been sitting idle, maybe a week, they will lose their connection to AD. However, the object still sits in AD. Open system preferences, we are seeing the connection to AD under Users and Groups. But our secure wireless, which depends on the Mac being bound, will drop off.

Just today, we had Macs that were in AD and the users and groups showed the computer being bound, BUT the JSS showed the computer NOT being bound. These computers were just fine a week ago. How the heck are they dropping their AD connection, at least according to the JSS?

We attempted to remove the binding, restarted, bound again, did an inventory update and yet the connection for logging didn't allow us to log in and our secure wireless didn't work.

This is so strange and it isn't happening everywhere, but maybe it is and we don't know it because this is only the third day of classes and computers aren't being used just yet?

Anyhow, any feedback is most welcome as it gives us different things to think about.

Thank you...

[brandonalexande]

you may want to verify you have time/location settings configured before the binding process occurs. if the time settings on one of the laptops is off by a minute or two, you could have some funky stuff occur.

[Look]

@mconners There is a timeout for the (I think) the machine password for AD, if the machine doesn't see AD for a prolonged length of time it drops off the domain.
The terminal command to disabe this is.

dsconfigad -passinterval 0

If your binding using a Configuration Profile you can also set this under Administrative.

[Look]

I am moving to Configuration Profile for the New Year refresh, as far as I can tell from testing it seems pretty reliable. Interestingly you can also rebind using a script and it doesn't seem to interfere with it.
I have gone this method as it gives me more control as to when I bind compared to DEP or JSS binding, I do this because it's easier to rename the device before binding it.

[atat5500]

We've been doing our binding through a policy.

When we initially rolled out our Jamf deployment, we were using configuration profiles for our AD binding and eventually decided that using a policy would be better for us. IIRC the only problem we had was if the profile was removed, then the settings were gone and the Mac no longer recognized that it was joined to our domain (typical behavior of 99% of config profile payloads in our experience). Granted, if things are set up properly (we had much to learn back then), and barring a bug in the software, the config profile not being present when it should be would be a very unlikely occurrence, but for us in particular, stranger things have happened.

[jwhiteiii]

Following

[JS_WWU]

Still manually binding post image here, but looking to automate/improve. Interesting to hear about the Mac falling off the domain, as we see that often with windows, but rarely with MacOS.

[Look]

@JS_WWU The falling off the domain issue is particularly prevelant in dual boot environments, especially if you have users who stay in Windows for prolonged periods of time, if your not dualbooting you will be much less likely to hit it and macOS will tend to see AD often enough to avoid it.

[nielandj]

We're running dual-boot in our labs, and even if the machines boot back to Mac frequently (several times a day, in fact), we still have AD drop-offs. This wasn't a problem until this semester, and it's only happening on half of the machines. Tearing my hair out over here!