Understanding difference between being an FV2 user and having a Secure Token

[stevenjklein]

I've tended to think of these two things as equivalent, all FileVault users have Secure tokens, and all users with Secure tokens are FileVault users.

But now I've discovered that we a few dozen Macs where our both of these things are true:

1. Our management account is a FileVault 2 User, and 2.Our management account does NOT have a Secure token.

(I use an extension attribute I found here to get a list of users with a Secure token: https://www.jamf.com/jamf-nation/third-party-products/files/990/users-with-secure-token)

I had thought those things were mutually exclusive.

What am I missing here?

Additional info: Some of those Macs are running 10.13.x, others 10.14.x. Most have boot or all partitions encrypted, but 2 have no partitions encrypted.

[ClassicII]

Did some of those machines get upgraded from 10.12?

If so one of the bugs in 10.13 was that even though the user was a FV2 user they never were granted a SecureToken on the upgrade to 10.13.

The best way classify a FV2 or SecureToken user is to view them as a CryptoUser.

Run

diskutil apfs listCryptoUsers /

or
sudo fdesetup list -extended

Will give you a list the true list of users who can unlock the drive.

[easyedc]

So what I think is the issue here is who does what. Think in these terms:
- SecureToken is the "master key" and those users can approve someone getting another key (and by extension the ability to unlock the drive as well). - FV2 users have been given a key and can unlock the drive.

FV2 users can't give other users the key, but ST users don't have to be FV2 users. Does that help?

I may be wrong, but that's how I understand it.

[isThisThing0n]

You can see this demonstrated when you login as a mobile user for the first time on a machine that has FV enabled then disabled. You will still be prompted to assign a secure token to that user, even though FV is no longer on.

[stevenjklein]

@ClassicII gave me some useful info, raised another question: What's the difference between Cryptographic Users and Secure Token Users?

Mike Bombitch offers some useful info. Here's an excerpt, but click the link below to get even more details.:

APFS volumes that contain an installation of macOS will each have a unique "secure access token". Access to this token allows users to do things like unlock the volume (e.g. if FileVault is enabled) and to change startup security settings. Because this token is volume-specific, it can't be copied to another volume; it has to be regenerated. In addition to this Secure Token, APFS volumes also have a list of users or keys that are "bound" to the volume. These "cryptographic users" are defined within the volume metadata, not within any particular file on the volume. As a result, these bound cryptographic users cannot be modified by CCC nor transferred from one volume to another. This cryptographic user list is proprietary to Apple; only Apple tools can modify the list, and only Apple tools can generate a SecureToken. While the SecureToken-endowed users and the cryptographic users are usually in sync on a particular volume, these lists are decoupled, and it is possible to get them out of sync. If you clone a system to a pre-encrypted APFS volume, for example, the destination has only one "Disk" crypto user. None of the user accounts on the system that you copied will be (nor can be) included in the crypto users list of that volume. Likewise, if you clone an installation of macOS to a volume that already has an installation of macOS, then you will be overwriting the user accounts that are currently in the crypto user list with new, foreign user accounts. Those new user accounts are not only missing from the crypto user list, but it will be impossible to add them to the crypto user list if all of the previous crypto users were deleted. To avoid both of these scenarios, it's important to clone to a volume that has either crypto users that match those users that exist on the source, or to a destination that has no crypto users at all (e.g. a freshly erased, non-encrypted volume). Manually regenerating a SecureToken Apple does not offer a method for creating a SecureToken for a user on a volume that is not the current startup disk, so CCC cannot offer a postflight method that automatically creates that token. Apple does, however, offer a utility for granting access to the secure token for specific users on the current startup disk in a very limited number of circumstances. If the current startup disk has no crypto users (diskutil ap listUsers / returns "No cryptographic users"), or if one of the crypto users is still present on the current startup disk, then you can use the sysadminctl utility to generate a SecureToken for your administrator account, e.g. in the Terminal application:

sysadminctl interactive -secureTokenOn yourname -password -

Source: https://bombich.com/kb/ccc5/frequently-asked-questions-about-encrypting-backup-volume

[stevenjklein]

FWIW: I've created Extension attributes to return CryptoUsers and SecureToken users, and found 3 encrypted Macs that each have 1 CryptoUser but no Secure Token users.

I found a discussion of ST and Crypto on Def Flounder's website, and it offers a few suggestions for fixing this problem.

I'll just have to give them a try and see what happens.