Bind to AD nowadays... good or bad decision?

Depends on operational needs. Neither good nor bad.

For us, absolute necessity. For you, sounds like not, so I'd (based on what little I know) lean towards reducing complexity. Binding itself is not good or bad, it is just a tool/practice/process that should depend on business requirements.

I would avoid it if at all possible. Apple frequently break AD binding with software updates and new OSs, there is no real need to bind to AD with the ability to set password policies/reset them etc with Jamf policies. You can also use NOMAD to generate Kerberos tickets and use it to connect to shares etc.

You will certainly save yourself a lot of troubleshooting and pain if you can build your workflows around using local accounts instead of AD/mobile accounts.

@cddwyer I'm not sure that the FUD of claiming Apple "frequently" breaks AD binding is helpful to the conversation. We've only seen one case where AD binding just didn't work properly in a brand-new OS, and we just chose not to release it to our users until the .1 update. It was effectively a non-problem.

We bind to AD because it's a simple way to allow users to log into any computer in any building – Mac or Windows – and be able to get to work. In our environment there is no appetite for desktop support to be involved (to create a local account, make sure NoMAD is working for the user, etc.) anytime someone wants to sit at a new desk or log into a conference room machine.

AD binding has not worked correctly the past 3 or 4 OS upgrades on the .0 release. Not sure that it's FUD.

Since Apple won't talk about future "plan" we are left with guessing and it's not unreasonable to assume that something that has not worked correctly the past 3 or 4 years might stop working soon or at a minimum isn't a priority to Apple any more.

And if it's not a priority to Apple anymore, it's risky using it and expecting it to continue being supported.

C

Folks have gotten a little carried away with this trend to not bind to AD IMO. It works fine and is fully supported. That said, it may not offer you much in your situation.

Agreed. Never had a problem binding with either the native tools or Centrify, and that's across 10+ years, with User/Pass as well as smart-card authentication.

Decide if you NEED AD based on your requirements. We do, at least in part because we also have the requirement to be able to lock users out of logging in if necessary. Harder to do that with a local account than one that is centrally managed. Any our 5,000+ users should be able to sit down at a Mac and log in if necessary without Helpdesk involvement, as bvrooman described.

It doesn't have to be an either/or. We have taken a open ended stance on binding, if needed in the circumstance we bind. We make it available as a Self Service option.

For remote users who's setup is handled via DEP, they don't bind off the bat but if they find a reason to down the road we can do so on the fly.

Not bound doesn't have to mean never bound.

AD binding has not worked correctly the past 3 or 4 OS upgrades on the .0 release. Not sure that it's FUD.

Still don't understand upgrading a business environment to a .0 release without testing/waiting for bugs. Home? Sure, I'll do it day 1 (actually before, with betas). Work? That gets planned out, documented, security baselined, tested on multiple levels. Usually on .3 or .4 before we deploy across the board. .0 bugs don't normally affect us unless something unusual has happened.

Apple breaking LDAP has certainly been an issue in the past.

Apple has a tendency to just start shipping machines with new OS's since they don't condone downgrading or imaging in the typical way windows or Linux does due to their "tight hardware integration" so if your a place that does not use too many macs and pretty orders on demand vs having a stockpile you order machines and suddenly your getting the latest OS and have no choice. On most windows machines I can order a downgrade or if you have a site license just image it up with whatever version of the OS you want. Apple does not offer this kind of flexibility.

I've taken a hardline stance on NOT supporting or deploying Apple's newest 10.x.0 OS release until it hits at least the x.2 or x.3 stage and has been tested fully, exactly because they break too much with their initial release. Apple has gotten really sloppy with their initial new releases. Look no further than the root exploit issue they just had to rush out a fix for as a prime example.

@Typhoon_87 That is only true when they ship new hardware that requires drivers only present in the new OS. For any previously released machines that they just start shipping with the new OS, but supported working on the previous one, they can be downgraded. That has been standard now for some time. So it's not completely true to say you have "no choice" when Macs start coming with the new OS. It really depends on if it's brand new hardware or not.

Of course, this is the main reason why we are very hesitant to move to DEP. You get the OS that the box comes with in a DEP workflow. For us, that isn't manageable. Yet.

If you stop binding to AD, how are using logging in? Just curious...Are they still somehow logging into an AD account? Just a local account setup on the Mac? Something else?

Do you have Windows network shares they map upon login? If so, how would these map without asking for credentials?

I'm working on this too, thanks to Apple sending in people to bypass me and talk straight to our CIO about how we're "doing it wrong." The biggest issue for me is that AD is the ultimate source of trust for our domain, and we'd need to make a lot of changes in areas I don't own to support trusting clients without it.

Apple isn't big on understanding why we do what we do. They just want us all to do it the same way so it's easier to support us. Their other option is to fix their native AD functionality so they don't need to sell us professional services to bypass it, and stop making it a low QA priority when they ship a new OS.

Shared machines you need to have some kind of directory service to allow logins, AD is what we already have available for our Windows fleet.
Once your doing it for half your macOS fleet, might as well throw the other half in.
That at least is our scenario as a university with labs full of classroom machines.

As for the .0 releases, we are kind of lucky here in New Zealand as these invariably ship late in the calendar year and by the time the first semester starts early in the new year the .1 is invariably out by then. We have leased machines so we are pretty much forced to move each year to support new hardware.

We're AD bound only because enterprise security says we must. I've pushed for local only with managed password policies. Our password management is also done externally (what used to be Hitachi Psynch but is now something else I think) and our Macs get no real benefit from syncing to AD but gain real headaches when things break (not referring to the FUD - but that's also a real issue) to the point where I have a weekly policy that performs an unbind/rebind to try to head-off the headaches. We also have Enterprise Connect and I think that could do most of what we need, too.

I would wait until to bind if you plan to deploy a wifi profile with certificates.

https://www.jamf.com/jamf-nation/discussions/24257/configuration-profiles-being-removed-and-reinstalled