An ask I had was on ADE builds can we add a second account to the Mac for IT access and the answer is yes but the tricky part is of course Secure Token to allow that IT account to show on boot at the FileVault screen.

Why add a second account?
There are arguments for and against this, these are just a couple…

For – Allow IT to access the device if there is a problem
Let’s take a scenario of IT being handed a Mac that is powered off.
If there is only a single account on the Mac at boot they will not be able to access the Mac unless the user is present as password sharing is a total no no.

Of course you could use the FileVault Recovery Key if you have it escrowed into your MDM but a quirk of Big Sur is in order to enter the PRK you have to enter something into the password box wrong 3 times before the FV Key entry box shows*. However, on M1 you will be forced to reboot the Mac and reset the user’s password. Once done you can then boot using the new password. The issue is if the user has another device you could end up syncing that new password to your cloud directory service which would them cause issues on their other device, so not ideal and also what if for some reason the Key is not escrowed into Jamf, it does happen.

*In macOS 12 Monterey you can easily show the FV key entry box by pressing shift-option-return you no longer need to fail the password 3 times and on entering the Key the Mac will just boot to desktop – much better 😊

For – macOS Recovery
If a user leaves your organisation and you need to re-deploy the Mac at macOS Recovery to wipe and reinstall you will be asked to auth as the user. Again, if you don’t know the password you can use the FV key, but what if its missing, what if MDM is not showing it or the record has already been deleted from your MDM. Without the FV Key or user password you will have to contact Apple and prove you own the device to reset it.

Against – Security Risk
Adding any additional accounts can be considered a security risk as it’s another entry point.

We still need a second account
For this article let’s go with we need a second account and I’ll explain how I did it, I’m not saying it’s the way you should do it as its not elegant and I do hope there are better solutions.

The goal is a user driven IT zerotouch build with FileVault enabled:

• Silently add a second account for IT access
• Ensure that second account gets a secure token so it can unlock the disk at boot but without requiring logging into first**
• Ensure the second account shows at macOS Recovery
• Ensure the second account password is not static but randomized and held in Jamf

**An ADE build and enrol to Jamf will bootstrap the secure token so any additional accounts created will get a secure token but only after physically logging into the device. Once logged in the account will then show at FileVault screen on next boot. In our scenario this is a user driven IT zerotouch build so only the user has logged in but we still need to show the IT account on boot.

Adding the second account is fairly trivial. We can set a Jamf policy to create an account and give set a password and make it admin, but this means every Mac will have an IT account with the same password which is clearly very very bad and currently Jamf MDM does not have a built in way to randomize this so we are going to use a Local Administrator Password Solution (LAPS) to randomize the password so it’s different on every Mac and keep that password in Jamf….more on that later.

There is also a strange quirk of adding an account by Jamf policy and that is it won’t show in macOS recovery. You can read more about this on MacAdmins Slack channel but we have a fix…more on that later as well.

Our High Level Build/Deploy flow is:
Out of the box Mac is powered on

• Goes to Remote Management Screen and enrols to our Jamf MDM
• Jamf Connect Login to provision the account to the Mac using cloud IAM
• User enters their details this creates their account and they login
• DEPNotify kicks off and the apps are installed and Mac is configured
• User is forced to restart at end of DEPNotify and FileVault is required to be enable

During DEPNotify we can trigger our Jamf policy to create our second account and we can also install our LAPS process.

LAPS
There are a number of LAPS solutions for the Mac, I user macOSLAPS by Joshua Miller. I would get this up and running first and understand how it works beforehand before adding it to this process as it requires a Jamf Extension Attribute and Profile scoped to the Mac so I’ll assume it’s all been tested and working as you require.

So we have our Mac enrolled to Jamf with our user account and our IT account added. macOSLAPS is setup but still not yet invoked as password reset has not been run so the IT account using the static password we set in the Jamf policy. Now we need the IT account enabled with a secure token and “fake” a login so it shows at boot and then randomize the password so its unique for the device and get that password into Jamf

We can accomplish this in one single activity via a Jamf policy and a couple of script but it will require user interaction as the user needs to authorise the secure token request and of course we won’t know their password so we are going to have to ask them for it.

Lucky for us Travelling Tech Guy has done some work for us. Using this script by TTG, which is at your own risk we can ask the user to enter their password and therefore get a secure token for out IT account.

What you need to do is add this script to Jamf, create a policy and add the script to the policy and set Parameter values with your IT account name and password. I also customised the script text and added a company logo and a few extra AppleScript routines avoid blank password was entered and added a confirmation box. I’m not going to go into the detail of script as you can find out more on TTG site. All I will say is be cautious, it may not be for you.

When out policy is run it will prompt the user enter their password and then use the values set in the parameter of the script in Jamf (your IT account name and password) and give allow the account a Secure Token.

Earlier I said a Jamf quirk on account creation via a policy that it won’t appear at macOS recovery so we need to add an extra couple of lines to fix this.

Towards the bottom of the  TTG script add the following line swapping out YOURITACCOUNT for the exact name of your IT account, ensure it’s the same case.

dseditgroup -o edit -a 'YOURITACCOUNT' -t user 'admin'

We will also need to run a update preboot, so add in

diskutil apfs updatepreBoot /

Below this is where I added some custom AppleScript to open a dialogue box to show a confirmation to inform the user what that all is good and the process has complete.

So now after this has run and complete, the IT account has a secure token, it has been added to show at macOS Recovery but in my testing it still won’t show at FileVault on boot as the account has not been logged into and of course it is using our static password. To fix all this we are going to create second script in Jamf and add to the same policy as our fist first script but run it after.

The script again will use Parameters set in the Jamf policy, these again will be the IT admin account and password.

To fake the login we use, note the variables

/usr/bin/dscl /Local/Default -authonly $addAdminUser $addAdminUserPassword

Now all that is done we can randomize the IT account password using macOSLAPS

/usr/local/laps/macOSLAPS -resetPassword

Finally we need to get that new random password back into Jamf so we need to do

jamf recon

My second script is below with the Jamf $4 and S5 values, note I’ve added in an ugly section that does an escrow to Jamf, you may not need this and it’s not pretty as it is an interactive terminal script made to run without interaction…yes ugly but works.

#!/bin/bash
# additional Admin credentials
addAdminUser=$4
addAdminUserPassword=$5
# The admin account needs to authenticate to validate its password to enable SecureToken on the account
# Using dscl and -authonly is the least intrusive way to do that.
/usr/bin/dscl /Local/Default -authonly $addAdminUser $addAdminUserPassword
# Kick off the bootstrap token escrow install. The UX is interactive.
# Use expect to supply username and password when prompted.
/usr/bin/expect << BOOTSTRAP
log_file /Users/Shared/expect.log
spawn profiles install -type bootstraptoken
sleep 1
expect “Enter the admin user name:”
sleep 1
send “$addAdminUser\n”
sleep 1
expect “Enter the password for user”
sleep 1
send “$addAdminUserPassword\n”
sleep 1
expect “profiles”
sleep 1
interact
BOOTSTRAP
sleep 1
# Randomize the account password using macOSLAPS
/usr/local/laps/macOSLAPS -resetPassword
# Update Jamf so macOSLAPS password is addded to Jamf
jamf recon

You could combine this and make it a single script but just for ease of use I left as two and this second script really takes a few seconds to run….quicker if you remove all those sleeps.

Wrap Up
So that’s it, we have our policy and script, so lets’ recap what it does:

• Asks the user for their password
• Allows a Secure Token for our IT admin account
• Set the account to show at macOS recovery
• Set the account it to show on next boot at FileVault
• Randomizes the password and adds it to Jamf

You can either run this from Self Service but as part our build and deploy process if you remember at the end of DEPNotify we do a restart so therefore I set the script to trigger at Login and run once….I mean you can only run it once as the hardcoded values for the IT account will get changed via the macOSLAPS process!

Check
Once run check in Jamf that your macOSLAPS EA is showing the new password. You could SSH to it or if you have access to the Mac reboot it and you will see you IT account show at boot. You can then use the macOSLAPS password to unlock the disk and continue to boot and if boot into macOS Recovery use the password to run the wipe and reinstall.

How do I login as the IT account now it’s a random password?
Joshua Miller has also created a tool to get the password but its only if you are adding it into AD but we are not using AD anymore are we… are we? If so why?

You could allow certain IT staff with certain permissions to login into Jamf and get it but based on Joshua’s work I also created some bespoke tools using the Jamf API to retrieve the macOSLAPs password. It’s a simple two-part process and the tools could be distributed via Self Service but make sure that they are only accessible by those you trust, I’ve scoped tham to named individuals and they must login to Self Service to access….more on that next time.

Conclusion
As I said, it’s not elegant, it could be simpler and it may not be for you and I do sure there must be a better way….I think it’s called Monterey.