Set User Account Image when Users & Groups is Inaccessible

When a Mac is set up via ADE and the user account is provisioned via Jamf the user account image is assigned randomly from the images at /Library/User Pictures/

To change the image a user would usually open System Preferences > Users & Groups and click Edit and select an image but what if Users and Groups is restricted how can a user change the image?

The answer I’ve come up although limited is simple script in Jamf with a Policy available in Self Service that is very easy to implement and duplicate.

The Script

#!/bin/bash

# image name in the /Library/User Pictures/Nature/
# Can be Cactus.tif Earth.png Leaf.tif Lightning.tif Nest.tif Sandollar.tif Snowflake.tif Zen.tif
imagename=$4

# Get userid
userid=$(defaults read /Library/Preferences/com.apple.loginwindow lastUserName)

# Delete image
dscl . delete /Users/$userid JPEGPhoto

# Set Image to /Nature/Earth.tif
dscl . create /Users/$userid Picture "/Library/User Pictures/Nature/$imagename"

Let’s go through the script…First we set a Jamf Script Parameter Variable for $4 and use this in the script for the image name. This lets us add the image name in the Policy Script Parameter Value setting so we can easily duplicate our policy and add in the image name.

The script needs the user ID so we change the picture of the logged in user and that is made a variable and added to the dscl commands to first delete the current image and then set the selected image. Note in this example we are using images in the /Nature directory. You can obviously change this to Sport or Fun etc.

The /Nature images are:
Cactus.tif
Earth.png
Leaf.tif
Lightning.tif
Nest.tif
Sandollar.tif
Snowflake.tif
Zen.tif

Add instructions in the Options section for our $4 Parameter as below so it’s easy to select one of these.

Save the script.

So now we have the script sorted. Create a new Policy and add the Script payload to the Policy. Set is as an ongoing Policy and give it a relevant name like Change User Image to Earth.

Now set the Parameter Variable to one of the image names stated we will use Earth.png
You can see here our $4 Parameter Variable Label we set in the Options section of the Script to help us out on the image names we can select.

Create the Policy as a Self Service item and add a description and an icon that is the same as the image, I’ve also changed the button name to Change.

Scope the policy and you are done.

Open up Self Service find your new like Change User Image to Earth item and click the Change button.

After a few seconds the policy is done. To check the image is updated Lock the screen, or close the lid and there you go the image is now the Earth.png close the lid and there you go the image is now the Earth.png

If you want to add Cactus, Leaf etc just duplicate the Policy change the Policy name to the image name, change in Self Service section as well and update the description and icon image and most importantly change the Parameter Script Values to Leaf.tif

Save and refresh Self Service and now you have Earth and Leaf items. Just repeat this for as many images in the Nature folder as you want.

You could of course add a policy that installs an image of your own and reference in your script just drop in in the same place or change the Script path.

If you have a better way that would also allow camera and Memoji, Emoji and Photos then please post a comment or contact me on Slack MacAdmins @cube

23rd January 2022 – 90 Days is Up

The 23^rd of January is an important day for Mac Admins, why? It’s 90 days since macOS 12 Monterey was released so if you have deployed a macOS Update Defer Profile via your MDM it will expire.

What does this mean?
It means the macOS 12 Monterey Update will now start to show in the user’s Software Update as below:

You may also find Apple start pushing out messages that appear in Notifications saying update now to Monterey, not ideal really.

Can I still block it?
Yes and No.

If the Mac is on Big Sur then it’s a no, Apple deprecated the ignore command. If it is on High Sierra, Mojave or Catalina then you can still use the ignore command. For details on using the ignore command head over to Derflouder.

Anything I can do to stop users from updating?
Well certainly in Jamf you can. You can create a Restricted Software policy that will stop the install, it won’t prevent the user from downloading though but it will block it from running and display a custom on-screen message to your users, although the characters limit is short.

You can find Restricted Software in the left-hand nav:

Have a look at Jamf’s documentation for how to block:
https://docs.jamf.com/10.35.0/jamf-pro/documentation/Restricted_Software.html

Here is an example of the policy setup to block Monterey:

In this example we are doing an exact process match, deleting the installer, killing the process plus informing Jamf users with notifications enabled (usually the Admins) the restriction policy has been broken and also showing an on-screen message to the end-user.
Hint: If you add a message and get an error when saving the restriction try shortening the message length.

Anything else?
There are a couple of Github scripts to also block the Monterey installer from running similar to a Jamf Restricted Software policy but that’s about it.

Apple really wants you to be getting the next macOS version out to your users within 90 days, great in theory but still, 3^rd parties lag behind certifying their software.

Happy 23rd Jan!

Erase all Content and Settings – Control the menu item when you need it

There is a great new feature in Monterey to erase a Mac, very similar to iOS, you can read all about it on Apple’s site here:
https://support.apple.com/en-us/HT212749

A good post on krcs.co.uk prompted me to write this article on how you can control showing the Erase All Content and Settings Menu item via Jamf to have it show when you want by who you want as you may not want it to be accessible by your end-users. Jamf has added this already directly into the Jamf UI so it is as simple as ticking a box in Profile.

So lets start with creating a new Profile

Profile Setup
Create a new Profile in Jamf
Add the Restrictions payload
Select the Functionality section and scroll down

You will see the item and by default its unticked meaning, if you scope this to your target Mac’s the Erase All Content and Settings menu item won’t be shown.
Ticking it will allow the item to be shown.

Scenario
Let’s say you scope this so the menu item is hidden but you want your IT Technicians to have access to it when they need to erase a Mac but without asking you as a Jamf Admin to change the Profile scoping adhoc per Mac, but how?…A Self Service “switch” is the answer.

Solution
A “switch” is possible by using two Profiles one with the item ticked, one unticked plus a Smart Group and a Policy that sets a Receipt for your on “switch” and you can have an “off” switch.

The Policy performs a Touch which writes a Receipt on the Mac and also must be set to do an Inventory Update (recon) which will update a Smart Group. The criteria of the Smart Group is looking for the Receipt and the scoping of the Profiles is set to the Smart group so if the Receipt is found the unticked Profile is removed and add the ticked Profile is added and therefore the menu item will be available!

The policy can be run via Self Service and you can control access to the Policy item to just your IT admins via scoping it to a User Group. When the Self Service item is run the menu item will be shown.

How To
Create a Profile and name accordingly and ensure the item is ticked, add any other Profile settings you require, leave un-scoped for now and save the Profile.
Now duplicate the Profile and name accordingly.
In this duplicate make sure the item is unticked. Again don’t scope yet and save the Profile.

Now create a new Policy

Add a Files and Process payload and in Execute Command field add a Touch command to add a Receipt to the Mac in the form of a .pkg

The touch command is the part in bold is the actual Receipt name and we add this to the Jamf Receipts folder.

touch /Library/Application\ Support/JAMF/Receipts/Restrictions_Allow_Erase_Reset.pkg

Now add a Maintenance payload to the policy and tick the Update Inventory box. This is required so the Mac can report back to Jamf the Restrictions_Allow_Erase_Reset.pkg is in place.

Make this Policy a Self-Service item, give it a nice icon a few instructions and drop in a category like IT Admin and Scope to only those you want to allow access to run it, like your IT Techs.

Now let’s Create the Smart Group
Name it how you want that’s relevant…like Mac’s with Restrictions_Allow_Erase_Reset.pkg

In Criteria find the item Packages Installed By Casper (I like Jamf keeping the old school name here!)
In the Criteria, setting ensure the Operator is has and the Value is the name of your Receipt pkg, so in this example Restrictions_Allow_Erase_Reset.pkg

Finally, save your Smart Group

Ok, so we have our Policy setting the Receipt and we have our Smart Group looking for Macs with the Receipt.

Let’s go back to our Profiles.

Our default position in this example is for the end user not to see the Erase All Content and Settings menu item so in the unticked Profile scope set the Target to be All Computers (assuming all your Mac’s are on Monterey) and set the Exclusion to be the Smart Group you just created.

So, all Mac’s will get the setting not to see the menu item but Mac’s with the Receipt will be excluded from getting this Profile.
Save the Profile and let it hit your Monterey Mac’s.

Now open the ticked Profile, go to Scope and select Specific Computers.

Click Add and this time your Deployment Target is going to be Computer Groups then select your Smart Group you created earlier that is looking for the Receipt.

So Mac’s in the Smart Group that is looking for a Receipt that is dropped in place by your Self Service Policy will now get this Profile when the unticked Profile is removed.

On a target Mac check it has your unticked Profile and check it’s doing its thing and the Erase All Content and Settings menu item is not showing in System Preferences.

Now open Self Service, find your Policy that will run the Touch command, which sets the Receipt, does an Inventory update and therefore based on our scoping will remove our unticked Profile and add our ticked Profile.

Run the item, allow it to complete which will take about 30 or more seconds as we have set it to do an inventory update. You then should notice the Dock open and Close as the Profiles are changed.

Now open System Preferences (Hint: if it’s still open close and re-open) and you will now see the Erase All Content and Settings menu item and the IT Tech can do the erase!

Of course, you may want to revert and hide the menu item. To achieve this is again really simple. All we need to do is create another policy to delete the Receipt we set with the Touch command and do an Inventory Update and add to Self Service. A simple rm of the pkg using the Execute Command in a Files and Process payload….don’t forgot to add a Maintenance payload to the policy and tick the Update Inventory box.

This policy when run from Self Service will move the Mac out of the Smart Group and therefore switch the Profiles back and hide the menu item.

Near the start of this article, I referred to it as a “switch” having both Policies is like an on/off switch, the one we use to write the Receipt is our On switch and one to remove the Receipt is our Off switch.

My guess is there are other ways to achive this, but this is my preferred, tested solution.

Hope that helps.

Mac SE Restore

Early Christmas Gift….a new to me Mac SE from around 1988. Comes with a huge 40Mb Hard disk and 4Mb of RAM. In its day this would have been around $3800. I started my career on one of these. This was the first model to ship with an internal disk drive and it also has the FDHD which is the 1.4Mb Floppy Drive

It powers on and is running OS 7.1.1. The plan is to Retrobrite the case as like all these vintage Mac’s the plastic yellows over time. Then give it a good clean inside and replace the clock battery before it explodes and possibly recap it.

Just need an ADB keyboard….anyone got one spare?

The plan was to buy an old Mac SE and gut it and modernize it but I just cant do that to this one…So if anyone has a dead Mac Classic or even just a case I’d be interested in taking it off your hands.

Checking if a Mac is Automated Device Enrollment Eligible – Jamf API Script

A dilemma I have come across recently is if a Mac is purchased and not in Apple Business Manager (ABM) then it won’t be an Automated Device Enrollment (ADE) eligible device so can’t be deployed as a ZeroTouch device but needs to either be registered which is now only just possible if its a Monterey device but has overheads (iOS15, Configurator 2, Managed Apple ID) or built using a more manual process.

But how can you easily check without booting the Mac?

You could log into ABM and check or log in to Jamf but what if you don’t want to add 10’s or even 100’s of accounts to your ABM or Jamf for your local engineers to access. At present, there is no API to ABM and the minimum account level of Staff still allows access to VPP settings so letting in users is not always ideal and adding and maintaining Jamf Pro access could be a chore based on your setup.

Well, there is an easier way and that’s using the Jamf Pro API (not classic) and device-enrollments/[ID]/devices request and creating a simple command-line tool.

When a device is in ABM and you have set up and pointed ABM to Jamf and in Jamf you have set up an ADE instance you will see your Macs in ABM in Jamf and you can assign these to your Pre-Stage for your Zero-touch deployment.

With a little bit of bash and a Jamf account with specific read-only access, it’s possible to search this list. When I say search you can’t do a direct search, there is no API reference to do that but what we can do is download a list of ADE devices, search it and then delete the download.

First, create an user account in Jamf and set it to only have the following access, that’s all it needs just Read Only for Automated Device Enrollment ensure you just have this in place and not write access.

Once done copy the script below and edit the URL, username adding your API username and password plus the ID number of your ADE instance in Jamf, if you just have one the ID is usually 1.

Save and run the script from the terminal and follow the instructions, enter the full serial number when requested.

The screenshot below shows using the serial 123456 and of course, it’s not found.

The screenshot below shows using a serial starting VQ and it’s found.

The full script is below, like a lot of scripting, there are multiple ways to achieve the same results.
Credit to William Smith aka talkingmoose as the script here really helped kick this off.

If I quickly go through it, after setting the URL and API details the file downloaded is set as my_ade_devices.txt, the next line is the ID of the ADE instance in Jamf. We then set some colours to make the script a bit easier to read.

The next part is the text on the screen when the script is run and a Y/N question. If we choose no we end if we continue we print some more text on screen then make the connection to jamf and do a curl to get the info and save it as a .txt file.

After that, we do our search for the user-entered text and then show results based on if the entered item is found in the text file and finally we clean up afterwards and delete the file.

To distribute the script I make it a .command file, chmod +x so its a simple double click to run. Then package using Jamf Composer and add to Self Service. Self Sevice has an IT Engineers section only and the Engneers must login to Self Service to access and install. I also tend to add some instructions or a video on how to use and link this in the Self Service description.

And thats is, simple command line tool to check your if a Mac is in ADE in jamf.

Feel free to take a copy change, improve as required.
As always using this is at your risk.

#!/bin/bash

# Gets the device in ADE in Jamf

do_file_action(){

# server connection information
URL="https://YOURJamfURL"
username="JAMFAPIUSERNAME"
password="JAMFAPIPASSWORD"

# Local file of the ADE devices
downloadfile="my_ade_devices.txt"

# provide the Jamf Pro ID of the Automated Device Enrollment instance; look in the URL when viewing the Automated Device Enrollment instance name
ADEID="1"

# Set the colour variable to make the script a bit more fun
bold='\033[1;30m'
green='\033[0;32m'
greenbold='\033[1;32m'
red='\033[0;31m'
redbold='\033[1;31m'
# Clear the colour variable
clear='\033[0m'

printf "\n"
printf "${bold}Mac ADE Check${clear}"
sleep 2
printf "\n"
echo "This app will check if the serial number entered is a Mac in ADE in your Jamf environment."
sleep 1
printf "\n"

# Continue question
read -r -p "Do you want to continue [y/n]" input
case $input in
[yY][eE][sS]|[yY])
echo "Continuing..."
;;
[nN][oO]|[nN])
echo "Thanks for this tool. Goodbye."
printf "Please close this app by click the ${redbold}red${clear} dot at the top left."
exit
;;
*)
echo "Answer was not Y or n so exiting"
exit
;;
esac

echo "Getting a list of Mac's in that are registered in Apple Device Enrolment."
printf "${bold}Please wait, this may take 20-30 seconds...${clear}"


# created base64-encoded credentials
encodedCredentials=$( printf "$username:$password" | /usr/bin/iconv -t ISO-8859-1 | /usr/bin/base64 -i - )

# generate an auth token
authToken=$( /usr/bin/curl "$URL/uapi/auth/tokens" \
--silent \
--request POST \
--header "Authorization: Basic $encodedCredentials" )

# parse authToken for token, omit expiration
token=$( /usr/bin/awk -F \" '{ print $4 }' <<< "$authToken" | /usr/bin/xargs )

# submit scope for ADE ID
/usr/bin/curl "$URL/uapi/v1/device-enrollments/$ADEID/devices" -o "$downloadfile" \
--silent \
--request GET \
--header "Authorization: Bearer $token" \
--header "Accept: application/json" \
--header "Content-Type: application/json" \

# expire the auth token
/usr/bin/curl "$URL/uapi/auth/invalidateToken" \
--silent \
--request POST \
--header "Authorization: Bearer $token"

# hide the downloaded file
chflags hidden "$downloadfile"

printf "\n"
printf "List of ADE Mac's downloaded.\n \n"
printf "Enter the Mac serial number of the Mac you need to check.\n"
printf "You can find the Mac serial number on the box or on the base of the Mac.\n"
printf "${bold}Enter serial number:${clear}"
read varserial
printf "The Mac serial number entered is: ${bold}"$varserial"${clear} \n\n"
echo "Searching...."
sleep 2
if grep -w -q "$varserial" $downloadfile;
then
printf "${greenbold}"$varserial"${clear} - ${bold}The Mac is registered.${clear} \n"
printf "Thanks for using this tool. Goodbye.\n \n"
rm $downloadfile
else
printf "${redbold}Computer Says No! - Mac Not Found ${clear}\n \n"

printf "${bold}This Mac is Not on ADE${clear} \n \n"


printf "${bold}Would you like to search again [y/n]${clear}"
read answer
if [ $answer = y ]
then do_file_action
exit 0
elif [ $answer = n ]
then echo "Thanks for this tool. Goodbye."
printf "Please close this app by click the ${redbold}red${clear} dot at the top left."
rm $downloadfile
exit
fi
fi
}

do_file_action

Jamf Connect 2.6 – Azure Passthrough

Jamf Connect is a great product but what seems an annoyance to some is now gone in version 2.6.

Prior to 2.6 when using Azure (at the Jamf Connect login you entered your MS login ID, your password and then you would be asked to verify the password again to get into your Mac which did not seem a great UX and users could not understand why and they really do not like repetitive password entries. In 2.6 Jamf have added passthrough

“Passthrough authentication with Jamf Connect allows the password entered by users in the login window web view to be sent to Jamf Connect for local authentication”
https://docs.jamf.com/jamf-connect/2.6.0/documentation/Passthrough_Authentication.html

As a Jamf customer when I heard this might be coming I started signing up for Jamf Connect Betas and in beta 2.6 it was introduced and we had up and running in 10 minutes.

All it takes to add the passthrough is one extra key and value in your Profile config.
Just add

<key>OIDCUsePassthroughAuth</key>
<true/>
<key>OIDCNewPassword</key>
<false/>

Such a simple change to implement but makes a whole load of difference to the users.

If you use Google Cloud ID this is also available and I suspect other IdP will follow.

Now jamf, please can you make the password change consistent when a user is on-site or connected to VPN and we are using Kerberos and not when on onsite/VPN as it changes between a direct AD password or your cloud providers web-based version. I would really like the ability to overrule the on-site/VPN to use the cloud version, again for a consistent user experience.

Jamf Connect – Configuration file does not specify default realm error message

A few months ago we added Jamf Connect and all was good but recently and we started getting this error when a user was changing their password.

Jamf state this could happen If the Mac was previously bound to AD but we also saw this on new Mac’s that had never been bound, so the jury is out on the cause, but the good news is there is a simple fix.

The fix is to add a krb5.conf file to the user’s Mac (/etc/krb5.conf) and specify in that file the Kerberos realm.

For example the krb5.conf file would be:

[libdefaults] default_realm=UK.DOMAIN.COM

Now we could of created this file, packaged in Composer, added to Jamf, created a policy, scoped and distributed but we have 5 realms (examples below)….so it seemed a lot of work to create 5 pkgs.

DOMAIN.COM
UK.DOMAIN.COM
US.DOMAIN.COM
ASIAPAC.DOMAIN.COM
RD.DOMAIN.COM

However, a quick search on https://community.jamf.com and this wonderful script by bigmikeey caught my eye. A quick test and we were in business. The Jamf community really is a fantastic resource.

All you need to do is change the MCSLTD.INTERNAL in the script below to your domain. Add the script to Jamf, create a policy and deploy. The krb5.conf is created on the users Mac and Jamf connect is killed and relaunched.

#!/bin/bash

#Find the Current users ID.
currentUser=$( /usr/bin/stat -f %Su "/dev/console" )
userID=$( /usr/bin/id -u "$currentUser" )

#Unload the Jamf Connect Menu bar app
/bin/launchctl bootout gui/"$userID" /Library/LaunchAgents/com.jamf.connect.plist

#Create the Kerberos file
touch /etc/krb5.conf

#Write the content into the file
cat << 'EOT' >/etc/krb5.conf

[libdefaults]
default_realm=MCSLTD.INTERNAL

EOT

#wait 2 seconds
sleep 2

#Kill any running instance with the name Jamf Connect
pkill "Jamf Connect"

#Re-launch Jamf Connect Menu bar app (by launching the LaunchAgent)
/bin/launchctl bootstrap gui/"$userID" /Library/LaunchAgents/com.jamf.connect.plist

exit 0

For our needs, we would have 5 scripts and change each one to the specific domain…..which I did! But a far more efficient way is to make the default_realm= value a variable, then have that variable set a script parameter in Jamf. So a single script, much more efficient.

So below is my version. You can see the domain variable is $4 and the default_realm=$domain

#!/bin/bash

#Jamf Script Parameter
domain=$4

#Find the Current users ID.
currentUser=$( /usr/bin/stat -f %Su "/dev/console" )
userID=$( /usr/bin/id -u "$currentUser" )

#Unload the Jamf Connect Menu bar app
/bin/launchctl bootout gui/"$userID" /Library/LaunchAgents/com.jamf.connect.plist

#Create the Kerberos file
touch /etc/krb5.conf

#Write the content into the file
cat << 'EOT' >/etc/krb5.conf

[libdefaults]
default_realm=$domain

EOT

#wait 2 seconds
sleep 2

#Kill any running instance with the name Jamf Connect
pkill "Jamf Connect"

#Re-launch Jamf Connect Menu bar app (by launching the LaunchAgent)
/bin/launchctl bootstrap gui/"$userID" /Library/LaunchAgents/com.jamf.connect.plist

exit 0

In the script Options section in Jamf you can set a Parameter Label as below:

Then when you create your policy and add the script you can enter your domain in the script Parameter Value and you will see your label set in script Options:

Now when you scope and trigger the script the krb5.conf will be created with the value entered so in this case UK.DOMAIN.COM

Once again thanks to the Jamf community for this fix 😊

ADE Mac Build with FileVault – Silently adding a Second Account

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.

macOS 12 Monterey Release Day – The Enterprise Conundrum

Today, 25^th October 2021 is macOS 12 Monterey release day.

I’m not going to list the what’s new but for some Enterprises this time of year the pressure is on. For some companies they may be Day 0 ready and allow users to hit the upgrade button on release but for many Profiles and Restricted Software settings will be in-place along with banners and various communications channels to prevent and inform users not to update but there will be those users who want to either upgrade today or will be wanting a new Mac that will ship with Monterey installed.

Why Not Day 0 Ready?
There are a number of reasons for this, experience suggests it can better to wait for the .1 or the .2 to resolve any initial issues that have not been picked up through the 4 months of beta testing. However, also consider that additional installed software may seem to run OK but is it supported by the vendor.

For example if you use a 3^rd party app for virus protection or VPN Connectivity if that app starts causing issues and you raise a ticket with the vendor have they actually stated macOS 12 Monterey is supported or will you ticket just be closed as running an unsupported OS. If it’s the latter then that may give you and your users a bit of headache.

IT Pressure
The pressure to allow macOS 12 Monterey is added to by the release of the new M1 Pro and M1 Max MacBook Pro’s, no one will want to buy an Intel MBP now even if you have access to stock but these new MacBook Pro’s and pretty much every Mac you can lay your hands on will now ship with Monterey and they can’t be downgraded. Even if you get a M1 Air with Monterey which last week shipped with Big Sur it should not be downgraded as potentially you are taking it out of any support agreements like Apple Enterprise Support (ACE).

So you have your conundrum of wanting to get the new amazing hardware and Monterey out to users to satisfy their requests but at the same time the potential of running apps that a vendor has not certified yet for Monterey. The best thing to do is communicate to your users, let them know the situation. The last thing you want is M1 Pros or even M1 Max running Monterey and the excitement that brings but then users getting a poor experience because of a crashing VPN client or a security app consuming the CPU!

Possible Solution
The best solution I have found for this for those who can’t wait is to provide an OS and /or hardware pilot. Just make it clear that it’s a pilot, list the apps that are not yet Monterey certified, lust any known issues, keep the pilot small and communications open perhaps via Slack or Teams channel and be on hand to help out at moments notice.

Work with your users, not against them. Let them know their Mac and apps could need updating at the drop of a hat. If you show them you care and are engaged most will help you out as you help them out and that way you will have a much better release ready for mass adoption when you are happy to go.

Worldwide Release Times
Honolulu, Hawaii — 7:00 a.m. HST
Anchorage, Alaska — 9:00 a.m. AKDT
Cupertino, California — 10:00 a.m. PDT
Vancouver, Canada — 10:00 a.m. PDT
Phoenix, Arizona — 10:00 a.m. MST
Denver, Colorado — 11:00 a.m. MDT
Chicago, Illinois — 12:00 noon. CDT
New York, New York — 1:00 p.m. EDT
Toronto, Canada — 1:00 p.m. EDT
Halifax, Canada — 2:00 p.m. ADT
Rio de Janeiro, Brazil — 2:00 p.m. BRT
London, United Kingdom — 6:00 p.m. BST
Berlin, Germany — 7:00 p.m. CEST
Paris, France — 7:00 p.m. CEST
Cape Town, South Africa — 7:00 p.m. SAST
Helsinki, Finland — 8:00 p.m. EEST
Moscow, Russia — 8:00 p.m. MSK
Istanbul, Turkey — 8:00 p.m. TRT
Dubai, United Arab Emirates — 9:00 p.m. GST
Delhi, India — 10:30 p.m. IST
Jakarta, Indonesia — 12:00 midnight WIB next day
Shanghai, China — 1:00 a.m. CST next day
Singapore — 1:00 a.m. SGT next day
Perth, Australia — 1:00 a.m. AWST next day
Hong Kong — 1:00 a.m. HKT next day
Seoul, South Korea — 2:00 a.m. KST next day
Tokyo, Japan — 2:00 a.m. JST next day
Brisbane, Australia – 3:00 a.m. AEST next day
Adelaide, Australia — 3:30 a.m. ACDT next day
Sydney, Australia — 4:00 a.m. AEDT next day
Auckland, New Zealand — 6:00 a.m. NZDT next day

Automate Mac App Updating in Jamf

A Jamf Admin’s tasks are never done….there always seems to be an app update you need to download from the vendor and upload to Jamf so your users are on the latest version and obviously the more apps you have the more you have to do so it can be quite a task to keep up.

Some of this can be controlled by Profiles for example Chrome can be set to be keystoned or configuring MAU to check and update Office but when you build a Mac you want it to be up-to-date straight away so that users does not get those update nags boxes to action.

So how can you keep the apps up-to-date in Jamf before deployment….Automation.

First off identify what apps you want to keep up-to-date automatically. If you already have set MAU to update Office and Chrome to stay up-to-date these are good candidates to have the very latest version install for your new builds but you might have some apps that you need to keep on a specific version until fully tested, perhaps a tool like Tanium or your VPN client.

Now you have your list there are two great options

Autopkg & Autopkgr – https://autopkg.github.io/autopkg/ & https://github.com/lindegroup/autopkgr

Installomator – https://github.com/Installomator/Installomator

Autopkg
Autopkg is framework that allows you to create recipes for software you want to update. It’s command line based but if that looks a little scary then Autopkgr is a UI for controlling Autopkg. I would highly recommend using Autopkgr just to keep things simple.

I’m not going to go into the detail of how you setup Autopkg/Autopkgr and create recipes as there are some great tutorials out there. What I will say is it requires an additional computer to run on. Perhaps you have an older Mac or a Mac mini, something that you can keep on 24/7 and connected to your network via Ethernet. It can be a little bit tricky to set up to begin with but once setup you can set it to check for a specific application like MS Office, download that app, package and upload to Jamf and update a policy. The policy then can be part of your new Mac setup process

So let’s say it’s the second Tuesday of the month and MS have just released Mac Office update. Overnight Autopkg will run, it will spot the update does its thing and uploads to Jamf. The next working day when a new Mac is built it will have that very latest update so on use no MAU update box for the user to deal with they will be on the very latest version of Office.

Autopkg is very capable and very flexible but it requires work and setup time.

Installomator
Installomator is a little different but my now preferred solution. Installomator is a script you add to Jamf and then create a Jamf policy add the installomator script and specify the app you want install in the first Script Parameter Value in the Script payload of the Jamf policy. The Installomator script contains hundreds of values of apps and the associated download URL.

When the Policy runs the script gets the application directly from the vendors CDN. Unlike Autopkg the package is not stored in your Jamf instance it comes direct when required from the vendors server so is a more on demand solution. The policy can then be added to your build process. If using DEPNotify simple create a custom trigger name and add that trigger name to your DEPNotify script and ensure the policy scoping is correct.

The downside and upside of Installomator depending upon your point of view is you are not having to hosting the pkg or dmg. Now for some that could be great if your Jamf is hosted and bandwidth can be an issue but others security may be a concern. Have a read of Armin Briegels post on Installomator. The other issue is if the vendor changes the location of the download or changes it format from pkg to dmg, this will result in a failed policy so keep an eye on your installomator policy logs. If something fails you can most likely work out the new URL and either edit the script or create your own definition, it’s very simple to do and also you can submit any missing items to the dev team and help build out the solution for all.

So there are the two options. This article is intended to be high-level just to give an overview of options available to automate deploying the latest version of some apps.

In both solutions you will find some apps not available as a recipe if Autopkg or a definition in the Installomator script this is usually apps are only available to download after logging into an account, these you will still have to download, check the app and upload to Jamf.

I hope this quick overview helps give you some ideas of taking some of the burden out of app updating but most of all allows your users to get working on their Mac straight away with the latest version of apps installed.