Script to assign SecureToken

rcarey
New Contributor III

Hello,

I have a few MacBook pros set up as loaner devices, and have been testing the script I use to assign the secure token. I get inconsistent results with it, both in High Sierra and in Mojave. Sometimes it just doesn't generate the pop up that requests the user's password. Anyone with scripting knowledge have any thoughts on how to get a more consistent result? I didn't write the script and to be honest don't know enough to be as efficient as I'd like.

The policy is set to run at Startup and Login, and is set for Once per user per computer.

#!/bin/sh
# This script is intended to be used with JAMF Self Service. It will enable SecureToken for the currently logged in user account
# and either add it to the list of to FileVault enabled users or enable FileVault using a Personal Recovery Key.

# Your policy must include script parameters for a SecureToken enabled administrator username and password. For more information
# on using script parameters, please see https://www.jamf.com/jamf-nation/articles/146/script-parameters.

adminUser="$4"
adminPassword="$5"
userName1="$3"
userName2="$6"

# Uses AppleScript to prompt the currently logged in user for their account password.
userPassword1=$(/usr/bin/osascript <<EOT
tell application "System Events"
activate
display dialog "Please enter your MCW password:" default answer "" buttons {"Continue"} default button 1 with hidden answer
if button returned of result is "Continue" then
set pwd to text returned of result
return pwd
end if
end tell
EOT)

# Enables SecureToken for the currently logged in user account.
enableSecureToken() {
    sudo sysadminctl -adminUser $adminUser -adminPassword $adminPassword -secureTokenOn $userName -password $userPassword1
}

# Creates a PLIST containing the necessary administrator and user credentials.
createPlist() {
    echo '<?xml version="1.0" encoding="UTF-8"?>
    <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
    <plist version="1.0">
    <dict>
    <key>Username</key>
    <string>'$adminUser'</string>
    <key>Password</key>
    <string>'$adminPassword'</string>
    <key>AdditionalUsers</key>
    <array>
        <dict>
            <key>Username</key>
            <string>'$userName1'</string>
            <key>Password</key>
            <string>'$userPassword1'</string>
        </dict>
    </array>
    </dict>
    </plist>' > /private/tmp/userToAdd.plist
}

# Adds the currently logged in user to the list of FileVault enabled users.
addUser() {
    sudo fdesetup add -i < /private/tmp/userToAdd.plist
}

# Enables FileVault using a Personal Recovery Key.
enableFileVault() {
    sudo fdesetup enable -inputplist < /private/tmp/userToAdd.plist
}

# SecureToken enabled users are automatically added to the list of Filevault enabled users when FileVault first is enabled.
# Removes the specified user(s) from the list of FileVault enabled users.
removeUser() {
    sudo fdesetup remove -user $adminUser
    sudo fdesetup remove -user $userName2
}

# Update the preboot role volume's subject directory.
updatePreboot() {
    diskutil apfs updatePreboot /
}

# Deletes the PLIST containing the administrator and user credentials.
cleanUp() {
    rm /private/tmp/userToAdd.plist
}

#

enableSecureToken
createPlist
if [ "$(sudo fdesetup status | head -1)" == "FileVault is On." ]; then
    addUser
else
    enableFileVault
    removeUser
fi
updatePreboot
cleanUp
4 REPLIES 4

tjhall
Contributor III

Could it be that the Mac's been built differently?
The script requires an admin with a securetoken and only the first logged in account get's (can't be hidden as far as I know).
Check on the Mac's you got problems with if the admin user has got a securetoken assigned to it and isn't hidden (sudo sysadminctl -secureTokenStatus [username]).

sshort
Valued Contributor

@rcarey @tjhall If your users happen to be standard accounts that are granted admin rights on first login that can mess with the secureToken pop-up that's supposed to appear. At my org we had to rework our enrollment workflow to have their AD-mobile account gain admin permissions at logout vs login to consistently get the secureToken dialog to appear.

tjhall
Contributor III

We've had several issues with Filevault on older macs (imaged) due to the admin account either being hidden or not being the first ones created once they got upgraded to High Sierra and Mojave.
Since then we've changed the workflow and the first admin account get's the securetoken. No problem since.

rcarey
New Contributor III

@tjhall Our admin account does have a secureToken, but @sshort that's interesting because I also have it set to assign admin permissions at log in. Didn't know that could mess with the pop up.

Appreciate all the help!