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.
- 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
- 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.
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.
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.
Now we need to create two (2) Smart Groups:
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.
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.
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.
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.
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.
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’.
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
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.
If you haven’t already, head over to Macjustsu’s GitHub Repository and copy the behemoth (5426 Line) Super script to Jamf Pro. Follow the instructions in the Wiki tab to configure your deferral options with a configuration profile. For example, here is the one I put in my lab for quick testing. Please adjust the values to fit your own needs.
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.
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.