Home > Apple File System, FileVault 2, Mac administration, macOS > Secure Token and FileVault on Apple File System

Secure Token and FileVault on Apple File System

As part of Apple File System’s FileVault encryption on mac OS High Sierra, Apple introduced Secure Token. This is a new and undocumented account attribute, which is now required to be added to a user account before that account can be enabled for FileVault on an encrypted Apple File System (APFS) volume. To help make sure that at least one account has a Secure Token attribute associated with it, a Secure Token attribute is automatically added to the first account to log into the OS loginwindow on a particular Mac.

Users and groups preference pane only user gets secure token automatically

Once an account has a Secure Token associated with it, it can then create other accounts which will in turn automatically be granted their own Secure Token.

For the consumer user, this usually takes the following form:

  1. Secure Token is automatically enabled for the user account created by Apple’s Setup Assistant.
  2. The Setup Assistant-created user account with Secure Token then creates other users via the Users & Groups preference pane in System Preferences. Those accounts get their own Secure Token automatically.

However, Active Directory mobile accounts and user accounts created using command line tools do not automatically get Secure Token attributes associated with these accounts. Without the Secure Token attribute, those accounts are not able to be enabled for FileVault.

Filevault preference pane account without secure token cannot manage filevault

Update 1-20-2018: @mikeymikey has pointed out an exception to the rule:

Instead, the sysadminctl utility must be used to grant Secure Token to these accounts as a post-account creation action. In that case, the sysadminctl utility must be run by a user account with the following pre-requisites:

  1. Administrative rights
  2. Secure Token

For more details, please see below the jump.

There are a couple of ways to check from the command line if a particular account has the Secure Token attribute associated with it:

sysadminctl -secureTokenStatus username_goes_here

Note: The sysadminctl utility has multiple ways to provide the needed admin authorization to run. Please see this post for details.

Sysadminctl interactive secureTokenStatus otheruser

Sysadminctl interactive secureTokenStatus username

dscl . -read /Users/username_goes_here AuthenticationAuthority

Dscl authentication authority username account showing secure token

Dscl authentication authority username account showing secure token using grep

You can also check in Directory Utility to see if a Secure Token entry appears under the account’s Authentication Authority attribute.

Directory utility username account showing secure token

Once it’s been verified if an account needs Secure Token, sysadminctl‘s SecureToken functions can be used to add it.

The command shown below should add Secure Token to a specified account

sysadminctl -secureTokenOn username_which_needs_secure_token_goes_here -password password_goes_here

If you want to be prompted for the account’s password, use the command shown below:

 sysadminctl -secureTokenOn username_which_needs_secure_token_goes_here -password -

To see how the process of adding Secure Token to an account which doesn’t have it works, please see the video below. It will go through the following process:

  1. Using sysadminctl to check an account for its Secure Token status
  2. Using sysadminctl to check the logged-in account for its Secure Token status
  3. Using sysadminctl to grant Secure Token to the first account, using the logged-in account’s credentials and Secure Token.
  4. Using sysadminctl to check the first account to verify that Secure Token has been added.

To see how user accounts created in System Preferences’ Users & Groups preference pane automatically get Secure Token when created by an account with Secure Token, please see the video below. It will go through the following process:

1. Creating a new user account in the Users & Groups preference pane
2. Verifying via sysadminctl that the new user account has Secure Token

  1. wes
    January 20, 2018 at 9:59 pm

    Ran the migration assistant from one machine to another and I ended up with a password protected disk and no users had secure tokens. The migration assistant threw errors (I forget which). I decrypted and encrypted the disk again and I was able to enable all users for filevault but curiously none appear to have the securetoken still.

  2. January 21, 2018 at 2:03 pm

    Thanks for the well written article. I’ve been running into this with every new system I setup. I noticed that with the systems I migrated to High Sierra That were already FileVault enabled I didn’t have any issues with user not being able to unlock FV disk. I’m guessing because the account was already on the system that a token was passed? I’ll have to use commands in this article to test.

  3. John Altonen
    January 22, 2018 at 4:17 pm

    We create mobile accounts with scripts. Here is the behavior I am observing:

    FileVault is enabled with one valid admin account

    create additional mobile accounts via script inside the existing admin account.

    use sysadminctl to turn on Secure Token for one of these scripted accounts

    enable the user for FileVault in the FileVault section of the Security and Privacy preference pane.

    restart. The mobile account user does NOT show up on the FV unlock screen.

    Create a new local account with Users and Groups GUI and restart

    Both the new local account and the mobile account show up at the FV unlock screen.

  4. January 22, 2018 at 7:14 pm

    Workflow for this feels like it’s going to be messy for those of us in JAMF environments where the users are not admins. May have to create a script to temporarily raise the enduser creds to admin to run the sysadminctl command as them to add the token to other users?

    • Devon
      March 2, 2018 at 4:38 pm

      ^^ My feelings exactly. My organization is stumped right now, because we’re trying to create a workflow that would allow us to use JAMF imaging to lay down a base image before passing the computer onto the user. Unfortunately, this results in the local admin account NOT having a secure token. With no user account on the computer having a secure token, there is no way to create additional users that DO have a secure token — meaning there’s no user account that can enable FileVault. We don’t run into this problem if we create the account via Apple Setup, but that is much more time consuming than just netbooting an entire room full of computers and imaging them all at once.

  5. jbrickley
    January 23, 2018 at 11:24 pm

    Ugh, now I guess we need a pop-up dialog prompting the user to authenticate so an elevated script can turn it on and provide the password. This is exactly what we train our users NOT to do in extensive Phishing Training. I guess I will have to put it in Self-Service and present a dialog with the company logo, etc.

  6. drewdiverDrew
    February 6, 2018 at 12:04 pm

    This nuked my occasional setup of a laptop where I install what’s needed, remove the account along with /var/db/.AppleSetupDone..

  7. Stephen Short
    February 9, 2018 at 10:03 pm

    I’ve run into some interesting behavior re: secureToken and the pycreateuserpkg tool. I create a new user with SetupAssistant, and it receives a secureToken as expected. A config profile is pushed from my MDM server that enforces Filevault. I reboot to enable FV for that user. After login, I install my admin_user.pkg created with pycreateuserpkg. I go to System Preferences and enable this second user for FV disk access. If I run -secureTokenStatus I get a positive “enabled” response, but if I reboot I am only presented with my Setup Assistant-created user.

  8. Jacob
    February 24, 2018 at 8:29 pm

    I’ve about had it with this and I’m hoping I can get some help. Somehow when I upgraded my personal machine to High Sierra I lost the secure token for my account. Now no accounts on my machine have a secure token.

    I am trying to enable one so I can enable Filevault, but I do not know how to create an account with a secure token when no existing accounts already have one. I have deleted .AppleSetupDone to re-run Setup Assistant, but that also produced an account with no secure token.

    Please let me know if you have any ideas!

  9. Taco
    March 22, 2018 at 4:34 am

    Thank you all for this post and particularly rtrouton and mikeymikey.
    I have found it very interesting because I am in the process of testing FileVault 2 on 10.13.3 for our work place for about 3 weeks now. We are using JSS 9.101.0 at this stage.

    All our macs are imaged via DEP and all of our users are logging in using Active Directory Mobile accounts. The local “administrator” account is also being used as a management account and hidden, the local “administrator” account is created via JSS during either enrolment or DEP. We do not create any other account at all.

    I am testing on both OSX Extended (Journal) and APFS formats:

    -For OSX Extended (Journal) format: the local administrator local hidden account is able to turn on FileVault and enable FileVault for AD Mobile accounts afterward

    -For APFS format: the local administrator local hidden account is NOT able to turn on FileVault.
    -The command used to check for Secure Status is “sysadminctl interactive -secureTokenStatus $username_type_here” > the output is the “$username_type_here is DISABLED…..”

    – SOLUTION: Use JSS to create a local account with administrative right called “filevault”, then run a script to enable secureTokenOn for this account “sysadminctl -adminUser administrator -adminPassword $administratorPassword -secureTokenOn filevault -password filevaultpassword”

    where: $administratorPassword = your administrator password

    After this script is run, it is found that both the local “administrator” and local “filevault” are ENABLED for secure token. Check by running the command “sysadminctl interactive -secureTokenStatus administrator” and “sysadminctl interactive -secureTokenStatus filevault”
    The next stage is to log in with the local “filevault” account and turn on the FileVault and enable the mobile AD account at the same time.

    This has just been tested on a brand new MacBook Pro about 3 hrs ago.
    I hope this helps………!

  10. April 23, 2018 at 7:55 pm

    We tested enrolling a macOS 10.13.4 computer on a JSS 9.101.4 and found:

    1. The initial account (local admin account “adminuser” for example) is deferred enabled.
    2. “adminuser” logs out and is prompted for password (which that user has NOT changed).
    3. FileVault 2 is enabled for that user.
    4. LDAP user logs in and gets “Enter a SecureToken administrator’s name and password to allow this mobile account to log in at startup time.” prompt.
    5. “adminuser” enters username and password into the prompt.
    6. LDAP user is now enabled for FileVault 2.

    Pretty nifty…even if it involves an additional step in our Thin Provisioning process, works fine.

    PS, if “adminuser” password is changed before it enters credentials to enable FileVault 2, the process no worky.

  11. smiller
    May 23, 2018 at 4:43 am

    I’ve been struggling mightily to get any deployment automation at all that will yield an end result with a SecureToken enabled account . here’s my setup:

    Tests are on Touchbar MacBook Pros (various models)
    – No DEP
    – Using (IMO a non-monolithic process with) DeployStudio 1.7.8 (using an external DS boot drive and a separate DS server, no netbooting)
    – Workflow foundation is an APFS 10.13.4 (17E99) AutoDMG created Master (totally barebones)
    – AD integrated enterprise environment, where users log in locally using AD creds and mobile accounts (especially on laptops)
    – in-house Apple Profile Manager (10.13.4 / Server 5.6.1 (17S2109)
    – Laptops (when things are working) get FV2 encrypted with an IRK in a config managed by the Profile Manager.

    I’ve tried two different DS processes with this 10.13.4 (17E99) OS – they both yield the same result. Other than the SecureToken issue, everything else in my builds go 100% normally.

    I don’t dare try and enable FV2 on these machines until this is sorted out. If anyone has any ideas I am all ears – would really appreciate any help!

    Test #1:
    Uses the native DeployStudio Account process for creating a hidden local admin user (ostensibly using dscl or some other “legacy” method). I can log in as the hidden local admin, and I can log in as an AD user, which creates a mobile account on login.

    When I run sysadminctl -secureTokenStatus [username]
    I get the same result.
    sysadminctl[2874:27290] Secure token is DISABLED for user [local adminuser]
    sysadminctl[2874:27290] Secure token is DISABLED for user [AD user]

    Test #2:
    Turned off the DeployStudio account creation process and turned off the “Skip Apple Setup” flag.
    After the deployment was complete, upon startup, I use the GUI setup wizard to create a new (NON-hidden) local admin. Much to my surprise, this account did NOT get SecureToken enabled. Same thing also true when I logged in with an AD account (and creating the mobile account) – same results as before.

    Am I the only one baffled by the Test 2 result? I get why accounts created by DS in Test 1 could fail – but why wouldn’t the ones created by Setup Assistant in Test #2 yield an admin account with an enabled SecureToken?

  12. Allan
    May 23, 2018 at 2:27 pm

    smiller, it seems I’m in the same boat as you, we image the monlithic way and basically it seems impossible to get any accounts with secure token enabled on them doing it this way.

    • Seth Miller, Miller Systems
      May 26, 2018 at 2:02 am

      I actually made a breakthrough on this just a couple of hours ago that i’ll describe in a comment after some sleep. FWIW I would not describe what we are doing as “monolithic” at all – it’s an automated installation process. Unfortunately DeployStudio is not able to create users the new way, and that’s the problem. Will post over the long weekend to try and help other folks out.

  1. No trackbacks yet.

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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

%d bloggers like this: