Ahh SecureToken; the gift that keeps on giving! macOS 10.13.4 introduced this new, undocumented dialog that would appear on first login under the following conditions:
- If the filesystem is APFS
- Whether or not FileVault is enabled
- If the Mac is bound to a directory service (e.g. Active Directory or LDAP)
- If there is a local administrator account present that has logged in at least once (e.g. the one created during the Setup Assistant).
- If the account currently logging in will be a directory based mobile account (i.e. it hasn’t been created yet and is logging in for the first time)
The text reads:
Enter a SecureToken administrator’s name and password to allow this mobile account to log in at startup time.
You can Bypass this to continue creating your mobile account, but you may not be able to log in with this account when the computer starts up until your administrator resolves this issue.
I think Apple has good intentions with this dialog, especially if you’re using mobile accounts in conjunction with FileVault – this gives us an easier way to grant users SecureToken without having to use sysadminctl. But the problems with it are this:
- The context of SecureToken is quite technical, this dialog would be confusing to a lot of people.
- If you click Bypass, your mobile account is created and you’ll never see this dialog again. If the Mac is encrypted with FileVault, you won’t be able to unlock it with your mobile account credentials. Moreover, if the Mac is not encrypted with FileVault, you won’t be able to enable it with that mobile account.
- For shared Macs in lab settings that are not encrypted with FileVault and never will be, this dialog is not necessary, as well as confusing.
With the macOS 10.13.5 update, Apple quietly gave us a preference key to suppress it:
The domain is com.apple.MCX and the key is a boolean: cachedaccounts.askForSecureTokenAuthBypass
Set it to TRUE and you’re done!
Here’s a Configuration Profile that would do it:
As a footnote, another way to avoid this dialog would be to switch to network based directory accounts. However, that would mean that the Mac must always be able to reach your directory service in order for users to log in, since network accounts aren’t cached (even if their home areas are local and do persist on disk).
Also – I have observed that this dialog does not present when binding to a directory as part of the DEP Pre-Stage, skipping the local user account creation and logging in with a directory account as the very first user. Logging in with a second, different directory account following this does not present the dialog either. I observed this behaviour whether or not FileVault was enabled. Because of this, the following workflow is possible:
- The technician proceeds through the Setup Assistant and enrols the Mac via DEP.
- Mac binds to Active Directory as part of the DEP Pre-Stage Enrolment configuration and skips initial user account creation.
- The technician logs in with their directory account to kick off our provisioning workflow (naming the Mac and choosing its role – staff or student use).
- The Mac restarts and intended user logs in with their directory account.
- FileVault is enabled for the user automatically by policy and the boot drive encrypts successfully without requiring any form of SecureToken granting.
- The user account has SecureToken but the technician account does not (good!). Only the user account is shown on the FileVault pre-authentication boot screen.