Local vs. Domain accounts

I'd suggest you watch this one as well:

http://www.jamfsoftware.com/resources/moving-from-traditional-windows-habits-to-advanced-techniques-for-modern-it/

A lot of those pros and cons are covered here as well as some options outside of AD binding.

We still do AD binding and use AD accounts (cached mobile) on all our managed Macs. Apple's DEP does pose some challenges around this (we aren't currently using it, but continue to keep looking at it) since there is that local account that gets created upon first setup. I imagine some folks are doing creative things like binding to AD after DEP enrollment, creating the AD user's account (using some interactive dialog stuff and the createmobileaccount binary) and then rebooting, removing the local 501 account in the process or something to that effect. Seems like a fair amount of work to do, but it could be done with enough know-how, scripting and testing.
However, as an alternative to point out, we recently sat in on a presentation around Apple's Enterprise Connect. One of the interesting takeaways from it was ways of managing access to company resources and password policy stuff while using local non AD accounts.
I doubt we will be moving away from AD accounts any time in the near future, but if we were, we would probably consider bundling the change with Enterprise Connect to help with the transition, assuming we didn't do something custom like what I outlined above that is.
It (Enterprise Connect) is something at least worth looking at. Its certainly an interesting toolset.

There's so much weird secrecy around Enterprise Connect. I contacted Apple for info on the service and what it entails, and they sent me their generic 1 page pdf and a price.

I need a bit more meat on the bone if I'm going to seriously look at it as an option. It's intriguing, but... Data! Data! Data! I can't make bricks without clay.

Well, KerbMinder just had a huge update so that:

• KerbMinder no longer requires the computer to be bound to Active Directory. It will prompt for username and domain info if the computer is not bound.

More about that & some other projects here.

We'll see what we can do about ADPassMon & non-bound Macs :)

@hkabik Our assigned Apple systems engineer asked us casually about it at one point, and we said basically the same thing. "Sounds interesting, but we know so darn little about, so whatcha gonna do to help with that?" And so he arranged for the team that works on Enterprise Connect to do a Webex meeting and demo on how it works and some of the technology behind it. I'm pretty sure we were only one of many Apple customers on the call though, so it was not an exclusive preso for us. If you have an Apple SE you work with, reach out to him/her and ask them to set something up because you're interested but need to know more.

My old job used both AD & OD, both in the Golden Triangle and stand alone iteration over the years, whereas my current one just has local accounts. When I first started, I was like HUH?!? and was initially in the mindset of I'm going to implement AD over the next year. But I've actually come to prefer local accounts. It's a whole lot easier to manage for our needs - no weird login issues or keeping up with AD/OD. All our users have laptop issues to that one person, so the need to log on to another machine with all your data is relatively rare - and we use Google Drive anyways so all their data will transfer over anyways. One of the main draws in the past of directory authentication was mobile home syncing, but that caused so many headaches that I'm glad to longer deal with it.

Our main drawback on not using AD is lack of SSO, such as PaperCut & GApps. But overall, from an administration standpoint, local accounts has presented less technical issues than directory authentication. Once people get logged in for the first time, the rest of the year is easy as pie.

We also use generic logins for carts (eg, "student/student"), and local logins definitely make life easier there.

Ultimately, it comes down to what drives your business. We don't have services directly tied into AD/OD here, so it currently makes little sense to implement it for our use case. But other locations may certainly benefit. It's also worth noting we only have about 4 Windows computers in the entire school - if we had more, I would certainly give more weight towards using AD again.

Yep reach out to your SE!!!! they should be able to set something up with Enterprise Connect...

I want to make this change to using Config Profiles to manage local passwords...and I am working toward it for sure.. and one of the sound bite I use is...

AD is old technology on the Mac that might get it's bugs/issues fixed, Config Profile are current technology that should have is bugs/issues fixed. This is true for any change... trading old issues for new issues...

Many people have been starting to move to Config Profile to manage the password and IBM/Apple last week at JUNC just told everyone that it's the way to go.... if your not using Config Profiles or working toward doing it you are going to be behind the curve...

C
PS with this discussion I am not sure that any arguments are really going to matter, in most orgs AD is a religion...

Reading and researching (reached out to our Apple SE about Enterprise Connect).

@gachowski We're lucky that our user base is small enough (500+) and unique enough (domestic and international production crews with infrequent office stays) that we've been able to dodge domain logins. My boss will take my suggestion, with enough reasoning, and stick with it in the face of management (yes, I'm that lucky).

I'm leaning away from domain logins, despite the 'good corporate citizen' aspect of adopting them.

"AD"-less doesnt look like an usable alternative for us. We have 300k+ Users in our Environment and due to the Law in Germany you want to know which Student was sitting infront of the Machine. The use of any generic Accounts is prohibited as soon as the Machine has Network Connectivity.
I'm not sure, but I think you will face the same Problem if you have shared Machines.

As soon as I have one Mac with DEP, I'll give it a test if I can enroll it, like we need it!
Currently we are going with Casper Imaging which finishes in around 20 Minutes.

My main pros and cons would be:

Pros for directory joined:

• SSO / Kerberos for services that support it
• User identification, tracking down who is using what Mac has come up lots of times. Without a directory account we would have a lot of trouble
• Central control and administration of all user accounts
• AD based machine certs for authentication to services like 802.1X

Cons for directory joined:

• Depends if SSO is really that useful for you. If you are using a load of cloud based services, probably not
• Going against the grain. It seems Apple prefer a more "consumer" like setup and AD definitely isn't that. DEP is a good example, non directory joined Macs "just work"
• Issues, slow logons, failed logons, FileVault, home folder syncing, the list of issues people face is quite long! 10.10.0-10.10.2 highlights the potential for major issues and prevents early adoption for new OS releases

There does seem to be a few other myths, such as password policy enforcement requiring a directory server. Config profiles can replace that functionality for local accounts. We even tested it adding the profile and deleting the /var/db/.AppleSetupDone file. The password policy was enforced for the setup assistant, which was pretty neat.

Anyway, just thought I'd chuck in my view!

Late followup, but we decided to not worry about domain accounts. Our test group of users reported several problems with updating passwords when their 90-day update period came around.

We'll probably be pushing local user accounts for the machines assigned to specific users, and leaving a non-admin generic account for when they have to share the machine and for pool (shared with no set owner) machines. One of us in support (or their local manager in some cases) will create their local user account.

Our company password change policy is 90-days after you last changed it. Which sounds all fine and dandy, until you look at that again. Its 90-days, individually for each user based when they last changed it. This will make our 90-day Local Machine password push somewhat annoying since we'll probably be out of sync with each individual's 90-day period. But oh well.

Thanks to everyone for the input. :-)