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.

      • GekkePrutser
        May 28, 2018 at 4:03 pm

        Could you tell us more about this breakthrough? SecureToken is a nail in my coffin 🙂

  13. Seth Miller, Miller Systems
    May 28, 2018 at 11:35 pm

    Sorry for the suspense. It appears that, at least with 10.13.4, the issue is that the *first* user that gets created on a freshly deployed system has to be done in a way that enables its SecureToken. Otherwise, there’s no way to get *any* user enabled. Here’s how we determined that – while working with an Apple Enterprise Support rep:

    Attempt #1: We’d tried turning off the native user account creation process in DeployStudio, as well as disabling the Setup Assistant suppression, and running our standard build. After deploying and then going through the manual Setup Assistant process, the freshly minted admin user account was still NOT SecureToken enabled. I was very unpleasantly surprised.

    I ran some queries following that attempt – and it turned out that one of our software installers (for a security product) was creating a user as part of its installation. So even though I had turned off admin creation in DS, there was still an older creation method being performed for a user *before* the manual process was undertaken. So, in…

    Attempt #2: Performed a much simpler Deployment. I continued to leave the DS account creation and setup assistant suppression off, but also stripped the workflow down. I basically left all of the OS configuration items (AD binding, Profile manager enrollment, some environment-specific network scripts, etc.) and removed all of the software installers, so that they would run be run separately (more on that later). After this deployment, upon startup, I was directed to the setup assistant, and manually created the first user at the console. When I queried the system, the user was in fact SecureToken enabled – and that allowed me to use that account to enable others, including AD accounts, using the sysadminctl commands.

    Finally, I was able to restart the system using a DS boot disk and kick off the workflow I’d created, which only had the installations that I’d removed from the original workflow, so that it could run the second half of our deployment processes, including the security software user.

    It’s not a great workaround – many more steps than we previously used to do to get a machine built. It is definitely time to replace DeployStudio with other tools that are being maintained to use the newer methods for these critical processes.

    I hope that helps folks, and if anyone has had a different experience please do share.

    • Allan
      May 29, 2018 at 7:55 am

      Looks like you’ve kinda just re-enforced what we knew already though sadly. At present it looks like there’s no way to get around this using Jamf imaging 😦

      • GekkePrutser
        May 29, 2018 at 9:03 am

        Yes I was hoping there was a way for automatically granting it to AD users in particular.

        Apple’s method of embedding hardcoded passwords in scripts is just so bad for security.

      • smiller
        June 1, 2018 at 12:46 am

        Allan – I’m glad that the details were clear to you from everything else you’d read. If I’m being honest, there were two things that weren’t really clear to me until I went through this exercise:

        1) Just how much the order of operations matter specific to user creation using non-sysadminctl methods. After everything I’d read, I was not really expecting to find that an AD user, creating a mobile account on their 1st login, going through the complete manual Setup Assistant, while physically typing on the machine, wouldn’t be granted a SecureToken.

        2) How much the particular 10.13.x base OS image matters specific to SecureToken. I’m going to post below with some (hopefully) helpful hints on this for anyone that’s still using DeployStudio or similar tools that are not yet able to enable SecureToken for users on creation.

  14. smiller
    June 1, 2018 at 2:32 am

    Here are a couple of things that I wish I’d had before embarking on the SecureToken/FV2 odyssey over the last couple of weeks:

    1) I can confidently confirm that using an AutoDMG created base of 10.13.2 (17C88) on a MacBookPro11,4 and MacBookPro11,5 (pre-touch bar) that one can come out the other end in 10.13.4 (17E202) WITH SecureToken enabled users, at least with the tools we are currently using. It’s all about enabling FileVault at the right moment in the process. Will validate this on TouchBar units next week.

    2) Using OS builds 10.13.3 and higher result in SecureToken problems as outlined by everyone here ad nauseam.

    3) Here’s a script snippet you can run using ARD as root. It will list “just the facts, ma’am” – most things one would probably like to know vis a vis the state of SecureToken and FileVault2.

    —–
    #this script lists the hardware model, OS version and build, then audits all local admin or AD users for their SecureToken and FileVault2 Status.
    date
    sysctl -n hw.model
    system_profiler SPSoftwareDataType | grep “System Version”
    echo “Checking FileVault2 status…”
    fdesetup status -verbose
    fdesetup list -verbose
    userList=`dscl . list /Users UniqueID | awk ‘$2 > 499 {print $1}’`
    echo “Checking SecureToken status for local admins and AD users…”
    for a in $userList ; do
    sysadminctl -secureTokenStatus “$a”
    done
    —–

    Output looks like this (I had to scrub a bit):

    Wed May 30 17:50:20 EDT 2018
    MacBookPro11,5
    System Version: macOS 10.13.4 (17E199)
    fdesetup: device path = /
    FileVault is On.
    FileVault master keychain appears to be installed.
    Encryption in progress: Percent completed = 14
    fdesetup: device path = /
    lepatron,669A603E-[redacted]
    rguy,8BB9D50A-[redacted]
    Checking SecureToken status for the following users…
    2018-05-30 17:50:21.826 sysadminctl[1650:14794] Secure token is DISABLED for user emergencyadmin
    2018-05-30 17:50:21.864 sysadminctl[1651:14799] Secure token is DISABLED for user theguardian
    2018-05-30 17:50:21.891 sysadminctl[1652:14803] Secure token is ENABLED for user lepatron
    2018-05-30 17:50:21.937 sysadminctl[1653:14809] Secure token is ENABLED for user Guy, Regular

    In my example:
    – The system, a MacBookPro11,5 was deployed using a fully automated DeployStudio workflow. AD Binding, network config, profile manager enrollment, software installations…all handled in the DS workflow.
    – The first step in the workflow is a Restore Master op, using a 10.13.2 (17C88) AutoDMG created master. ** I believe that 10.13.2 may be the last OS you can use and still use this approach. YMMV **
    – The accounts “emergencyadmin” and “lepatron” were both created using DeployStudio’s native account creation options, with as much setup assistant suppressed as possible (Siri and the Privacy screens are not suppressable in DS 1.7.8).
    – “theguardian” is a local account that got created by one of our security endpoint installers – a standard package step in a DS workflow. The important bit is that this user gets created before real humans get to try and log in.
    – ”Regular Guy” is an AD user (domain\rguy) that now has an enabled SecureToken (isn’t that nice!?). That account was created the first time that Mr. Guy logged in to the Mac with AD credentials, and created his mobile account… but AFTER “lepatron” had already enabled their SecureToken.

    • June 11, 2018 at 10:08 pm

      How did “lepatron” enable SecureToken for “rguy”?
      Where in the process?
      and
      What command was run?

      Thanks!

      • smiller
        November 14, 2018 at 6:36 pm

        @poolpog – i didnt see this question until just now, so the answer may be moot, but here goes, anyway. The important thing to call out here is this, from the above:

        – The first step in the workflow is a Restore Master op, using a 10.13.2 (17C88) AutoDMG created master. ** I believe that 10.13.2 may be the last OS you can use and still use this approach. YMMV **

        – This test was performed on pre-touch bar MacBooks – MacBookPro11,4 and MacBookPro11,5. I can’t say for sure if the TouchBar MacBooks were successful using this approach – and I’m inclined to say that they were not.

        I have adjusted my DS deployment process (as a stopgap before retiring DS) to skip the Master restore part of the process; this instead relies on a separate OS install that happens prior to DS. I have outlined that in some more detail in a separate comment on this thread. Hope this helps.

  15. John
    June 4, 2018 at 10:43 pm

    Have you run into an issue where the only local admin account does not have a secure token? FileVault is enabled and the user is able to login on the FV login screen. This all came up when JAMF alerted me that the user’s Personal Recovery key was missing. We were unable to issue a new recovery key manually or using a script that worked with other users. Here’s the output when we tried to do it manually:

    sudo fdesetup changerecovery -personal -verbose
    fdesetup: use personal recovery key
    fdesetup: device path = /
    Enter the user name:username
    Enter the password for user ‘username’:
    Error: Unable to change key.
    echo $?
    99 Internal Error

    Running securetokenstatus:
    sysadminctl interactive -secureTokenStatus username
    Secure token is DISABLED for user User Name

    sudo diskutil apfs updatePreboot / did not help to enable secure token.

    I read that disabling FV and then re-enabling should help but sudo fdesetup disable produced an error:

    FileVault was not disabled (-69550)

    Any help on this would be greatly appreciated!

  16. Jeff Rippy
    June 11, 2018 at 1:56 pm

    John,

    I was running into the issue where the only account on my machine was the management account laid down with the Jamf PreStage Enrollment. This account did NOT have a secureToken (with 10.13.4) but could enable FileVault in the GUI.
    Additionally, I was able to get a secureToken by `# sudo sysadminctl mgmtAcct -password – -adminUser mgmtAcct -adminPassword -`

    Again, only a single account. Run sudo as the management account, try to enable the management account for a secureToken using the management account as the admin user. It worked for me.
    I had to enter the same password 3 times for the different needs, but it worked.
    I think this just showed that the management account was in some way in a FileVault deferred status.

    Anyway, with 10.13.5, this appears to not be an issue and my management account has a secureToken as soon as enrollment is complete.

  17. July 11, 2018 at 12:57 am

    Have they broke this in 10.13.6 Rich?

    musi-temp:~ appleadmin2$ sysadminctl -secureTokenStatus AppleAdmin2
    2018-07-11 12:50:08.306 sysadminctl[763:12717] Secure token is DISABLED for user AppleAdmin2
    musi-temp:~ appleadmin2$ sysadminctl interactive -secureTokenOn AppleAdmin2 -password –
    Enter password for AppleAdmin2 :
    2018-07-11 12:50:32.759 sysadminctl[766:12885] setSecureTokenAuthorizationEnabled error Error Domain=com.apple.OpenDirectory Code=5101 “Authentication server refused operation because the current credentials are not authorized for the requested operation.” UserInfo={NSLocalizedDescription=Authentication server refused operation because the current credentials are not authorized for the requested operation., NSLocalizedFailureReason=Authentication server refused operation because the current credentials are not authorized for the requested operation.}

  18. mark
    July 31, 2018 at 3:20 pm

    Hi
    I have a 10.13.6 mac with an local admin account created by macOS setup Assistant it has a secureToken, but then i bind the machine to our AD which has the setting enabled for mobile accounts, then login as a AD user and get the prompt Enter a secureToken Administrators name and password to allow this mobile account to use file vault.
    You can select bypass but would prefer we dont get this prompt in the first place for non filevaulted machines.

    • Rob
      November 6, 2018 at 2:41 pm

      Try this to supress the dialog.. create a config profile, custom settings…
      {cachedaccounts.askForSecureTokenAuthBypass=true}

      works for me

  19. Peter
    August 29, 2018 at 5:46 pm

    Been fighting with this also. Our Deploy Studio workflow lays down 10.13.6 image and a local user account but that account does not have a secure token. So far there does not look like there is a way to create an account with a security token or add one to accounts unless you already have an account with a security token. We are looking at chaining our process to require the macOS installer to be run which will run the full OS setup. The account created during the setup will then have a security token. From there you can use that account to run scripts to create new accounts with security tokens and or add tokens to accounts the do not have them. Also seems that if you change an accounts password with the command line (not GUI) the security token for that account goes away and a new one needs to be created

  20. Marc
    October 10, 2018 at 10:03 am

    I’m having issues with no account having a secure token after an upgrade, even when I delete the AppleSetupDone file and create a new admin accounting Setup Assistant the new account doesn’t receive a Secure Token. Anyone have any ideas as I”m all out!

    • Peter
      November 1, 2018 at 2:32 pm

      Seems apple has not given IT administrators a way to create a secure token when you get into this type of situation. This is an issue for a lot of admins that used deploystuido or some other product to deploy images with out using the setup assistant to create the first Master account (which also creates a secure token) Apple needs to fix this.
      Marc have you tried upgrading that computer to 10.14? I know upgrading from 10.12 to 10.13.6 automatically created tokens for the admin accounts. Maybe upgrading to 10.14 will also do this?

    • smiller
      November 14, 2018 at 6:23 pm

      Marc – it’s hard to know how to answer your question on this without more detail on what you mean by “after an upgrade” in your description. But one thing appears constant based on my extensive pain/agony and troubleshooting: SecureToken is a chain of trust process. this means that…

      Your first-ever created user *must* have a SecureToken, or you’ll never be able to enable any other accounts on the system, full stop.

      Caveats: If you are using a deploy process that includes any account creation before a human touches the Mac, you’re probably going to be up the creek. This includes tools like DeployStudio – but it’s also important to remember that installer packages can also create user accounts. One of my issues in an environment I maintain was that one of the security software packages created a hidden admin account, which made it impossible to enable a SecureToken after deployment.

      If you are using DeployStudio, and have an extensive deploy process that you haven’t migrated to more modern tools, you can work around this (at least in 10.13.6) by:

      1) Starting with a “clean slate” vanilla Mac OS installation
      2) Running the Apple setup assistant manually on that Mac so that you can be assured an admin account with a valid SecureToken (make sure validate at the Terminal before moving on – my preferred script reiterated below.)
      3) Booting that Mac using external media or NetBoot, running the DeployStudio runtime while booted that way, and using a workflow that does *not* include an OS Master restore.
      4) After completing your deployment workflow, boot normally, and re-run the ST/FV validation script. Review your list of users for anyone reporting “Disabled” and decide which ones need to actually be able to successfully log in/get past pre-boot FileVault.
      For each ST disabled user that you want to enable for FileVault, you can either…
      a) Log in as each user. Upon login, you’ll be prompted to enable the SecureToken with an already-ST enabled login and password,
      – or –
      b) Log in as your ST *enabled* user, and run this command in Terminal:

      sudo sysadminctl -adminUser [admin user] -adminPassword – -secureTokenOn [user you are granting a SecureToken] -password –

      5) re-run the validation script
      6) Just to be all belt-and-suspenders about the whole thing, turn on Filevault. Reboot, and login as one of users you manually enabled using this process, to make sure you can actually do it. that never hurts. 🙂

      here’s the script again (from earlier in the thread) to audit the state of SecureToken and FileVault2 for all the users. I hope this all helps.

      #this script lists the hardware model, OS version and build, then audits all local admin or AD users for their SecureToken and FileVault2 Status.
      date
      sysctl -n hw.model
      system_profiler SPSoftwareDataType | grep “System Version”
      echo “Checking FileVault2 status…”
      fdesetup status -verbose
      fdesetup list -verbose
      userList=`dscl . list /Users UniqueID | awk ‘$2 > 499 {print $1}’`
      echo “Checking SecureToken status for local admins and AD users…”
      for a in $userList ; do
      sysadminctl -secureTokenStatus “$a”
      done

  21. WeiW
    November 1, 2018 at 2:00 pm

    Apple make FileVault things worse since 10.13.6.

  22. smiller
    November 14, 2018 at 6:43 pm

    Important development / question for everyone: I’ve had a few users suddenly have their SecureTokens mysteriously become Disabled, after being enabled and working normally for months. Does anyone know what could cause a SecureToken to be revoked, e.g, a number of bad password attempts, perhaps? in my case, the users that have exhibited this disturbing development are AD users. If anyone has any insight to how someone goes from Enabled to disabled without admin intervention, I would very greatly appreciate it.

  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: