by Josh Wisenbaker, Head of Engineering
As we have been pushing to the initial 1.0 release of NoMAD Login AD a surprising topic
has come up quite a bit. Many admins are asking what the differences are between the different types of user accounts on macOS. By account type, we aren’t talking about the difference between an admin and user, but between local, network, or mobile. All of these account types have existed on macOS for a long time, but there are still many nuances that can trip you up at first.
The NoMAD product line knows how to deal with these account types in order to keep things moving along in your deployment. In light of some of the confusion that is out there about what makes each account type unique, we’ve prepared a quick primer on them. Each of these sections describes the different sort of user accounts that you can have on macOS and features that are unique to each of them.
Local Account:
This is the default type of account on macOS. Simply it is an account that is created on a Mac and all of the information for it resides there. If you create an account with the Users & Groups pane of System Preferences, or with the sysadminctl tool, this is what you will get. These accounts live in the local node of Directory Services (DSLocal) and the authentication authority for the account is simply the local hash file. Nice and simple.
Network Account:
Things are a bit more complicated with a network account, although not all that confusing. These accounts live in a directory service that isn’t on the Mac. Typically this is some form of LDAP, with Active Directory being one of the most common. In order to access these accounts the Mac is connected to the remote service and then users can be looked up and authenticated according to the search order that is setup on the Mac. No part of the account is on the Mac and information, while cached for performance, ultimately must be looked up repeatedly from the network source. In the Mac world, pure network accounts are most often used now on the server side, where a macOS server can lookup things like group memberships. With deployments full of portable computers the network dependency is an obvious issue as you won’t be able to get anything to work if you disconnect from the network, let alone try to get work done on an airplane. This brings us to the…
Mobile Account:
This account type is the most widely deployed if you are binding your Mac computers to AD. Simply put, a mobile account caches a network account onto your Mac. In theory this allows you to simply use it wherever you are. If you are on the network the account will authenticate to the network. If you are off the network the account will rely on the cached copy of the authentication authority for the user account. This all wonderful until it hits a snag, which it does ALL THE TIME.
If a user simply closes their MacBook and walks off without first logging out and disconnecting from the network, then it will still think it is connected to the network when re-opened. This then can lead to a long timeout when trying to unlock their screen. Normally you are going to hit a two minute timeout for the connection in general and then two minutes for each lookup attempt that has been made. This all adds up and the practical result is that the user is locked out of their Mac until they do a hard reset, losing whatever work they had opened and unsaved.
This happens because the cached authentication authority for the account is the Kerberos realm of the network directory service. Since it is always tried first this leads to the pinwheel of doom and a support desk call. Not coincidentally, this is the exact scenario that NoMAD was designed to address. It allows you to use a local account, but also access a remote authentication authority when you need it.
External Account:
Here is something that most folks have never run into. An external account is simply a mobile account that isn’t cached in the local directory services of the Mac. At first that seems confusing, but it’s fairly simple. When a mobile account is created a cached copy of the account is put into the DSLocal node of the Mac. Another copy of the account is also cached though in an invisible file named .account in the root of the user’s home folder. If that file is found on a disk by another Mac it can be used to allow access to the system. If the account is known by a shared directory service then it’s simply allowed to login. If the account isn’t known to the Mac then the user will be presented with a dialog box that asks if you would like to allow the account to have access.
External accounts are a cool idea that never really took off. I used to make admin accounts that only existed on a thumb drive and could be plugged into a Mac to work on it, but the effort never really seemed to be justified by the payout. (If you want to see what the experience is like, put a Mac with a mobile account on it into Target Disk Mode and then plug it into another Mac that is sitting at the Loginwindow.)
NoMAD and the Account Types:
NoMAD and NoMAD Login can deal with these different account types to make the user experience on your Mac better.
When using NoMAD, we automatically determine if the account is a mobile account or not. If it is a mobile account then we defer to the authentication authority and AD settings of the Mac. This is done to prevent any conflicts with the account arising. If you unbind your Mac from AD, which is common after installing NoMAD, then your local account will still be able to access the Kerberos SSO realm, without any of the lockout and pinwheel issues of using a mobile account. In short, it is the best of both worlds.
NoMAD Login takes this a step further with a feature we call “Demobilization”. When using this setting, NoMAD Login will actually reverse the mobile account creation process, turning the cached account into a local one. Part of this process removes the network authentication authority, thus ending the pinwheels and lockouts. After logging in, users can continue to use NoMAD to gain access to network resources.
That sums it up for the different types of user accounts and how NoMAD interacts with them. As we move forward with our technical blog entires we will cover topics such as these, and more, in more depth.