Granting Volume Owner status on Apple Silicon Macs

macOS on Apple Silicon Macs includes a concept known as volume ownership. You must be a volume owner to perform the following tasks on an Apple Silicon Mac:

• Make changes to startup security policy for a specific install of macOS.*
• Be able to authorize the installation of macOS software updates or macOS upgrades.
• Authorize running Erase All Contents and Settings.

* There may be multiple installations of macOS on one Apple Silicon Mac; each macOS install would have their own startup security policy.

For more information on volume ownership, please see Apple’s Platform Deployment article linked below:

https://support.apple.com/guide/deployment/use-secure-and-bootstrap-tokens-dep24dbdcf9e/web (see the Volume ownership section.)

How do you get volume ownership though? It turns out that Apple has this currently set up on macOS as a two-fer deal: If an account account has Secure Token, it is also granted volume ownership. For more details, please see below the jump.

Mad, bad and possibly dangerous – a cautionary tale of software installation

In my career, I’ve run across a lot of terrible installers in a variety of forms. The one I ran across today though is noteworthy enough that I want to point it out because of the following reasons:

1. It’s an installer application. I have opinions on those.
2. It’s for a security product where, as part of the installation, you need to provide the username and password for an account on the Mac which has:

• Administrator privileges
• Secure Token

Note: I have no interest in talking to the vendor’s legal department, so I will not be identifying the vendor or product by name in this post. Instead, I will refer to the product and vendor in this post as “ComputerBoat” and leave discovery of the company’s identity to interested researchers.

For more details, please see below the jump.

Re-syncing local account passwords and Secure Token on FileVault-encrypted Macs running macOS Mojave

As part of FileVault on Apple File System, Apple introduced a new account attribute called Secure Token. As mentioned in a previous post, Secure Token can present some interesting problems for Mac admins who work with FileVault-encrypted laptops. Among the potential complications are these scenarios:

• “I changed the password for my local account, but only the old password is being taken at the FileVault login screen.”
• “We’ve lost the password to the only local user account with a Secure Token, so now we can’t enable any other accounts on this Mac for FileVault.”

Usually, this happens because the local account password in question was changed outside of the Users & Groups preference pane in System Preferences and now Secure Token and the account password are out of sync with each other.

Up until the past few days, the only fix I knew of for that situation was to back up the data and wipe the drive. However, it looks like there is a workaround for encrypted Macs which fixes the password problem and sorts out Secure Token in these scenarios. In both cases, a personal recovery key will be needed as the way to authorize the needed changes. For more details, please see below the jump.

Unable to enable FileVault on macOS Mojave

As part of FileVault on Apple File System, Apple introduced a new account attribute called Secure Token. Secure Token can present some interesting complications for Mac admins and among them is this scenario:

“The laptop is decrypted, but we can’t re-enable FileVault now.”

Usually, this happens because the account password was changed outside of the Users & Groups preference pane in System Preferences and now Secure Token and the account password are out of sync with each other.

Up until today, the only fix I knew of for that situation was to back up the data and wipe the drive. However, it looks like there is a workaround that fixes the password problem and sorts out the Secure Token attribute for the account on a decrypted laptop. For more details, please see below the jump.

Detecting if a logged-in user on a FileVault-encrypted Mac has a Secure Token associated with their account

A challenge many Mac admins have been dealing with is the introduction of the Secure Token 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.

In my own shop, we wanted to be able to identify if the primary user of a Mac had a Secure Token associated with their account. The reason we did this was:

1. We could alert the affected help desk staff.
2. We could work with our users to rebuild their Macs on an agreed-upon schedule where their data was preserved.
3. We could hopefully avoid working with our users on an emergency basis where their data could be lost.

To help with this, we developed a detection script. For more details, please see below the jump.

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.

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.

---

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

.@rtrouton Not strictly true.

If you bind to AD and suppress SetupAssistant, the first mobile AD user logging in will indeed get a SecureToken.

There are undocumented subtleties Apple follows in bootstrapping the first SecureToken user from none. pic.twitter.com/yZ7khKCmne

— mikeymikey (@mikeymikey) January 20, 2018

---

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.