Untangling SecureToken and Bootstraps for LAPS and Software Updates with Jamf Pro

WARNING: As of 9/23/2024 I am recreating this post to include more up-to-date information and details around the mechanisms involved. See the JNUC 2024 repository on my github for a preview I will be presenting in Nashville or watch my recorded presentation on YouTube.

The most critical thing is the SetAutoAdminPassword MDM Command used by Jamf LAPS will not work if you delete or change the GUID of the PreStage Administrator account. If you need a LAPS enabled Administrator account that will not break cryptographic password sync, use the Jamf Management Account instead.

Are you ready for this one? It’s a doozy of an information dump as it involves a perfect storm of asks from a customer which made me really think about the flow of SecureToken and how it impacts common practices I often see in the industry. As always, this post demonstrates a proof of concept and should always be paired with purpose built solutions that align with best practices for your industry. Example scripts provided involve passwords in clear text for the sake of the demonstration, but can be salted for added security.

Disclaimer: This blog is not intended to be advice on how to manage your environment. As the name suggests, these accounts are based on experiences I’ve had in my own lab. Always approach information you find outside (or inside for that matter) official documentation with skepticism and follow the golden rule: Never test in production.

Scenario Requirements:

Existing Local Admin Service Account (LASA) is required
The LASA password must be rotated regularly going forward
Computers must have FileVault enabled
Must be able to push available updates with deferrals and deadlines (Like Windows Update Rings)
Users must be Standard Users
Workflow must work for both PreStage and User-Initiated Enrollments
Deployments for new and refreshed computers must be Zero Touch

Challenges to Overcome:

Shared logins (especially admins that can unlock the disk) are not good
The LASA was used for initial setup and thus have a SecureToken as the first interactive login
SecureToken enabled accounts require the old password to be passed before changing (meaning they can’t use the Local Account Payload in Jamf Pro)
Subsequent logged in users are not SecureToken enabled by default
Giving non-enabled users a SecureToken requires authentication from an account with a SecureToken
macOS updates and upgrades requires Volume Owner permissions (and a Bootstrap/SecureToken)
Escrowing the Bootstrap Token for MDM Command to do updates requires the SecureToken enabled user to be an admin

Solution:

Ensure user is SecureToken Enabled
Temporarily make the user an admin just long enough to escrow the Bootstrap Token, then immediately demote them again (unless they were already an admin)
Remove the LASA from FileVault so it can be deleted without old credentials
Create a new LASA with a standardized password to be used for initial setup/troubleshooting
Rotate the LASA password either by Policy or LAPS after completion

Building the Workflow:

The workflow I came up with to automate as much as possible is deceptively simple even if the components involved are not. As shown in the diagram below we can break it down into three (3) key logic checks which we will walk through and build out further down.

1) Is the User SecureToken Enabled?

This preliminary check determines where we need to begin and really only applies to enrollments where the LASA was the first user to log in and the user never received the SecureToken. If this is the case, the user will not be enabled for FileVault and (in the case of Jamf Connect) FileVault will not be enabled automatically. If a Configuration Profile dictates that FileVault must be turned on, the user will encounter an error after entering their password at enablement. The following Extension Attribute will collect this information for us.

Shell

Extension Attribute – Users with SecureToken

#!/bin/bash

OS_MAJOR=$(/usr/bin/sw_vers -productVersion | awk -F . '{print $1}')
OS_MINOR=$(/usr/bin/sw_vers -productVersion | awk -F . '{print $2}')

result=""

listSecureTokenUsers ()
{
	userList=$(dscl . list /Users name | awk '{if (substr($1,1,1) != "_") print $1}')
	for user in $userList;
	do
		enabledUser=$(sysadminctl -secureTokenStatus $user  2>&1  | awk -v user="$user" '{if ($7=="ENABLED") print user}')
		result=( "${result[@]}" "$enabledUser" )
	done
	if [ ${#result[@]} -eq 0 ]; then
		result="No users have a Secure Token"
	fi
}

if [ ${OS_MAJOR} -ge 11 ]; then
	listSecureTokenUsers
else
	result="Older macOS version."
fi

echo "<result>${result[*]}</result>"

exit 0

If the user does NOT have a SecureToken then they will need to be enabled for FileVault in System Preferences with an existing user that is already FileVault enabled. This can be done from terminal, but it requires the credentials of both the currently-enabled user and the to-be-enabled user which unfortunately means this cannot be automated.

Shell

Enable User for SecureToken

sysadminctl interactive -secureTokenOn AlreadyEnabledUsername -password password

If by some black magic you find that either no user on the machine has a SecureToken (this should be impossible) or you do not know the credentials for the SecureToken enabled user then we must wipe the computer and start over from scratch. Remember that SecureToken enabled users REQUIRE the old password to be changed. If the computer is already FileVault enabled and you have the recovery key, you can initiate a password reset by entering a bad password at the FileVault login screen 3 times and clicking the link to reboot into recovery mode and enter the recovery key.

2) Is the Bootstrap Token Escrowed to Jamf Pro?

This is the part that stumped me the longest. If the user was not the first to interactively log in AND they are not an admin Jamf Pro will not be able to automatically escrow the Bootstrap token. During PreStage enrollments where the LASA remains untouched this process completes just fine (usually). If we find ourselves unable to escrow the Bootstrap in either situation for any reason, the only path forward I can identify is to make the user an admin temporarily and demote them when we’re done. Elevating the end-user for the sake of automation is an iffy practice at best… but in this case the trade off is a much more secure configuration and in my opinion (given Apple doesn’t offer an alternative) worth the risk.

For this workflow we will need an Extension Attribute to collect whether escrowing the Bootstrap Token is currently supported or if has been escrowed to Jamf Pro already.

Shell

Extension Attribute: Bootstrap Token Status

#!/usr/bin/env bash
export PATH=/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin

# Checks on if the bootstrap token is supported and escrowed by MDM

# Validating minimum OS version for attribute (10.15.0 or later)
OSVersion=$(sw_vers -productVersion)
OSVersionMajor=$(echo $OSVersion | cut -d '.' -f 1)
OSVersionMinor=$(echo $OSVersion | cut -d '.' -f 2)
if [[ $OSVersionMajor -eq 10 ]] && [[ $OSVersionMinor -lt 15 ]]; then
    echo "<result>Collected for macOS 10.15.0 or later</result>"
    exit 0
fi


StatusBootstrapToken=$(profiles status -type bootstraptoken 2>/dev/null)

if [[ -n $StatusBootstrapToken ]]; then
    Supported='supported on server: YES'
    Escrowed='escrowed to server: YES'
    if [[ "$StatusBootstrapToken" == *"$Supported"* ]] && [[ "$StatusBootstrapToken" == *"$Escrowed"* ]]; then
        Result="Escrowed"
    elif [[ "$StatusBootstrapToken" == *"$Supported"* ]]; then
        Result="Supported"
    else
        Result="Not Supported"
    fi
fi

echo "<result>$Result</result>"

Now we need to create two (2) Smart Groups:

Note that we only care if escrowing the Bootstrap Token is Supported. There’s no point running the escrow script if it’s either not supported due to age of the OS or not ready yet.

Finally, upload the Escrow Bootstrap script and deploy a policy to run it targeting our ‘Computers without Escrowed Bootstrap Token’ Smart Group. There are no parameters for this one and make sure to update the inventory with a Maintenance payload so that the computer falls out of scope. I’ve already included checks to verify the Bootstrap has not already been escrowed and not to demote the user if they were an admin already just in case such a scenario exists in the environment. If the Bootstrap needs to be created and escrowed, the user will receive a prompt to enter their password as a SecureToken enabled user.

Scripts/Jamf-EscrowBootstrap-StandardUser.sh at main · nverselab/Scripts · GitHub

Note: In my lab I have a group of production machines I excluded from all these policies for testing. Make sure to control your scope until you are ready for roll-out.

Shell

Jamf-EscrowBootstrap-StandardUser.sh

#!/bin/bash

##################################################################################################################
# This script will elevate the current user to administrator temporarily to escrow bootstrap token to Jamf Pro.  # 
# User will need to provide credentials as SecureToken enabled to complete                                       #
# User will be removed from admin after each attempt                                                             #
##################################################################################################################

#######################
# Check Pre-requisits #
#######################

# Exit successfully if Bootstrap token is already escrowed
verify=$(profiles status -type bootstraptoken | awk '/escrowed/ {print $7}')
if [[ $verify == "YES" ]]; then
    echo "Bootstrap already escrowed. Exiting successfully"
    exit 0
fi

# Get the logged in user's name
LoggedinUser=$(/usr/bin/stat -f%Su /dev/console)

# Check to see if a user is logged in and exit unsuccessfully if they are not

if [ -z "$LoggedinUser" -o "$LoggedinUser" = "loginwindow" ]; then
    echo "no user logged in, cannot proceed"
    exit 1
fi

## Check to see if logged in user has a SecureToken and exit unsuccessfully if they do not
secureToken=$(sysadminctl -secureTokenStatus $LoggedinUser 2>&1 | awk '{print$7}')
if [[ $secureToken != "ENABLED" ]]; then
    echo "$LoggedinUser is not SecureToken enabled, cannot proceed"
    exit 1
fi

######################################
# Begin Elevation and Escrow Process #
######################################

## Ask User for Credientials

# Prompt for Password until entered
userPass=""
until [[ $userPass != "" ]]
do
userPass=$(/usr/bin/osascript<<END
application "System Events"
activate
set the answer to text returned of (display dialog "IT needs to set some things up for you.  Please Enter your Password:" default answer "" with hidden answer buttons {"Continue"} default button 1)
END
)
done
    
# Loop until successful
result=""

until [[ $result == "success" ]]
do
    
## Temorarily Elevate User if they aren't already an Admin
    
if groups $LoggedinUser | grep -q -w admin; then 
    admin="yes"
else 
    /usr/sbin/dseditgroup -o edit -a $LoggedinUser -t user admin
fi
    
/usr/sbin/dseditgroup -o edit -a $LoggedinUser -t user admin
    
## Create and Escrow BootStrap Token
    
    #Create an EXPECT file to deal with interactive portion of bootstrap tokens
    /bin/cat << EOP > /Library/Application\ Support/JAMF/tmp/escrowToken
#! /usr/bin/expect
set adminName "[lindex \$argv 0]"
set adminPass "[lindex \$argv 1]"
#This will create and escrow the bootstraptoken on the Jamf Pro Server
spawn /usr/bin/profiles install -type bootstraptoken
expect "Enter the admin user name:" 
send "\$adminName\r"
expect "Enter the password for user '\$adminName':" 
send "\$adminPass\r"
expect eof
exit 0
EOP
    
    # Give script execute permissions
    chmod +x /Library/Application\ Support/JAMF/tmp/escrowToken
    
    # Pass arguments to EXPECT script
    /Library/Application\ Support/JAMF/tmp/escrowToken "$LoggedinUser" "$userPass"
    
    # Remove script after completion
    rm -rf /Library/Application\ Support/JAMF/tmp/escrowToken
    
## Remove User from Admin if they were not already an admin

if [[ $admin != "yes" ]]; then
dseditgroup -o edit -d $LoggedinUser -t user admin
fi

## Check that token as been escrowed
    
verify=$(profiles status -type bootstraptoken | awk '/escrowed/ {print $7}')
if [[ $verify == "YES" ]]; then
    result="success"
else
    # Prompt for Password AGAIN until entered
    userPass=""
    until [[ $userPass != "" ]]
    do
        userPass=$(/usr/bin/osascript<<END
application "System Events"
activate
set the answer to text returned of (display dialog "That did not work.  Please try entering your Password again:" default answer "" with hidden answer buttons {"Continue"} default button 1)
END
)
            done
fi
    
done

exit 0

3) Is the LASA FileVault/SecureToken Enabled?

This is the home stretch. If everything prior to this point lines up we just need to prep the LASA to be ready for password rotation by first disabling the account for FileVault so it can be recreated without a SecureToken. You could script this out to feed it an old password, but in this scenario there are multiple password variations in the wild which would make scripting it difficult. Much easier to do with a Policy so that no password is required.

We will, however, also want to make sure the LASA is not the only SecureToken account when the Bootstrap is escrowed just in case the account was interactively logged into at some point after enrollment by adding those criteria to another Smart Group.

Notice we are checking both that the LASA is not the ONLY user listed with a SecureToken AND that it is included among the others. No need to do this if the LASA already doesn’t have a SecureToken.

Simply create a new Policy scoped to the ‘Computers with Escrowed Bootstrap and SecureToken Enabled Admin Account’ Smart Group with the Local Accounts and Maintenance payloads to update inventory.

Notice that I am putting the home directory of the LASA somewhere other than /Users. This further obfuscates the accounts presence to the end user, but will also keep it from showing up as a local user in Jamf Pro. Either method is fine.

Deploying your SecureToken, Bootstrap, and Volume Owner dependent tools

If you’ve survived the remediation workflow and that’s all you wanted to accomplish then congratulations on being done! For the sake of this proof of concept, let’s put a few bows on it to finish the job.

LAPS (Local Admin Password Solution)

UPDATE: As of Jamf Pro 10.49 or later, a built-in Local Admin Password Solution is available to configure via the API. Please reference Local Administrator Password Solution for Jamf Pro for more information.

There are a few LAPS solutions out there and fewer for MacOS, but in my research I stumbled across one that uses a script and an extension attribute to do it in Jamf. It’s not perfect and will certainly raise a few eyebrows among security minded individuals due to how it stores the password locally in a folder only admins/root have access to (in which case malicious actors have already compromised the machine) and saves it in Jamf Pros inventory in plain text, but you could salt it with some additional scripting and tighten your security within Jamf Pro itself to mitigate the risk. In this scenario, it’s a free and simple way to manage local admin passwords better than it was before and sometimes baby steps is all you need to start heading in the right direction. Please carefully consider your organizations risk tolerance before implementing any LAPS product.

First, lets add our Extension Attribute so we can make a reporting Smart Group.

Shell

Extension Attribute – LAPS Password

#!/bin/sh

###################################
# EA to update LAPS Password      #
###################################

udid=$(/usr/sbin/ioreg -rd1 -c IOPlatformExpertDevice | awk '/IOPlatformUUID/ { split($0, line, "\""); printf("%s\n", line[4]); }')
LAPSFileLocation="/usr/local/jamf/$udid/"
LAPSFile="$LAPSFileLocation.$udid"

if [[ -f "$LAPSFile" ]]; then
   value=$(cat $LAPSFile)
   echo "<result>$value</result>"
   else
   value="Not recorded"
fi

The Smart Group we’ll create with this is just to report on devices that don’t have a LAPS password yet.

The LAPS script itself was written by some folks over at the University of Nebraska-Lincoln in 2016 and if you’ve Googled “LAPS for MacOS” before it’s surely come up before. This version though has had a few updates to remove reliance on a Jamf Pro API account and handle a SecureToken enabled LAPS account.

NOTE: This script will not pull down the current LAPS Password to change it for a SecureToken enabled account. It will only rotate it the first time if it still has the initial password. Again, better than nothing.

Shell

#!/bin/sh
####################################################################################################
#
#   MIT License
#
#   Copyright (c) 2016 University of Nebraska–Lincoln
#
#	Permission is hereby granted, free of charge, to any person obtaining a copy
#   of this software and associated documentation files (the "Software"), to deal
#   in the Software without restriction, including without limitation the rights
#   to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
#   copies of the Software, and to permit persons to whom the Software is
#   furnished to do so, subject to the following conditions:
#
#   The above copyright notice and this permission notice shall be included in all
#   copies or substantial portions of the Software.
#
#   THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
#   IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
#   FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
#   AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
#   LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
#   OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
#   SOFTWARE.
#
####################################################################################################
#
# HISTORY
#
#	Version: 1.4
#
#	– 04/29/2016 Created by Phil Redfern
#   – 05/01/2016 Updated by Phil Redfern, added upload verification and local Logging.
#   – 05/02/2016 Updated by Phil Redfern and John Ross, added keychain update and fixed a bug where no stored LAPS password would cause the process to hang.
#   – 05/06/2016 Updated by Phil Redfern, improved local logging and increased random passcode length.
#   – 05/11/2016 Updated by Phil Redfern, removed ambiguous characters from the password generator.
#
#   – This script will randomize the password of the specified user account and post the password to the LAPS Extention Attribute in Jamf.
#  Version 1.5
#   – 8 Sep 2020 Mark Lamont  Removed reliance on API user thus closing security hole. Now uses standard inventory function to update.
#   – Password does remain on the device though but is obscured and only available to root user.
#   – Not written to work with FileVault enabled admin users because of all the issues with secure token
#   Found on https://community.jamf.com/t5/jamf-connect/mac-os-laps/m-p/246910
####################################################################################################
#
# DEFINE VARIABLES & READ IN PARAMETERS
#
####################################################################################################

resetUser=""
basePassword=""
# CHECK TO SEE IF A VALUE WAS PASSED IN PARAMETER 4 AND, IF SO, ASSIGN TO "resetUser"
if [ "$4" != "" ] && [ "$resetUser" == "" ];then
resetUser=$4
fi

# CHECK TO SEE IF A VALUE WAS PASSED IN PARAMETER 5 AND, IF SO, ASSIGN TO "initialPassword"
if [ "$5" != "" ] && [ "$basePassword" == "" ];then
basePassword=$5
fi

udid=$(/usr/sbin/ioreg -rd1 -c IOPlatformExpertDevice | awk '/IOPlatformUUID/ { split($0, line, "\""); printf("%s\n", line[4]); }')

LogLocation="/Library/Logs/Jamf_LAPS.log"
LAPSFileLocation="/usr/local/jamf/$udid/"
if [ ! -d "$LAPSFileLocation" ]; then
mkdir -p $LAPSFileLocation
chmod 600 $LAPSFileLocation
fi

LAPSFile="$LAPSFileLocation.$udid"

newPass=$(openssl rand -base64 10 | tr -d OoIi1lLS | head -c12;echo)
####################################################################
#
#            ┌─── openssl is used to create
#            │	a random Base64 string
#            │                    ┌── remove ambiguous characters
#            │                    │
# ┌──────────┴──────────┐	  ┌───┴────────┐
# openssl rand -base64 10 | tr -d OoIi1lLS | head -c12;echo
#                                            └──────┬─────┘
#                                                   │
#             prints the first 12 characters  ──────┘
#             of the randomly generated string
#
####################################################################################################
#
# SCRIPT CONTENTS – DO NOT MODIFY BELOW THIS LINE
#
####################################################################################################

# jamf binary path
jamf_binary="/usr/local/jamf/bin/jamf"
# Logging Function for reporting actions
ScriptLogging(){

DATE=$(date +%Y-%m-%d\ %H:%M:%S)
LOG="$LogLocation"

echo "$DATE" " $1" >> $LOG
}

ScriptLogging "======== Starting LAPS Update ========"
ScriptLogging "Checking parameters."

if [ "$resetUser" == "" ];then
    ScriptLogging "Error:  The parameter 'User to Reset' is blank.  Please specify a user to reset."
    echo "Error:  The parameter 'User to Reset' is blank.  Please specify a user to reset."
    ScriptLogging "======== Aborting LAPS Update ========"
    exit 1
fi

# Verify resetUser is a local user on the computer
checkUser=$(dseditgroup -o checkmember -m $resetUser localaccounts | awk '{ print $1 }')

if [[ "$checkUser" = "yes" ]];then
    echo "$resetUser is a local user on the Computer"
else
    echo "Error: $checkUser is not a local user on the Computer!"
    ScriptLogging "======== Aborting LAPS Update ========"
    exit 1
fi

ScriptLogging "Parameters Verified."

# Update the User Password
RunLAPS (){
ScriptLogging "Running LAPS…"

if [[ "$secureTokenStatus" = "DISABLED" ]]; then

    ScriptLogging "Updating password for $resetUser."
    echo "Updating password."
    $jamf_binary resetPassword -username $resetUser -password $newPass
else
    ScriptLogging "*** Secure Token Enabled! ***"
    sysadminctl -resetPasswordFor "$resetUser" -newPassword "$newPass" -adminUser "$resetUser" -adminPassword "$basePassword"
    
    
fi

}

# Verify the new User Password
CheckNewPassword (){
ScriptLogging "Verifying new password for $resetUser."
passwdB=`dscl /Local/Default -authonly $resetUser $newPass`

if [ "$passwdB" == "" ];then
    ScriptLogging "New password for $resetUser is verified."
    echo "New password for $resetUser is verified."
else
    ScriptLogging "Error: Password reset for $resetUser was not successful!"
    echo "Error: Password reset for $resetUser was not successful!"
    ScriptLogging "======== Aborting LAPS Update ========"
    exit 1
fi
}

# Update the LAPS Extention Attribute
UpdateJamf (){
ScriptLogging "Recording new password for $resetUser into LAPS."
# debug
# ScriptLogging "*** new pass is $newPass ***"
touch $LAPSFile

#echo "$resetUser|$newPass" > $LAPSFile
echo "$newPass" > $LAPSFile

# EA must be in Jamf to record the value
jamf recon

}

checkSecureTokenStatus () {

secureTokenStatus=$(sysadminctl -secureTokenStatus $resetUser 2>&1 | awk '{ print $7 }' | sed s'/ //g')

ScriptLogging "secure token for $resetUser is $secureTokenStatus"

}

checkIfRunBefore () {

if [ -f "$LAPSFile" ]; then
    previousPassword=$(cat $LAPSFile)
    basePassword=${previousPassword}
    # Debug
    #ScriptLogging "base password is $basePassword"

fi

}
#====================================================
# The script itself

checkSecureTokenStatus
checkIfRunBefore
RunLAPS
CheckNewPassword
UpdateJamf

ScriptLogging "======== LAPS Update Finished ========"
echo "LAPS Update Finished."

exit 0

To make the parameters easy to read in the Policy, give Parameter #4 the label “LAPS Account Username” and Parameter #5 the label “Initial LAPS Account Password”

Create a Policy to run the Script and Update Inventory targeting the ‘Computers with Escrowed Bootstrap Token’ Smart Group and excluding the ‘ Computers with Escrowed Bootstrap and SecureToken Enabled Admin Account’ to ensure it only runs once all fun stuff from earlier is complete. Make sure to set the script to run ‘Before’ and set your LAPS account details for Parameters #4 and #5.

The end result will display the LAPS Password in the Computer’s Extension Attributes. If you added any language to salt the password, make sure you decrypt it before trying to use it.

Enabling FileVault and Escrowing the Recovery Key

If you use Jamf Connect, you can configure it to enable FileVault for the user which allows FileVault to encrypt the drive on first login without an additional password prompt from the user. Otherwise a standard FileVault Configuration Profile works just fine. Either way, we need to create a Configuration Profile to Escrow the recovery key to Jamf Pro in case of emergency. Just like before, scope this to ‘Computers with Escrowed Bootstrap Token’ and exclude ‘Computers with Escrowed Bootstrap Token and SecureToken Enabled Admin Account’.

If everything moves along correctly we should see the Encryption State as Encrypted with a valid Personal Recovery Key.

But what happens if the Recovery Key becomes invalid? Since our LASA is no longer FileVault enabled we need to continually make sure that it is and re-issue the recovery key if it is not. To do this, create a Smart Group where computers are encrypted, the bootstrap token is escrowed, and the recovery key is either ‘Invalid’ or ‘Unknown’.

Notice that we are using parenthesis to group (‘Invalid’ or ‘Unknown’) and (All Partitions or Boot Partition).

Head over to Jamf’s GitHub repository and grab the FileVault2_Scripts/reissueKey.sh script and upload it to Jamf Pro. For human readability in the Policy, set your #4 Parameter label to Org Name, #5 label to Max Attempts, #6 to Custom Message, and #7 to Logo Path.

Create the Policy and scope it to the ‘Computers with Invalid Personal Recovery Key’ Smart Group. Set the Script to run ‘Before’ and fill in the parameters as labeled and don’t forget to update the inventory so it falls out of scope when complete.

If a Personal Recovery Key is Invalid, the script will run and prompt the user to enter their SecureToken enabled credentials and upload a new Recovery key to Jamf Pro. The next time the computer updates inventory, Jamf will confirm the key is valid and remove it from scope. If it does not successfully validate, the user will be prompted again until it succeeds. You may want to include messaging to let your users know to call the Help Desk if the Recovery Key never validates.

Run S.U.P.E.R.M.A.N. to handle Software Update Deferrals and Deadlines

UPDATE: The following example is for S.U.P.E.R.M.A.N. v3 and older. v4 includes a complete re-write of all functions and configurations which do not align with this article. Please review the wiki for v4 or newer for complete and correct instructions for the latest version.

I have plans to write a walkthrough for Macjutsu’s S.U.P.E.R.M.A.N. script in another post so I’ll keep it high level for now. If you want to learn more, check it out on GitHub. For this workflow, one of the challenges was to enable the user for SecureToken so they can be a Volume Owner and escrow the Bootstrap token which allows S.U.P.E.R.M.A.N. to execute the Download and Install Software Updates MDM Command as needed rather than pushing the command via Bulk Actions.

Next, create a new API account in Jamf Pro with only ‘Create Computer Objects’ and ‘Send Computer Remote Command to Download and Install macOS Update’ permissions.

Finally, create a new Policy and Scope to the ‘Computers with Escrowed Bootstrap Token’ smart group. You technically only need to run the script once and it will run locally on the machine regularly and only prompt the user to take action if a reboot is needed. Personally, I want to make sure that the settings I set are being followed so I choose to run it daily or weekly from Jamf Pro.

Set your script parameters to include any non-configuration profile-based options (these will override the configuration profile if included), but be sure to include the Jamf API credentials to trigger the updates when needed. Since we escrowed the Bootstrap token Jamf will not need to prompt the user for Volume Owner credentials to complete the updates.

If you want to capture additional information from Super such as next run time, current version, etc… Grab the example Extension Attributes from the GitHub Repository as well and add an Inventory Update to your Policy.

And that’s it! As always, thanks for reading and coming along with me on my journey to making Apple function in an enterprise environment. If you have a similar worklflow or have suggestions to improve mine please let me know on Twitter, LinkedIn, or GitHub.