Category "Admin tips"

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.

With NoMAD version 1.1 just a short ways around the corner, we wanted to start sharing the Shares preference file… see what we did there!?!

Note: As a beta this file format is still subject to change… but we wanted to give you an idea of what was coming.

What is this?

With 1.1 NoMAD will be able to arbitrarily mount shares specified in a preference file. Since the shares are rather different than the rest of the NoMAD preferences, we’ve put them into a new plist to make things easier.

Where does it go?

Currently this preference is at menu.nomad.shares, but as with all things beta, this may change.

How do you make it?

There are 3 top-level objects in the file.

1. Version – this is the version number of the file format. Currently the only version is 1

2. HomeMount – This is a Dictionary of attributes for if the user’s home profile should be mounted.

Groups – [String] – Only mount the home for members of these AD groups
Mount – Bool – Mount automatically or not
Options – [String] – Array of mount options defined below

3. Shares – [Dictionary] – An array of dictionaries with each dictionary defining a mount point and associated attributes. Below is what goes into each Dictionary
AutoMount – Bool – Is the share automatically mounted
ConnectedOnly – Bool – Is the share only mounted when on the AD domain
Groups – [String] – An array of AD group names. This share will only automount for members of that group
LocalMount – String – A local mount point
Name – String – The name of the share as it will appear in the NoMAD menu item
Option – [String] – Array of mount options defined below
URL – String – The actual URL of the mount point in the form of “smb://dc1.nomad.test/Homes”


First off huge thanks to @frogor for having figured these out. Note that most of these are probably not very useful or safe. Please use at your own risk. The primary ones that most admins will care about are MNT_RDONLY, MNT_DONTBROWSE and MNT_NOEXEC.

"MNT_RDONLY" - Mounts the share read only
"MNT_SYNCHRONOUS" - All I/O to the file system should be done synchronously.
"MNT_NOEXEC" - Prohibts execution of code from the share
"MNT_NOSUID" - Do not allow set-user-identifier or set-group-identifier bits to take effect.
"MNT_NODEV" - Do not interpret character or block special devices on the file system.
"MNT_UNION" - Causes the namespace to appear as the union of directories of the mounted filesystem with corre-
sponding directories in the underlying filesystem.
"MNT_ASYNC" - All I/O to the file system should be done asynchronously.
"MNT_EXPORTED" - Filesystem is exported
"MNT_QUARANTINE" - File system is quarantined
"MNT_LOCAL" - File system is stored locally
"MNT_QUOTA" - Quotas are enabled
"MNT_ROOTFS" - Identifies the root filesystem
"MNT_DOVOLFS" - Filesystem supports volfs (deprecated flag in Mac OS X 10.5)
"MNT_DONTBROWSE" - Does not display the share in the Finder
"MNT_IGNORE_OWNERSHIP" - Ignore ownership information on file system objects
"MNT_AUTOMOUNTED" - Set flags on the mountpoint to indicate that the volume has been mounted by the automounter.
"MNT_JOURNALED" - Mount filesystem journaled
"MNT_NOUSERXATTR" - User extended attributes not allowed
"MNT_DEFWRITE" - Filesystem should defer writes
"MNT_MULTILABEL" - Support for individual labels
"MNT_NOATIME" - Do not update the file access time when reading from a file.

Preference file itself

{ HomeMount = {
Groups = ( "Domain Users" );
Mount = false;
Options = ( );
Shares = (
{ AutoMount = false;
ConnectedOnly = true;
Groups = ( "Share Mounter Test" );
LocalMount = "";
Name = "File Server 2";
Options = ( );
URL = "smb://dc2.eng.nomad.test/Files";
{ AutoMount = true;
ConnectedOnly = true;
Groups = ( );
LocalMount = "";
Name = "Home Shares";
Options = ( );
URL = "smb://dc1.nomad.test/Homes";
Version = "1";

Starting with NoMAD 1.0.5(640)BETA NoMAD can now support environments that don’t have Active Directory. If you have a Kerberos environment that has been integrated with an LDAP server, NoMAD can give you the same functionality that you would get if AD was in the mix. Since there’s a variety of different LDAP setups, please test this in your environment and let us know if it’s missing anything.

Getting it working

NoMAD is designed to automatically configure as much as possible and relies on a number of AD-focused methods to do that. In the situation where you don’t have an AD environment you may not have all of these services in place. Don’t worry! As you can manually configure everything that you may need.

Starting Off

To get NoMAD to start doing LDAP-only queries you can set the LDAPOnly preference key to true.

SRV Records

NoMAD by default attempts to find both LDAP and Kerberos services via SRV records in your DNS. You most likely have these for your Kerberos KDCs, but you may not have the records for your LDAP servers. To get around this you can just designate your LDAP servers manually with the LDAPServerList preference key to a comma separated list of your LDAP servers.


Many LDAP environments are configured to use LDAP over SSL. NoMAD fully supports this, but you’ll need to set the LDAPOverSSL preference key to true.

Test It!

NoMAD will allow for password changes, scripts and other actions, sign in and sign out and local password synchronization. The only major feature that you won’t have will be the password expiration countdown. This is mostly because there’s no real standard way to do this in an LDAP-only environment. However, if you’re interested in this please let us know and how you’ve implemented it, as this is something we’d be happy to put more work into.


Most NoMAD users are pushing preferences via configuration profiles. This is a great thing, but does make troubleshooting a bit tougher as the defaults command won’t show what keys are forced.

So… have a look at pref-finder.

Launch the tool and specify a preference domain you want to look at. You’ll be able to see all of the keys for that domain, check just a single key, check if a key is forced, or what most people will use it for, show all forced keys for a particular domain.

pref-finder -d com.trusourcelabs.NoMAD -k LastUser -f -F -a

It has a project page, and can be downloaded here.

NoMAD 1.0.3 responds to a number of Apple Events that you can send it from the CLI and other methods.

Current Actions

  • nomad://open – launches the application
  • nomad://signin – opens the sign in dialog if the system is on the domain and a user is not already signed in
  • nomad://user:pass@signin – causes NoMAD to get a Kerberos ticket for that user and password. If the Keychain is set to be used, this password will be stored in the keychain.
  • nomad://update – makes NoMAD update immediately
  • nomad://passwordchange – will show the change password window

If you have 1.0.3 or later installed, clicking on any of the above links will cause NoMAD to react. You can also use this from scripts via the “open” command.

open nomad://signin

In a shell script will cause NoMAD to launch, if it isn’t already and then show the sign in window if AD is reachable. This is a pretty handy thing to use at the end of your enrollment workflow to get the user’s password starting to sync.


© 2017 Orchard & Grove Inc.