How Do I Grant Secure Tokens To Accounts That Don't Have Them?

[john_sherrod]

Here's my scenario: I want to enable FileVault 2 encryption for a fleet of about 600 Macs. None of them have had FileVault enabled in the past. All of our users are logging in with Active Directory credentials. In the past we've always hit "Bypass" on the Secure Token dialog at first login, so none of those user accounts have a Secure Token. Is there a way to mass-enable Secure Token on all of these user accounts? I've been diving into old threads on this topic but many of them were written in the High Sierra era and most haven't been updated in months. Any help you can provide would be appreciated. Thanks!

[sshort]

Check out this post on securetoken behavior and filevault in 10.14.2 (and later): https://travellingtechguy.eu/mojave-10-14-2-and-secure-tokens-it-works/

[john_sherrod]

Thanks! This has been very helpful. I just did a successful test of enabling FileVault via Self Service policy on a test computer. For some reason it doesn't appear to have escrowed the key to Jamf though.

[TTG]

@john.sherrod Try to run 2 Inventory Updates when enabling FV via Policy. One to generate the security data, second to escrow it in Jamf Pro.

[carlo_anselmi]

Hello everyone and @frederick.abeloos @sshort , I am resurrecting this old thread to better understand how to fix a bunch of 10.14.6 machines where none of the users has the secure token and now I would need to enable FileVault.
I think the problem might come from the fact they have been upgraded from Sierra to High Sierra and the Mojave.
They have a (manually created) local admin and Active Directory network users
My current policy in self service to enable Filevault does not work with these machines.
With some of them, I can manually enable FileVault from System Preferences using the local admin (although the Institutional Recovery Key apparently is not being collected, only the personal key is visibible in my JSS) while others simply do nothing when I click the button in System Preferences to enable FV.
If I manually try to enable Filevault from Terminal on one of these Macs where FV can't be enabled from System Prefences I get this

TestMac:~ admin$ sudo fdesetup status
Password:
FileVault is Off.
TestMac:~ admin$ sudo fdesetup enable 
Enter the user name:admin   
Enter the password for user 'admin':
Error: A problem occurred while trying to enable FileVault. (-69594

I have read all relevant directions I could find (including Mr. Trouton's well known pages) and tried all the suggested workarounds, including deleting the .AppleSetupDone and creating an additional admin (which of course is not the first created), also tried with adding a local admin users with a Jamf policy (but again to my knowledge that admin does not have a secure token either)

I would like to understand why my policy does not work or at least start with finding a way to assign a secure token to the local admin without going through Recovery or re-installing those systems?
Many thanks for your help!
Ciao
Carlo

[TTG]

Hi @carlo.anselmi

Not sure what you mean with the institutional recovery key not showing in JPS. Are you deploying an institutional recovery keychain?

For the Secure Token part, adding FV user won’t work out of the box with JP Policies. This because all Secure Token manipulations need to be executed in the user context via a Secure Token enabled user.

Jamf Policies do not run in the user context so even the Jamf Pro Management account is irrelevant.

The only way to grant/generate a Secure Token on a truly tokenless system post initial deployment is via the sysadminctl command.

Normally this command is used by a secure token enabled admin to grant a token to another tokenless user.

However, on a truly tokenless system (nowadays very difficult to achieve on Catalina due to additional actions like authenticating with any local admin in terminal, sys prefs, ... which triggers the creation of a secure token) but on Mojave there is one way to do it.

Run the following command on a tokenless sytem and specify any local admin (without a token) and any other account (which also has no token).

The result will be that both accounts will have a token:

sysadminctl -adminUser adminUsername -adminPassword adminPassword -secureTokenOn receivingUsername -password receivingUsernamePassword

[TTG]

Next, enable FileVault by any means like profile, policy, manually...

Note that you might need to cancel the unwanted FV deferral if you tested things before and enabling FileVault failed.

Deferral might have gone awol.

[carlo_anselmi]

Hello @frederick.abeloos and many thanks for your detailed explanation!
Unfortunately it does not seem to work with a test client here (where "carlo.anselmi" is an AD managed network account)

MyTestMac:~ MyLocalAdmin$ sysadminctl -adminUser MyLocalAdmin -adminPassword MyLocalAdminPSW -secureTokenOn carlo.anselmi -password carlo.anselmiPSW
2020-06-16 23:10:10.487 sysadminctl[13964:78220] setSecureTokenAuthorizationEnabled error Error Domain=com.apple.OpenDirectory Code=5101 "Authentication server refused operation because the current credentials 
are not authorized for the requested operation." UserInfo={NSLocalizedDescription=Authentication server refused 
operation because the current credentials are not authorized for the requested operation., NSLocalizedFailureReason=Authentication server refused operation because the current credentials are not 
authorized for the requested operation.}

Although I am not sure how relevant it is (since FV has not yet been enabled) have also tested

MyTestMac:~ MyLocalAdmin$ diskutil list
/dev/disk0 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *500.1 GB   disk0
   1:                        EFI EFI                     209.7 MB   disk0s1
   2:                 Apple_APFS Container disk1         499.9 GB   disk0s2

/dev/disk1 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +499.9 GB   disk1
                                 Physical Store disk0s2
   1:                APFS Volume Hard Disk               91.1 GB    disk1s1
   2:                APFS Volume Preboot                 45.0 MB    disk1s2
   3:                APFS Volume Recovery                510.5 MB   disk1s3
   4:                APFS Volume VM                      2.1 GB     disk1s4

and then

MyTestMac:~ MyLocalAdmin$ diskutil apfs updatepreboot disk1s1
Started APFS operation
UpdatePreboot: Commencing operation to update the Preboot Volume for Target Volume disk1s1 Hard Disk
UpdatePreboot: The Target Volume's OpenDirectory (non-special kind) user count is 1 and the Recovery (any of 3 kinds) user count is 0
UpdatePreboot: There are OpenDirectory user(s) but no Recovery user(s)
UpdatePreboot: The above is an abort condition for some purposes but not UpdatePreboot; continuing
UpdatePreboot: No custom Open Directory path given
UpdatePreboot: Using GivenVolumeMountPointOrNilIfNotMounted for the MacOSSearchPath
UpdatePreboot: Using MacOSSearchPath's child dslocal path for the OpenDirectorySearchPath
UpdatePreboot: MacOS Search Path = (nil=NotMounted) = /
UpdatePreboot: Open Directory Database Search Path = (nil=MacOSSearchPathNotMounted) = /var/db/dslocal/nodes/Default
UpdatePreboot: Preserve EncryptedRootPList When No-OD = 0
UpdatePreboot: Successfully opened Open Directory database; setting AuthODNodeOrNil accordingly
UpdatePreboot: Mounting and ensuring as mounted the related Preboot Volume
UpdatePreboot: Preboot Volume = disk1s2 Preboot
UpdatePreboot: Taking mount hold on Preboot Volume
UpdatePreboot: Preboot Volume Target Directory = /Volumes/Preboot/E8577643-E5C6-3880-B289-9D2E992DCD34
UpdatePreboot: Considering APFS Crypto User 752D2329-74B0-4A47-8FEB-098801FE85F6
UpdatePreboot: Defaulting and requiring that this be an Open Directory User
UpdatePreboot: Treating this APFS Crypto User to be, and requiring to match, an Open Directory User
UpdatePreboot: This APFS Crypto User is not in the Open Directory database
UpdatePreboot: Error for this processed user was -69568
UpdatePreboot: Error among all processed users was -69568
UpdatePreboot: Aborting entire operation, regardless of abort mode, because an error occurred for one of more users and not even one contingency user was successfully processed
UpdatePreboot: Releasing mount hold on Preboot Volume
UpdatePreboot: Unmounting Preboot Volume
UpdatePreboot: Did unmount Preboot Volume err=(ignored)=0
UpdatePreboot: Doing memory releases
UpdatePreboot: Exiting Update Preboot operation with overall error=(ZeroMeansSuccess)=-69568
Error: -69568: An APFS crypto user was not found in the Open Directory user database

where it seems there's a missing user from the DB

At the end I have also found an article with the same issue and error messages I have and the following solution suggesting using the Recovery partition I was trying to avoid.

Any additional help would be greatly appreciated!
Thank you again
Carlo

[a_hebert]

@carlo.anselmi The user cannot have a network account. If you make the user have a mobile account then you can pass the secure token to them. I have been working to make FileVault work and this was a issue i was having also

[TTG]

Yes, can you specify if it is a pure network account or mobile account?

[carlo_anselmi]

@a.hebert @frederick.abeloos Thank you for your responses, yes the user is a moble network account. I think the problem might be specific to that machine and should repeat the suggested solution with another one
Meanwhile I have updated this machine (I could not fix/assign secure token) to Catalina and after that everything is fine. The local admin account received the secure token automatically after the upgrade and I could succesfull run the follwing to assign the secure token to the previously created) mobile account

sysadminctl -adminUser LocalAdmin -adminPassword LocalAdminPSW -secureTokenOn carlo.anselmi -password carlo.anselmiPSW

Also if I delete and re-create that mobile account carlo.anselmi, the usual/expected window appears at first login to assign the secure token asking the local admin credentials
I'll keep you updated, for now many thanks again!
Carlo