Script to Grant Local Admin Account a SecureToken Locks out End User

[sim_brar]

Hi everyone,

We're currently testing a modified version of a script (presented below) which we originally found here: https://github.com/Yohan460/Automatic-Secure-Token-Granting-Workflow.

To put it simply, this script grants the local admin account (which we deploy and manage via a LAPS workflow on Jamf) a SecureToken via the sysadminctl -secureTokenOn command.

The script:

#!/bin/bash

apiUser=""
apiPass=""
apiURL=$(/usr/bin/defaults read /Library/Preferences/com.jamfsoftware.jamf.plist jss_url | sed 's|/$||')
udid=$(/usr/sbin/system_profiler SPHardwareDataType | /usr/bin/awk '/Hardware UUID:/ { print $3 }')
extAttName=""LAPS""
LAPS_User="LAPS"
LAPS_Password=$(curl -s -f -u $apiUser:$apiPass -H "Accept: application/xml" $apiURL/JSSResource/computers/udid/$udid/subset/extension_attributes | xpath "//extension_attribute[name=$extAttName]" 2>&1 | awk -F'<value>|</value>' '{print $2}')
Local_User=$(ls -l /dev/console | cut -d " " -f 4)
Output=""

while [[ $Output == *"not permitted"* || $Output == "" ]]; do
    if [[ ! -f /Library/Application Support/JAMF/Receipts/.SecureTokenPromptCancelled ]]; then
        read -r -d '' AppleScriptCode <<'EOF'
            set firstDialog to (display dialog "Company XYZ requires your computer's password to enable the Local Administrator Account to access your disk. 

Please enter your local password and click Enable. 

If you have any questions, please contact IT." default answer "" buttons {"Cancel", "Enable"} default button "Enable" with hidden answer with icon POSIX file "/Library/Application Support/JAMF/icon.png")
            set dialogText to text returned of (firstDialog)
        return dialogText
EOF
    else
        read -r -d '' AppleScriptCode <<'EOF'
            set dialogText to text returned of (display dialog "Company XYZ requires your computer's password to enable the Local Administrator Account to access your disk. 

Please enter your local password and click Enable. 

If you have any questions, please contact IT." default answer "" buttons {"Enable"} default button "Enable" with hidden answer with icon POSIX file "/Library/Application Support/JAMF/icon.png")
        return dialogText
EOF
    fi
    Local_Password=$(osascript -e "$AppleScriptCode" || touch /Library/Application Support/JAMF/Receipts/.SecureTokenPromptCancelled && exit 0)
    Output=$(sysadminctl -secureTokenOn $LAPS_User -password $LAPS_Password -adminUser $Local_User -adminPassword $Local_Password 2>&1)
    ReturnCode=$?
    echo "$Output"
done

if [[ $Output != *"Done"* ]]; then
    ReturnCode=1
else
    touch /Library/Application Support/JAMF/Receipts/.AssignedUserGivenToken
fi
exit $ReturnCode

When we were stress testing this script (i.e. running it multiple times in a row, entering incorrect passwords, leaving the password field blank, etc.), everything would behave as expected (i.e. if the user's password was correct, the local admin account would be granted a SecureToken, if the password was incorrect, the AppleScript prompt would re-appear).

This being said, a few moments later, entering the correct password (i.e. to grant the local admin account a SecureToken) resulted in the AppleScript prompt re-appearing (even though the provided passwords were correct) with the following output:

sysadminctl[4427:35604] ### Error:-14167 File:/BuildRoot/Library/Caches/com.apple.xbs/Sources/Admin_sysadminctl/Admin-716/addremoveuser/main.m Line:373
sysadminctl[4427:35604] Operation is not permitted without secure token unlock.

Additionally, launching a new Terminal window would present a "Login incorrect" message, with the user being unable to log into their laptop after a reboot.

Any ideas?

Thanks!

[sim_brar · Accepted solution]

Updates:
1. The maximum number of failed attempts (number of passcode entry attempts allowed before all data on device will be locked) configuration profile payload was responsible for this issue.
2. The script would lock the user out whenever more than 10 incorrect passwords were entered into the AppleScript prompt.
3. Removing the relevant payload from the profile (i.e. lock the user out after 10 failed attempts) resolved the issue.