Cannot delete local admin account with SecureToken on but FileVault Turned off

[joethedsa]

I'm having an issue where during PreStage enrollment I have an admin account created for temporary purposes to get computers setup for a users.  After the setup process is done, we delete the account.  I'm encountering an issue where on some computers, I'm not able to delete the admin account.  After trying multiple methods (Jamf policy, Jamf Remote, jamf binary, and sysadminctl), I am still unsuccessful.  What I've found is that when I use the sysadminctl command to remove the account, I'm presented with the following error:

"<useraccount> can not be deleted (it's either last admin user or last secure token user neither of which can be deleted) 

When I use the "fdesetup status" command, FileVault is turned off.  When I look at the computer record in Jamf under Inventory > Disk Encryption, I see the account that I can't delete listed under "FileVault 2 Enabled Users:" which in my view doesn't make sense

I suspect because it's listed in Jamf as an enabled user there, this is the cause of the issue but I'm not sure how to confirm that and resolve that.  This happening on over 20 computers so manually going to each one to delete is less than ideal.

[nelsoni]

You cannot delete it because you cannot have a system that is tokenless. Apple is effectively saving you from yourself. This is enforced regardless if FileVault is enabled or not. You will need to create another user account that has a secure token before you can delete the other account.

[junjishimazaki]

@joethedsa , found this online article with the same issue you have. https://www.aixperts.co.uk/?p=214

[bwoods]

@joethedsa, from your description above, it sounds like you need to start passing off the secure token from the temporary account to the user account before attempting to delete the temporary account. After you've created the user account, log back into the temporary account and run the script below:

#!/bin/bash

userAccount=''
passWord=''

# This script passes the secure token from the token holder to another desired user

# Pass the token
sudo -u $(ls -l /dev/console | awk '{print $3}') sysadminctl interactive -secureTokenOn $userAccount -password $passWord

Now that the user account has a token, you can delete the temporary account. You will need to know the passwords for both accounts for this to work. ( Yeah, I know. Thanks Apple! ) I highly recommend reading all of the traveling tech guy's posts about secure tokens. These things can land you in Big trouble if you don't have the right workflow. 

I would also suggest using the extension attribute below to keep track of which account has the secure token:

#!/bin/sh

#  Who_Has_SecureToken.sh
#
#
#  Created by Benjamin Janowski on 5/16/18.
#

AllUsers=$(dscl . list /Users | grep -v _)

for EachUser in $AllUsers; do

TokenValue=$(sysadminctl -secureTokenStatus $EachUser 2>&1)
    echo "Checking $EachUser"

	if [[ $TokenValue = *"ENABLED"* ]]; then
        SecureTokenUsers+=($EachUser)
	fi
done

    if [[ -z "${SecureTokenUsers[@]}" ]]; then
        echo "<result>No Users</result>"
	        else
                printf '%s,' '<result>'"${SecureTokenUsers[@]}"'</result>'
    fi

exit

[joethedsa]

@bwoods , Thanks for your comment and the link.  The EA script is working as intended.  As for the second script, since the affected computers are in a lab environment most of the time it will be at a login screen so it would make sense to run something at "check-in".  Do you know what adjustments would have to be done to the script to allow that to happen.  I know the passwords for both the temp admin account and the admin account which I would transfer the SecureToken to.

[bwoods]

I think this is what you're looking for. You can add your own variables for the accounts.

sudo sysadminctl -secureTokenOn newuseraccounthere -password 'newuseraccountpasswordhere' -adminUser securetokenaccounthere -adminPassword 'securetokenaccountpasswordhere'

[PaulHazelden]

If you set the temp admin account to have an ID of 401 to 499, it will be hidden and will not get a secure token.

We have a Jamf Admin account that gets given the token in this case, plus the first user account logging in will get one. Apple assigns the secure token to accounts starting with an ID of 501, which is the normal first user account created and is normally the admin account. Our Jamf admin account is set to 501, but we use an admin account at 502, and this is the first account logged in to and it too gets a secure token assigned to it.

[easyedc]

Had a similar issue a few years ago (link) and Apple basically said that you need to ensure that you have a) an admin account and b) an account created through the gui in order to delete an account built during enrollment process. Do you meet those 2 criteria?