I'll explain our current situation which may help give some insight:

Our encryption policy has both an individual recovery key and institutional recovery key. We setup and encrypt our computers with a generic local admin account and then bind to AD and deliver to the user. At their first login, when prompted for the SecureToken, we authenticate with the local admin account. After that, there is a script in Self Service to remove the FileVault permissions and then fully delete the setup admin account. This leaves just the mobile non-admin AD user with a SecureToken and able to unlock the disk at boot.

If another account ever needs to be given a SecureToken, we would have to make the mobile AD account an admin and then go through the steps to enable another account. We have both AD groups set with admin capabilities and a hidden local admin account with LAPS that can be used to perform the elevation. The admin rights could be removed from the original mobile AD account afterwards. This rarely has to happen as all our encrypted devices are usually assigned to a single user for the life of the device.

Rather than having all individually assigned computers have both the assigned users account and our admin account at the FileVault unlock screen at boot, we just grab the individual recovery key from Jamf if the user is not around to unlock the drive. The institutional recovery key is the failsafe if the record is ever removed from Jamf or somehow broken.

Hope that helps, open to feedback or questions as it's still a fluid system as we all learn the joy of SecureTokens.

@kendalljjohnson ,

I am curious about the script you use to remove the FV2 permissions. Can I see the script?

What I discovered today was, if we want to have a local admin account it will be on the FV2 login screen no matter what. Our only other option is to remove the local admin and leverage a hidden admin if needed for admin access? does that sound right?

My only last option is to leverage Jamf to create the local admin account, this way no token is assigned and thus my issue might be fixed. I will have to test this tomorrow. Seems like its taking advantage of a bug more than a functional solution. But if it works so be it.

Thanks for the information.

@clegger06

My apologies if I'm not understanding your question correctly, but when encrypted, only 1 account is required at the initial boot screen. So if you have the user's account enabled with a SecureToken for FileVault, then you can still have a hidden or non-hidden admin account exist without it having to also have SecureToken/FileVault enabled.

Here's the removal script I use:

#!/bin/bash



loggedInUser=$(stat -f%Su /dev/console)



#Check if the currently logged in user is enabled for FileVault. Is so, delete the SecureTokenUser. If not, provide the error.



checkFDE=$(/usr/bin/fdesetup list | grep $loggedInUser)



if [[ $checkFDE == "" ]]; then

    /Library/Application Support/JAMF/bin/jamfHelper.app/Contents/MacOS/jamfHelper -windowType utility -title "FileVault Error" -description "$loggedInUser is not enabled for FileVault, therefore the SecureTokenUser has not been removed. Further troubleshooting is required." -icon /Library/Application Support/JAMF/myCustomeLogo.png -button1 "Ok"



    exit 0



  else



    /usr/bin/fdesetup remove -user SecureTokenUser



    /usr/sbin/sysadminctl -deleteUser SecureTokenUser



    /Library/Application Support/JAMF/bin/jamfHelper.app/Contents/MacOS/jamfHelper -windowType utility -title "FileVault Setup Complete" -description "The SecureTokenUser has been removed from FileVault. Thank you." -icon /Library/Application Support/JAMF/myCustomLogo.png -button1 "Ok"



    exit 0

fi

@kendalljjohnson ,

First, you are correct I am not being very clear. I basically am looking to have only 2 accounts at the FV2 login screen and a third account that is local admin, and I don't want local admin to show on the FV2 screen.

2 Users at FV2 login:
- AD User Account
- Local Non-admin account

3rd User not on FV2 login screen:
- Local Admin

Up until today, I have tried every trick I know. I've spent quite some time trying to get this setup working. Up to this point, the closest I have gotten was to remove the token from Local Admin, but the account was still visible at FV2 login... but it couldn't be used to unlock the disk.

As of today, I used your script and it removed the stale Local Admin account from FV2. Thank you for the assist here.

@clegger06

Ah, I see. To get that scenario you could setup a process where once the AD account is given a SecureToken you would remove the admin rights from the original local account, which would take care of your 2 users. And then just create a policy to have a new local admin account created without enabling FileVault for it to make the 3rd user you want.

This Apple support article might be of help:
https://support.apple.com/en-us/ht203998

Or you can change the user ID to a number below 500 and then:

sudo defaults write /Library/Preferences/com.apple.loginwindow Hide500Users -bool YES