FV2 on High Sierra and secureToken - Admin Accounts

clegger06
New Contributor III

Jamf Nation,

Been troubleshooting FV2 on our High Sierra build for a bit now. I understand how to enable/disable a secureToken, that an account can only get a token using setup assistant and what the sysadminctl command can do etc.

What I want to know can be broken down in two questions...

1. Does an administrator have to be secureToken "enabled" at all times, or once secureTokens are assigned can we disable? Or, can the administrator be secureToken enabled.... but somehow not be enabled as a FV2 boot screen login account?

which leads me to my next question/issue...

2. We want to be able to see 2 users on our FV2 boot screen, one would be our Standard Users account and the other would be a generic "Standard" user account for our IT support. We do not want our admin account on the FV2 boot screen.

I cannot figure out how we can accomplish this simply. I have tried giving temporary admin rights to the generic account and removing rights from the admin accounts for encryption purposes. However, upon changing those rights back, I see the admin account in the FV2 boot screen.

I am going to try revoking rights from admin and having a user with admin rights encrypt the device. This way only the user will be at the FV2 boot screen. After that I will promote rights to the admin account and see if it appears at the FV2 boot screen. Of course I will have to "Enable" the generic user for FV2 boot screen. But if this works, its only going to help a user with admin rights and I am still stuck on standard users.

1 ACCEPTED SOLUTION

kendalljjohnson
Contributor II

@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

View solution in original post

6 REPLIES 6

kendalljjohnson
Contributor II

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.

clegger06
New Contributor III

@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.

kendalljjohnson
Contributor II

@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

clegger06
New Contributor III

@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.

kendalljjohnson
Contributor II

@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.

Phantom5
Contributor II

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