Pros & Cons of going local vs using a mobile account?

dlprentice
New Contributor III

Hi Guys,

We are building out our login workflows, and a good question was asked. Why are we going Local and not using Mobile Accounts when we bind anyway?

Most videos seem to hint that local accounts are the recommended option, but I can't seem to find a hard list of Pro/Cons for reasons to go local over mobile.

Any insight as to why we would go local over mobile would be helpful. We are using the Kerberos SSO Extension to give user's Kerberos tickets after they login. The concern is that user's don't get a Kerberos ticket upon login which I believe is what a mobile account would do for us.

Thanks in advance!

1 ACCEPTED SOLUTION

russeller
Contributor III

Hey @dlprentice
This can be a spicy discussion, but its what really makes the most sense for your environment. If your Macs are going to be:

  1. on-prem
  2. communicate with your AD server all the time
  3. you expect multiple users on the Mac binding might still be a great option.

I feel like most environments are dealing with Macs going off site making AD inaccessible unless VPN is used (or forced on). Also considering if your Macs are going to have a single user their whole life a local account would also make a lot of sense. If your Macs are expected to let any directory user to login then binding makes sense.

Feel free to ignore all the noise about what is new and shiny and continue to do what is best for your situation. At the end of the day you are going to be the one supporting whatever you choose.

View solution in original post

8 REPLIES 8

russeller
Contributor III

Hey @dlprentice
This can be a spicy discussion, but its what really makes the most sense for your environment. If your Macs are going to be:

  1. on-prem
  2. communicate with your AD server all the time
  3. you expect multiple users on the Mac binding might still be a great option.

I feel like most environments are dealing with Macs going off site making AD inaccessible unless VPN is used (or forced on). Also considering if your Macs are going to have a single user their whole life a local account would also make a lot of sense. If your Macs are expected to let any directory user to login then binding makes sense.

Feel free to ignore all the noise about what is new and shiny and continue to do what is best for your situation. At the end of the day you are going to be the one supporting whatever you choose.

chadlawson
Contributor

I'll secon what @ssrussell said. Unless you have a need or requirement for AD binding, local is the way to go these days. For most of my clients, the only benefit that Macs get from AD these days is password synchronization which can be done almost as easily, far more cleanly, and wayyyyyy more reliably with NoMAD or Jamf Connect these days.

Since you mention Kerberos, that is easily done with NoMAD and Jamf Connect as well. Do you have any other requirements that have been pushing you to AD?

And it's also worth noting that with so many people working from home and so few organizations using externally facing AD servers, I spent the first quarter after quarantine working with clients to get their Macs off of AD for just that reason.

snowfox
Contributor III

I could be wrong here but to me it looks like mobile accounts are on the way out. The industry trend is moving towards cloud identity providers AzureAD etc. With the pandemic our organization is rapidly moving towards (having to pivot to) total cloud configuration including Jamf Protect and Jamf Connect in case lockdown 2.0 and 3.0 happens. We have to do this so the organization is flexible enough to survive going forward and can keep working.

Jamf Connect will convert your mobile accounts to local accounts from the brief read I've had over the documentation. Mobile accounts will be no more. Your needs may be different from ours but for us, investing in mobile accounts is heading in the wrong direction. If the industry is heading for cloud IDP then that's where we're heading too as that is where platform solutions will be developed for customers going forward. As the others have said, we can't easily access our on-prem AD off site. AzureAD is probably where we'll end up. My 2c.

walt
Contributor III

Pros - (local) flexibility, supported moving forward
Cons - (mobile accounts) spending too much time dealing with what is now becoming a legacy function

shared devices it depends on your configuration or what you're doing. using NoMAD Login or even Jamf Connect as a solution to AD for shared devices/labs could work.

tlarkin
Honored Contributor

I would suggest local accounts for most environments. In my personal opinion the only time you want to mess with AD/LDAP and mobile accounts are the following edge cases

  • You have more than one human per a machine
  • You actually need kerberos tickets to auth to internal services

If those two things aren't a factor, just use local account in my opinion

dlprentice
New Contributor III

I appreciate all of your well formulated feedback on this topic.

eaititig
New Contributor III

Curious ... but with mobile accounts once the user logs in, their password is cached, so there is no need to communicate with AD all the time. I see no difference in how Windows laptops are treated. Happy to hear any counterpoints.

One of the issues we have with using mobile accounts is if you also use FileVault and the user changes their AD password FileVault does not automatically sync the new password. So when the user restarts or shuts down their Mac they often have difficulty getting past the initial login screen (I call it the FileVault screen) so they cannot boot the Mac. We have to log in with our local admin account and use terminal to remove them from FileVault and re-add their account using the new password. 

We have since switched to just using local accounts because of this issue. If a user is remote they are totally SOL if they cannot get past the FileVault login screen to unlock the drive and boot their Mac. 

This was mentioned above, but using mobile accounts is no longer supported by Apple. It's basically a legacy feature that they just haven't removed from macOS yet. Keyword being "yet".