FAQ: Troubleshooting FileVault

FileVaulting a macOS device adds an extra layer of security to prevent data loss/breach. However, sometimes FileVault can run into some hurdles before it can be properly enabled.

Table of Contents

• FileVault not Automatically Enabling
• User Unable to Enable FileVault / User(s) not Showing at the FileVault Login Screen
• Incorrect Password at the FileVault Login Window (Unable to Login)
• FileVault Recovery Key did not Escrow

FileVault not Automatically Enabling

When there are issues enabling FileVault, the first thing to check would be the status of Filevaut. 
To do this, you can send the following command to the device from the Devices page in the 'Run command...' dialog box:

fdesetup status

fdesetup disable

User Unable to Enable FileVault / User(s) not Showing at the FileVault Login Screen

One aspect that can hinder the proper enablement of FileVault is whether or not a user has SecureToken enabled. Without this, a user would not be able to complete the encryption process even if deferred FileVault enablement is active for a user.

Additionally, you may encounter users who do not show up at the FileVault login screen. This is because the FileVault login window will only show users with SecureToken.
Note: The regular macOS login screen and FileVault login window are two separate entities. The user must authenticate (decrypt the disk) via FileVault before accessing the regular OS.
Additionally, per Apple's restrictions, this special login window will not allow any internet connection.

To check on the status of which users have SecureToken enabled on a macOS device, you can execute the following command from the Devices page in the Scripts section as a Saved Script:

#!/bin/bash

for user in $(dscl . list /Users UniqueID | awk '$2 >= 500 {print $1}'); do
    sysadminctl -secureTokenStatus "$user" 2>&1 | awk -F'] ' '{print $2}' 
done

When executed, the output should be as follows:

This tells us whether or not a user has SecureToken enabled so that we may take action to remedy it. Details on the remedy are in the section that follows.

Enabling SecureToken for a Local User Deployed Using Addigy (Requires Addigy MDM)

If the device in question has Addigy's MDM installed and approved, it should have escrowed the Bootstrap Token upon MDM enrollment. This Bootstrap token is what allows us as the MDM provider to grant users SecureToken(s), but only when the user logs in. For example, if you deploy a user via OS Users, it will not have SecureToken until you log into that user on the device.

To verify if the Bootstrap Token has been escrowed, run this command:

sudo profiles status -type bootstraptoken

If the Bootstrap Token was escrowed properly, it should show as such:

If the second line says "NO", then you will want to attempt a manual escrow using this command:

sudo profiles install -type bootstraptoken

Enabling SecureToken For a Local User not Deployed Using Addigy

If a user that was not deployed via Addigy is found to have SecureToken disabled for their account and you would like to enable it, follow the steps below.
(Please note, this process must be done locally on the device, there is currently no other method to accomplish this otherwise):

1. Login to a user that has SecureToken Enabled for their account.

2. Next, you will need to login to a user with SecureToken, open up terminal, and execute the following command:

sysadminctl interactive -secureTokenOn username -password password

3. Once this command is executed you will be prompted to enter the password of the current user to unlock:

4. After entering the password and clicking unlock you should receive a confirmation of successfully completing the command with the "Done!" output:

5. Finally, check the SecureToken status from the devices page to confirm the user now has SecureToken enabled.

You can also check this locally by running the command for the specific user:

sysadminctl -secureTokenStatus username

Now that this process is complete, users with SecureToken enabled should be able to FileVault without any issues.

It is important to note that a user created via any other means aside from Apple's GUI in System Preferences > Users & Groups will most usually not have SecureToken enabled by default. 
This is a security implementation done by Apple to prevent users from being granted access to a device if they manage to create a user by any other means.

Incorrect Password at the FileVault Login Window (Unable to Login)

If a user is entering their password and the FileVault login window is refusing it, this is likely due to their password having been reset incorrectly and thus breaking SecureToken.

SecureToken is part of a chain of trust between the device and the user. If the password is reset in a way that does not maintain the chain of trust (e.g. via GoLive > Users), then the SecureToken will be broken. This will, in turn, cause a desync between the user's regular password and their SecureToken password.
Let's say that a user's password is "password123" and they forget it (somehow). So, you go ahead and reset it to "A Kinda Better !!!! Password" via GoLive > Users, which will break the SecureToken. The next time the user shuts down or restarts their device, they will reach the FileVault login window which is expecting their SecureToken password of "password123", not their new password "A Kinda Better !!!! Password".

When you are faced with this situation, we recommend following this article:
Fixing broken Keychains ( Secure Tokens ) using Recovery Mode

FileVault Recovery Key did not Escrow

If the recovery key did not automatically escrow upon enablement, please follow this guide for steps on how to escrow it:
FAQ: Escrowing a FileVault Recovery Key Not Currently in Addigy