Bypassing the SecureToken dialog for mobile accounts

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:

  1. The context of SecureToken is quite technical, this dialog would be confusing to a lot of people.
  2. 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.
  3. 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 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:

  1. The technician proceeds through the Setup Assistant and enrols the Mac via DEP.
  2. Mac binds to Active Directory as part of the DEP Pre-Stage Enrolment configuration and skips initial user account creation.
  3. 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).
  4. The Mac restarts and intended user logs in with their directory account.
  5. FileVault is enabled for the user automatically by policy and the boot drive encrypts successfully without requiring any form of SecureToken granting.
  6. 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.

Author: n.martin

Managing 450-odd Macs at a university, innit.

4 thoughts on “Bypassing the SecureToken dialog for mobile accounts”

  1. The behavior changed in Mojave. The Secure Token is necessary to enable filevault, thats why you have to implement a (hidden) secure token holding user which is able to grant a secure token to the active directory user (which isnt always known at the time of deployment).


    1. Hi Rémi,

      It’s still not needed if you never intend to enable FileVault – eg in a shared lab setting. But yes, for FileVault, I’d say don’t suppress this.

      Kind regards,



    2. I used FV2authplugin for this before 10.13.4 and it worked flawlessly. This has been a headache to give admin credentials everytime when a new user logs in. In the article above, I find that it’s only for bypassing. Any idea I can skip the credentials window when a new AD user logs in and still can able to decrypt that account? Let me know.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s