Semi-Regular "Do you Bind" discussion

easyedc
Valued Contributor II

With 10.13 now out and moving along, and the requirements of local accounts created through the GUI for certain admin functionality, FV2 not playing nice with mobile accounts, and a few other quirks, has that changed peoples perspectives on binding? We purchased Enterprise Connect a few years ago, but still bind, and force users to use mobile accounts.

10.13 is maybe changing my mind on that, and I wondered if others have thought about that, too.

13 REPLIES 13

rich_thomas
New Contributor III

For the exact reasons you mention plus a bunch of others, we are looking at removing the bind of binding ASAP. There's no enterprise connect over here though, so we'll be trying nomad.

john_bio
New Contributor III

Can you post a link/info to some resources about these limitations that you mentioned? (requirements of local accounts created through the GUI for certain admin functionality)

I must have missed something :

easyedc
Valued Contributor II

Among other things, 10.13 now enforces secureToken, which requires an account created via the GUI for, at the very least, FileVault 2 enablement. FV2 is a security requirement to deploy in the field, but letting our field techs create local accounts and then having to manually try to clean that up by running terminal commands to enable our default account, delete extra accounts, etc, becomes concerning, if not problematic.

Mobile AD accounts, or accounts created via MDM still do not get secureToken enabled by default, but according to Apple Support, their engineering is working on a solution to help mitigate issues caused by this. With my goal of the simplest deployment possible, not being able to easily leverage my jamf created management account is a pain.

Add into this, the frequent issues that macOS has with AD in general (think back just a few short weeks ago to 10.13.0 release where for a lot of users, mobile accounts couldn't log in unless connected to a network with access to a domain controller which did affect us). There's been AD related issues in every major OS release as far back as I can remember.

timlarsen
Contributor

I can speak from experience that using local accounts DEP plus local password profile plus Enterprise Connect plus FV2 works very, very well in our environment. I understand EC isn't available or plausible for some, but I would highly recommend it to anyone still considering it. I haven't tried NOMAD but have heard really good things about that too. Long story short, using local accounts has been great for us, particularly on laptops we deploy to other countries that may or may not have access to our corporate network.

mm2270
Legendary Contributor III

Still AD binding here (and using cached mobile accounts), not because I really want to, but more because the org is a dinosaur Windows shop that still thinks binding is the only thing that matters. But with the above mentioned roadblocks and wrenches being thrown into 10.13, I am seriously considering making a big push against management to go with local accounts and use NoMAD (or EC if they are open to the cost) as the way forward.

It's very apparent AD binding is quickly becoming a pariah in the Apple world, with Apple more or less leading the charge on making it into one, which is a bit frustrating. It's like Apple is purposely creating problems that cause AD binding to be more and more of a pain, only to point to these as reasons to not bind. Well, yeah Apple! When you've essentially created the problems and breakages, of course it's not going to work! Jeez!

Anyway, with the handwriting becoming very clear on the wall, it seems we need to move away from it if we want to continue to use Macs in the environment.

donmontalvo
Esteemed Contributor III

Active Directory binding offers a lot of functionality, to complement that "naked body dragged over broken glass" experience.

For shops scoping to LDAP groups, direct ldapsearch queries can give you all you need in that space (where local dscl queries require binding).

The only legit reason I see losing in walking away from that horrible thing called Active Directory binding, would be if Legal/Security/HR request an immediate lock down of a user account.

@mactroll's excellent NoMAD and Apple's Enterprise Connect help minimize the bleeding and hemorrhaging associated to Active Directory binding, but neither can lock down a user account.

Although who knows what's up @mactroll's sleeve. :) Not sure if Apple cares about improving Enterprise Connect.

With all that said, Apple does provide device lock and/or wipe using MDM. A different way to do the same thing on the client side...where user account lock down has always been possible on the server/resources side using AD.

--
https://donmontalvo.com

AVmcclint
Honored Contributor

We continue to bind to AD because resources like McAfee ePO and BigFix require every computer be in their records to be managed. We also have to manage because our 802.1x is controlled by Computer certificates that are issued only after binding to AD.

gachowski
Valued Contributor II

We don't bind, and it was worth the effort to get our org to change.. less complicated build process, better user experience and the most important one to me is that it's allowed us spend those wasted resource screwing with binding issues on other improvements.

C

Look
Valued Contributor III

None of the non bound solutions appear realistic for a shared student computer environment, hence we still bind.

gachowski
Valued Contributor II

I looked it up in the Apple dictionary.....student computer environment = iPad=mdm...

C

: )

bbot
Contributor

Still using binding here as we need Active Directory to generate certificates for 802.1x network authentication

Dooley
New Contributor

We are just implementing a "no bind" policy on new macs/imaged macs. We deployed Apple Enterprise Connect September 2017 and have been pleased with the way Apple has added functions into it. The add on function, Enterprise Connect Control Language (ECCL) was released Spring 2018 and was timely. It allows us to do API calls to grab the Kerberos logon name to capture user info for inventory.

I'll post back in a few weeks after we get experience with "no-bind" production deploys.

Paul D.

dshepp33
New Contributor III

We bind only for the system certs that allow WiFi and VPN. Password sync would be the other but NoMAD can do that. I wish my AD folks would more receptive to my desire to get rid of binding. I would be fine going with a hybrid solution. Bind for the reasons I said but use local accounts with NoMAD or the like to do the password sync and what not.