Endpoint Services, Munki, macOS Secure Token
This article provides information about Apple's Secure Token account attribute.
Munki Mac Endpoint Management
University of Illinois IT Pros managing macOS devices
- What is Secure Token
- Who Receives the Secure Token
- The Secure Token Dialog
- Bypassing the Secure Token Dialog
- Adding Secure Token to an Account
- Deployment Considerations
- Additional Resources
Apple's Secure Token account attribute, introduced in macOS 10.13, is required for a particular user to enable FileVault disk encryption on a Mac, and to unlock a FileVault-encrypted volume at startup.
For DEP-enrolled devices on macOS 10.15 (Catalina) or up:
All accounts receive the Secure Token attribute. This is due to the Bootstrap Token, which is created and escrowed in Workspace ONE and which grants the Secure Token attribute to every account on the device, whether admin or standard, local or mobile.
For all other devices, the Secure Token attribute is automatically applied to:
- The local admin account created by the Setup Assistant, and to any local accounts created in System Preferences - Users & Groups by that first account.
- The local admin account created during DEP setup, as long as that account is the first user to log in.**
- The following types of accounts do NOT automatically receive the Secure Token attribute upon creation:
- Accounts created using command-line tools, including packaged scripts and installers.
- Most mobile accounts. (If deployment involves suppressing the Setup Assistant and binding to the AD, as in a DEP-Workspace ONE workflow, the first logged-in account will receive the Secure Token attribute even if it's a mobile account. In this scenario, subsequent logins--including the local admin account--will NOT automatically receive the Secure Token at login, which presents support problems.)
Beginning with macOS 10.13.4, Apple introduced the above dialog that appears during each account's initial login if all of the following conditions are met, even if FileVault is not enabled:
- The filesystem is APFS.
- There is a local admin account present that has already logged in at least once.
- The account logging in will be an AD-based mobile account.
Selecting 'Bypass' in the dialog will allow the user to continue logging in, but without receiving the Secure Token attribute. That user will not see the dialog again. If they need to be Secure Token-enabled down the road, an account with the Secure Token will need to add it to their account.
In some cases such as lab environments, and where the Bootstrap Token doesn't grant Secure Token access to all accounts, it makes sense to proactively bypass the Secure Token dialog for all mobile users on devices that will never be encrypted. The EPS team has created a mobileconfig profile for Multi-Tenant Munki stakeholder use. To install the profile on a managed Mac, add secure_token_bypass to the Managed Installs section of the machine manifest, or to your unit's base manifest structure as appropriate. You may want to update your unit's manifest template(s) to reflect this change.
A Secure Token-enabled account can add the attribute to other accounts in one of two ways:
- In System Preferences - Security & Privacy - FileVault, enable users to unlock the disk
- With the command-line sysadminctl tool: sysadminctl -secureTokenOn [username_which_needs_secure_token] -password -
In both cases, the receiving account's password will need to be provided.
Deployment workflows that rely on command-line account creation and bypassing the Setup Assistant will result in Secure Token problems. The EPS team strongly recommends that units discontinue their use.