Use secure token, bootstrap token and volume ownership in deployments
Secure token
Apple File System (APFS) in macOS 10.13 or later changes how FileVault encryption keys are generated. In previous versions of macOS on CoreStorage volumes, the keys used in the FileVault encryption process were created when a user or organisation turned on FileVault on a Mac. In macOS on APFS volumes, encryption keys are generated either during user creation, setting the first user’s password, or during the first login by a user of the Mac. This implementation of the encryption keys, when they’re generated, and how they’re stored are all part of a feature known as Secure Token. Specifically, a secure token is a wrapped version of a key encryption key (KEK) protected by a userʼs password.
When deploying FileVault on APFS, the user can continue to:
Use existing tools and processes, such as a personal recovery key (PRK) that can be stored with a mobile device management (MDM) solution for escrow
Create and use an institutional recovery key (IRK)
Defer enablement of FileVault until a user logs into or out of the Mac
In macOS 11 or later, setting the initial password for the very first user on the Mac results in that user being granted a secure token. In some workflows, that may not be the desired behavior, as previously, granting the first secure token would have required the user account to log in. To prevent this from happening, add ;DisabledTags;SecureToken to the programmatically created user’s AuthenticationAuthority attribute before setting the user’s password, as shown below:
sudo dscl . -append /Users/<user name> AuthenticationAuthority ";DisabledTags;SecureToken"Bootstrap token
In macOS 10.15 or later, a bootstrap token is used to help with granting a secure token to both macOS accounts and the optional device enrolment-created administrator account (“managed administrator”). In macOS 11 or later, the bootstrap token can grant a secure token to any user logging in to a Mac computer, including local user accounts. Using the Bootstrap Token feature of macOS 10.15 or later requires:
Supervision
MDM vendor support
Suppose that your MDM solution supports bootstrap tokens. In macOS 10.15.4 or later, when a user who is secure token–enabled logs in for the first time, a bootstrap token is generated and escrowed to MDM. A bootstrap token can also be generated and escrowed to MDM using the profiles command-line tool, if needed.
In macOS 11 or later, the bootstrap token may also be used for more than just granting secure token to user accounts. On a Mac computer with Apple silicon, the bootstrap token, if available, can be used to authorise the installation of both kernel extensions and software updates when managed using MDM. The bootstrap token is also used to silently authorise an Erase All Content and Settings command when triggered through MDM on macOS 12.0.1 or later.
Volume ownership
Mac computers with Apple silicon introduce the concept of volume ownership. Volume ownership in an organisational context isn’t tied to the true legal ownership or chain of custody of the Mac. Instead, volume ownership can loosely be defined as the user who first claimed a Mac by configuring it for their own use, along with any additional users. You must be a volume owner to make changes to the startup security policy for a specific installation of macOS, authorise the installation of macOS software updates and upgrades, initiate an Erase All Content and Settings on the Mac, and more. The startup security policy defines the restrictions around which versions of macOS can boot, as well as how and if third-party kernel extensions can be loaded or managed.
The user that first claimed a Mac by configuring it for their use is granted a secure token on a Mac with Apple silicon and becomes the first volume owner. When a bootstrap token is available and in use, it also becomes a volume owner and then grants volume ownership status to additional accounts as it grants them secure tokens. Because both the first user to be granted a secure token and the bootstrap token become volume owners, as well as the bootstrap token’s ability to grant secure tokens to additional users (and thus volume ownership status as well), volume ownership should not be something that needs to be actively managed or manipulated in an organisation. Previous considerations for managing and granting secure tokens should generally align with volume ownership status as well.
It’s possible to be a volume owner and not be an administrator, but certain tasks require checking the ownership of both. For example, modifying startup security settings requires being both an administrator and a volume owner, while authorising software updates is allowed by standard users and only requires ownership.
To view the current list of volume owners on a Mac computer with Apple silicon, you can run the following command:
sudo diskutil apfs listUsers /The GUIDs listed in the diskutil command output of type “Local Open Directory User” map back to GeneratedUID attributes of user records in Open Directory. To find a user by GeneratedUID, use the following command:
dscl . -search /Users GeneratedUID <GUID>You can also use the following command to see user names and GUIDs together:
sudo fdesetup list -extendedOwnership is backed by cryptography protected in the Secure Enclave. For more information, see:
Command-line tool usage
Command-line tools are available for managing bootstrap token and secure token. The bootstrap token is usually generated on the Mac and escrowed to the MDM solution during the macOS set-up process after the MDM solution tells the Mac that it supports the feature. However, a bootstrap token can also be generated on a Mac that has already been deployed. In macOS 10.15.4 or later, a Bootstrap Token is generated and escrowed to MDM on the first login by any user who is SecureToken enabled if the MDM solution supports the feature. This reduces the need to use the profiles command-line tool after device set-up to generate and escrow a bootstrap token to the MDM solution.
The profiles command-line tool has a number of options to interact with the bootstrap token:
sudo profiles install -type bootstraptoken: This command generates a new bootstrap token and escrows it to the MDM solution. This command requires existing secure token administrator information to initially generate the bootstrap token and the MDM solution must support the feature.sudo profiles remove -type bootstraptoken: Removes the existing bootstrap token on the Mac and the MDM solution.sudo profiles status -type bootstraptoken: Reports back whether the MDM solution supports the bootstrap token feature, and what the current state of the bootstrap token is on the Mac.sudo profiles validate -type bootstraptoken: Reports back whether the MDM solution supports the bootstrap token feature, and what the current state of the bootstrap token is on the Mac.
sysadminctl command-line tool
The sysadminctl command-line tool can be used to specifically modify secure token status for user accounts on a Mac computer. This should be done with caution and only when necessary. Changing the secure token status of a user using sysadminctl always requires the username and password of an existing secure token–enabled administrator, either interactively or through the appropriate flags on the command. Both sysadminctl and System Settings (macOS 13 or later) or System Preferences (macOS 12.0.1 or earlier) prevent the deletion of the last administrator or secure token–enabled user on a Mac. If the creation of additional local users is scripted using sysadminctl, for those users to be enabled for secure token, current secure token–enabled administrator credentials are required to be supplied either using the interactive option, or directly with the -adminUser and -adminPassword flags with sysadminctl. If not granted a secure token at time of creation, in macOS 11 or later, a local user logging in to a Mac computer is granted a secure token during login if a bootstrap token is available from the MDM solution. Use sysadminctl -h for additional usage instructions.