Category: macOS

Install a Company Logo Without a Pkg using Jamf Pro

I have been doing this little trick for years so I thought I would create a blog post to share it.

Imagine you need to get your company logo onto computers so that you can brand some widget. When using tools that the user can interact with (like Nudge, IBM Notifier, Jamf Helper, SwiftDialog, or DEPNotify for instance) having a familiar logo or icon helps users to understand, verify, and trust the source of that window when it is presented. There’s the added benefit that it looks good too!

This method can be used to get any image file placed in any location, without having to build a package for distribution, all within Jamf Pro.

All you need do is upload an image to the Self Service section of a policy in Jamf, then use curl in a script to download that image from your Jamf Pro server and place it in the specified location. Here’s how I set it up:

  1. Upload the following script to your Jamf Pro server:
#!/bin/bash
fetch_from="$4"
save_to="$5"
# Check for the image and grab it if it does not exist
if [ ! -f "$save_to" ]; then
curl -o "$save_to" "$fetch_from"
fi
view raw Fetch Image from Jamf Server.sh hosted with ❤ by GitHub
  1. Give the script parameters some useful labels. I used “Image URL” for parameter $4. This is the location of the image we will download. And “Path to Destination” for parameter $5. This is where the image will be saved on disk.
  1. Create a new policy in Jamf Pro and save it.
    IMPORTANT: When first creating the policy, leave it disabled by unchecking the “Enabled” checkbox.
  • General
  • Name: Download Company Logo
  • Enabled: No
  • Trigger: Recurring Check-in
  • Frequency: Once per computer
  • Scripts
  • Select script uploaded previously – do not configure any parameter values yet.
  • Scope
  • Targets: All Managed Clients or All Computers
  • Self Service
  • Check the box for “Make the policy available in Self Service”
  • Upload the image you would like to distribute.
  1. After creating and saving your policy, go to the Self Service tab and find the icon that you uploaded. Right click and select “Copy Image Address” to copy the URL of the image to your clipboard. Take note of this URL.
  1. While still on the Self Service page for your policy, click Edit in the lower right corner, then deselect the checkbox for “Make the policy available in Self Service”. Even though the policy is no longer available in Self Service, the icon remains so we can still access it in our script.
  1. Select the Options tab, then the Scripts section. Paste the image URL copied in step 4 into the “Image URL” field under Script Parameters.
  1. Enter the full path to where the image should be placed on disk, including the image name, into the “Path to Destination” field under Script Parameters. For example /Users/Shared/logo.png
  1. Return to the General section and check the Enabled box to enable the policy, then Save in the lower right corner.

That’s it. The image will be downloaded to each machine in scope and placed in the location of your choice. Now you can reference that image in other scripts and configurations as needed.

Nudge Extension Attribute

What is Nudge?

Nudge is an open source application (primarily created by Erik Gomez) that strongly encourages users to apply macOS updates.

Nudge has been written and talked about plenty of times by my fellow MacAdmins, so I’ll spare you the details. Here are some links if you want more info:

Getting Data from Nudge into Jamf Pro

Nudge stores information about the next time Nudge will run, the minimum required OS version you have defined, and how many deferrals have been used in the plist located at ~/Library/Preferences/com.github.macadmins.Nudge.plist

Notice this is in the user’s local Library. If we want to report this data, we will need to do it in the user context. I have developed the following Jamf Pro extension attribute to do just that.

The following EA will grab the currently logged in user (or the last user if there isn’t one) and read the requiredMinimumOSVersion key value from the com.github.macadmins.Nudge plist. If a value exists, we use the is-at-least function built in to zsh to compare this to the currently installed macOS version. If an update is required, we report the number of deferrals used. This can be useful to ensure that Nudge is running successfully, or to see which users are procrastinating (and how much).

  • If the requiredMinimumOSVersion key is not found, the EA will report No minimum required macOS version found
  • If the requiredMinimumOSVersion key is found, but macOS is already greater than or equal to that value, the EA will report macOS meets minimum required version
  • If macOS does not yet meet the minimum required version, the EA will report the value found in the userDeferrals key. This key is the sum of userSessionDeferrals and userQuitDeferrals.

And here is that extension attribute. Note that it is written in zsh so that we can access functions specific to that shell. It will not work with a .sh extension.

#!/bin/zsh
# Get the currently logged in user
currentUser="$( scutil <<< "show State:/Users/ConsoleUser" | awk '/Name :/ && ! /loginwindow/ { print $3 }' )"
# Check for a logged in user and proceed with last user if needed
if [[ $currentUser == "" ]]; then
# Set currentUser variable to the last logged in user
currentUser=$( defaults read /Library/Preferences/com.apple.loginwindow lastUserName )
fi
# Get the current user's UID
currentUserID="$( id -u "$currentUser" )"
# Nudge plist name
nudgePlist="com.github.macadmins.Nudge.plist"
# Get the current OS version
osVersion="$( /usr/bin/sw_vers -productVersion )"
# Get the required minimum OS version from the plist
minOS="$( launchctl asuser "$currentUserID" sudo -u "$currentUser" defaults read $nudgePlist requiredMinimumOSVersion 2>/dev/null )"
# Report info from nudge plist
if [[ $minOS ]]; then
# Check if OS version meets the requirement using zsh is-at-least function
autoload is-at-least
if is-at-least "$minOS" "$osVersion"; then
result="macOS meets minimum required version"
# If not up-to-date, get the number of deferrals from the plist
else
result="$( launchctl asuser "$currentUserID" sudo -u "$currentUser" defaults read $nudgePlist userDeferrals )"
fi
else
result="No minimum required macOS version found"
fi
echo "<result>${result}</result>"
view raw Nudge Deferrals.zsh hosted with ❤ by GitHub

Smart Group

This extension attribute reports its result as a string. That means we cannot access the integer comparison tools within a Jamf Pro smart group, but we can use a regex.

I set up a smart group to find all devices where the Nudge deferral value is greater than 0 with the regex: ^[1-9][0-9]*$

Use Jamf Self Service to Enable TouchID for sudo

As you may be aware, it is possible to use a fingerprint on any TouchID enabled Mac (or Magic Keyboard with TouchID) to authenticate sudo at the command line.

This possibility has been discussed many times by many MacAdmins, and Mac enthusiasts over the years. The earliest mention I could find is from 2017. Cabel Sasser tweeted:

Pro MacBook Pro Tip: have a Touch Bar with Touch ID? If you edit /etc/pam.d/sudo and add the following line to the top…

auth sufficient pam_tid.so

…you can now use your fingerprint to sudo!— Cabel

(@cabel) November 16, 2017

sudo on the command-line is great. It enforces security and separation by running under your own user, and it logs actions taken using sudo. But it can be a pain to type longer passwords and passphrases repeatedly. By using TouchID to authenticate, we can keep all the security, while reducing long password entries.

All we have to do is edit the file /etc/pam.d/sudo and add the following line at the top:

auth sufficient pam_tid.so

Save and you’re done. However, there are a few caveats. For one, the sudo file gets overwritten with default values each time macOS is updated. That is where our Self Service policy comes in. The script below can be placed in Self Service, allowing users to re-enable the feature with the click of a button after each update.

The script will check if TouchID is already enabled for sudo, and only enable it if needed. The original sudo file gets backed up to /etc/pam.d/sudo.bak.

Another caveat is that this feature does not work in iTerm2 unless a specific setting is changed. The script handles that too. If iTerm is installed, it will check if the required setting is enabled to allow TouchID. If the setting needs to be changed, a Jamf Helper message will let the user know what to do. Note this is a one time only change, once the setting is correct, users will not see the following message.

Additional step required for iTerm

If you do not use Jamf, the Jamf Helper section could easily be replaced with something more appropriate for your environment, or removed altogether.

Without further ado, here is our script:

#!/bin/bash
# Get the current user and their UID
currentUser=$( scutil <<< "show State:/Users/ConsoleUser" | awk '/Name :/ && ! /loginwindow/ { print $3 }' )
currentUserID=$( id -u "$currentUser" )
# This is the line we need to add to enable TID
enableTouchID="auth sufficient pam_tid.so"
# Original sudo file location
sudoFile="/etc/pam.d/sudo"
# If TouchID is already enabled exit. Otherwise modify the sudo file
if fgrep -q "$enableTouchID" "$sudoFile"; then
echo "TouchID for sudo is already enabled. Doing nothing…"
else
echo "TouchID not enabled for sudo. Enabling now…"
# Write new file with line to enable touch ID
awk 'NR==2 {print "auth sufficient pam_tid.so"} 1' $sudoFile > $sudoFile.new
# Make a backup of the current sudo file
cp $sudoFile $sudoFile.bak
# Replace the current file with the new file
mv $sudoFile.new $sudoFile
fi
# If iTerm is installed, tell the user what they need to change to enable this setting
if [ -d '/Applications/iTerm.app' ]; then
# Read iTerm preference key
iTermPref=$( launchctl asuser "$currentUserID" sudo -u "$currentUser" defaults read com.googlecode.iterm2 BootstrapDaemon 2>/dev/null )
# If preference needs to be set, show Jamf Helper window with instructions
if [[ "$iTermPref" == "0" ]]; then
echo "iTerm preference is already set properly. Doing nothing…"
else
echo "Notifying user which iTerm setting needs to be changed…"
# Set notification description
description="We have detected that you have iTerm installed. There is an additional step needed to enable this functionality.
To enable TouchID for iTerm: Navigate to Preferences » Advanced » Session, then ensure \"Allow sessions to survive logging out and back in\" is set to \"No\""
# Display notification
"/Library/Application Support/JAMF/bin/jamfHelper.app/Contents/MacOS/jamfHelper" \
-windowType utility \
-title "Tech Services Notification" \
-heading "Additional Step Required for iTerm" \
-description "$description" \
-alignDescription left \
-icon "/Applications/iTerm.app/Contents/Resources/AppIcon.icns" \
-button1 "OK" \
-defaultButton 1
fi
fi
view raw Enable TouchID for sudo.sh hosted with ❤ by GitHub

I would advise adding the above script to Jamf Pro, then setting up a Self Service policy like so:

  • General
  • Name: Enable TouchID for sudo
  • Trigger: Self Service
  • Frequency: Ongoing
  • Scripts
  • Select script uploaded previously.
  • Scope
  • Targets: Computers with TouchID enabled

Unfortunately, scoping to only computers with TouchID enabled requires an extension attribute (and a smart group). I have included the extension attribute I use below:

#!/bin/bash
# Check to see if TouchID is enabled and returns the number of enrolled fingerprints per user
touchIDstatus=$( sudo bioutil -s -c | sed 's/Operation performed successfully.//g' )
if [ "$touchIDstatus" != "There are no fingerprints in the system." ]; then
echo "<result>$touchIDstatus</result>"
else
echo "<result>Not configured</result>"
fi
view raw TouchID Status.sh hosted with ❤ by GitHub

I would also add something to the description in Self Service indicating that the user needs to return and run the policy again after each macOS update, and check the box to ensure that users view the description.

Should you ever need to undo this action, it is as simple as restoring the original sudo file from the one we backed up. The following command can be run with a Jamf policy to restore the original settings:

mv /etc/pam.d/sudo.bak /etc/pam.d/sudo

Detecting if Rosetta 2 is Installed on an Apple Silicon Mac

There are a few different ways to detect if Rosetta 2 is installed on an Apple silicon Mac. Most of them look for a process containing the string oahd. This is because inside macOS, Rosetta is not referred to by name, it is know as OAH.

Adding to the confusion, Apple has made minor changes along the way that may have affected some scripts or extension attribute’s ability to accurately report Rosetta 2 status. One such change occurred in macOS 11.5 where checking for the LaunchDaemon /Library/Apple/System/Library/LaunchDaemons/com.apple.oahd.plist stopped working. As a result, most transitioned to checking for a process containing oahd.

The Jamf extension attribute below sidesteps these limitations. It first checks if the device architecture is Apple silicon (arm64), then checks if the system is able to run x86_64 intel code using the arch binary. It follows that if an Apple silicon device can run intel code, Rosetta 2 must be installed, regardless of if the oahd process is found.

This method is more robust, and less likely to provide a false positive. Additionally, it will not be affected by any future changes Apple may make to Rosetta 2.

#!/bin/sh
# If cpu is Apple branded, use arch binary to check if x86_64 code can run
if [[ "$(sysctl -n machdep.cpu.brand_string)" == *'Apple'* ]]; then
if arch -x86_64 /usr/bin/true 2> /dev/null; then
result="Installed"
else
result="Missing"
fi
else
result="Ineligible"
fi
echo "<result>$result</result>"
view raw Rosetta 2 Extension Attribute.sh hosted with ❤ by GitHub

Taking that a step further, if we detect that Rosetta 2 is not installed, we will want to get it installed. The following script can be used to do just that.

#!/bin/sh
# If cpu is Apple branded, install Rosetta 2
if [[ "$(sysctl -n machdep.cpu.brand_string)" == *'Apple'* ]]; then
/usr/sbin/softwareupdate –install-rosetta –agree-to-license
fi
view raw Install Rosetta 2.sh hosted with ❤ by GitHub

Remind Users to Run as Standard with SAP Privileges App

This post is going to cover a set of scripts and launch daemons that can be used alongside the SAP Privileges app to remind users not to abuse admin privileges. I will skip much of the background info on Privileges because that has been covered thoroughly by my fellow mac admins. Inspiration for this tool came from:

The Privileges application allows users to switch from standard to administrator and vice versa. As stated on the Privileges GitHub page, “Working as a standard user instead of an administrator adds another layer of security to your Mac and is considered a security best practice. Privileges helps enable you to act as an administrator only when required.”

While Privileges is excellent at its intended function, you may want some help encouraging users to act as an administrator only when required (instead of setting themselves as an admin and never looking back). Additionally, you may want some way of logging who is using admin privileges for an extended period of time and how often. That’s where PrivilegesDemoter comes in.

PrivilegesDemoter

PrivilegesDemoter consists of two scripts and two launchDaemons. The first launchDaemon runs a script every 5 minutes. This script checks if the currently logged in user (or the last user if there is no current user) is an administrator. If this user is an admin, it adds a timestamp to a file and calculates how long the user has had admin rights.

Once that calculation passes 15 minutes, a signal file gets created. That is where the second launchDaemon comes in. The signal file tells the second launchDaemon to call a Jamf policy. I chose 15 minutes here because that should be more than enough time to perform an admin task or two (like installing an update).

So far we have confirmed that there is an admin user on the machine, and that user has been an admin for more than 15 minutes. The Jamf policy is where all the real work gets done. In the policy called from Jamf we use a jamf helper message to ask if the user still requires admin rights.

  • Clicking “Yes” resets the timer allowing the user to remain an administrator for another 15 minutes, at which point the reminder will reappear.
  • Clicking “No” revokes administrator privileges immediately. 
  • If the user does nothing, the reminder will timeout and revoke administrator privileges in the background.
  • Users may use the Privileges application normally to gain administrator rights again whenever needed.
  • Each privilege escalation and demotion event is logged in /var/log/privileges.log

You can find the PrivilegesDemoter tool as well as deployment instructions in my GitHub here: https://github.com/sgmills/PrivilegesDemoter

Update Inventory (Immediately) After macOS Update

This is related to my previous post Re-enabling Jamf Connect Login after an in-place macOS Upgrade, but without the Jamf Connect part.

When a macOS update or upgrade is performed, often times Jamf Pro will not recognize the update until up to 24 hours later. Depending on how often computers are set to update inventory, it could be even longer.

If you happen to have policies or configuration profiles scoped to devices based on their OS version this delay in inventory information would also delay those actions. Or perhaps a security update has come out and you want to know which devices remain vulnerable. A delay in reporting means you do not have timely information to ensure your mac fleet is protected.

Ensuring Jamf Pro updates inventory immediately after a macOS update can be done rather simply by having Jamf Pro run a script on startup.

The first requirement is to ensure you have the Jamf startup script enabled. Navigate to Settings > Computer Management > Check-In and ensure that the boxes for Create startup script and Check for policies triggered by startup are checked. This ensures our script will run each time the computer boots. (If not using Jamf Pro, consider creating your own LaunchDaemon here.)

Next we upload our script to Jamf Pro. The (below) script performs the following actions:

  1. Gets the current local operating system build.
  2. Checks if there is an existing local plist file for the macOS build version, and creates it if needed.
  3. If the current OS version matches the local plist we assume the OS was not updated, exit with status 0.
  4. If the current OS version does not match the the local plist, we assume the OS was updated, and perform an inventory update.
  5. Update the macOS build in the local plist with the new build version.
#!/bin/sh
# Location of macOS Build plist for comparison
# Subsitute your org name for anyOrg, or place in another location
buildPlist="/usr/local/anyOrg/macOSBuild.plist"
# Get the local os build version
# Using build version accounts for supplimental updates as well as dot updates and os upgrades
localOS=$( /usr/bin/sw_vers | awk '/BuildVersion/{print $2}' )
# If the macOS Buld plist key does not exist, create it and write the local os into it
if ! /usr/libexec/PlistBuddy -c 'print "macOSBuild"' $buildPlist &> /dev/null; then
echo "macOS Build plist does not exist. Creating now…"
defaults write $buildPlist macOSBuild $localOS
else
echo "macOS Build plist already exists. Skipping creation…"
fi
# Get the os from the macOS build plist now that we have ensured it exists
plistOS=$( defaults read $buildPlist macOSBuild )
# If the local OS does not match the plist OS do some maintainance
if [[ $localOS != $plistOS ]]; then
echo "macOS was updated. Performing maintenance now…"
# Update inventory
echo "Updating inventory…"
/usr/local/bin/jamf recon
# Update the local plist file
echo "Updating plist with new OS build version…"
defaults write $buildPlist macOSBuild $localOS
else
echo "macOS was not updated. Nothing to do here."
fi
view raw Update Inventory after macOS Update.sh hosted with ❤ by GitHub

With this script uploaded to Jamf Pro, the last step is to create a policy that runs it. Note that I have named the policy and the script “macOS Update Maintenance” feel free to name them as you see fit.

  • General
  • Name: macOS Update Maintenance
  • Trigger: Startup
  • Frequency: Ongoing
  • Scripts
  • Select script uploaded previously.
  • Scope
  • Targets: All Managed Clients or All Computers

Now each time one of our Jamf Pro managed macs boots, it will run this script. The script will determine if the macOS build version has changed, then optionally perform a recon so that our inventory records are updated immediately!

Using a Self Service Policy to Grant End Users a Secure Token

Occasionally end users may end up without a secure token. This attribute is required to enable FileVault on any macOS device. Additionally, it is required for the end user to install updates on Apple silicon devices (this is a little complicated but for the purpose of this post I am ignoring volume ownership, as it is functionally equivalent to secure token in this respect).

Use the following script in a Self Service policy to grant the end user a secure token. This script will check if the currently logged in user has a secure token. If so, a notification informs them that no action is required.

If the currently logged in user does not have a secure token you will be guided through the process to grant one. In order to grant a secure token to a user without one, an account with a secure token must be used. The script will find all secure token users on the system and list them for you. Select an account that you already know the password for.

Next you will be prompted for the existing secure token user’s password. This is required to grant the token to other users

Then, you will be prompted for the end user’s password to complete the process.

Finally, the script will check if a bootstrap token is escrowed with MDM, and escrows the token if needed.

The script is available below:

#!/bin/sh
# Set the icons and branding
selfServiceBrandIcon="/Users/$3/Library/Application Support/com.jamfsoftware.selfservice.mac/Documents/Images/brandingimage.png"
fileVaultIcon="/System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/FileVaultIcon.icns"
if [[ -f $selfServiceBrandIcon ]]; then
brandIcon="$selfServiceBrandIcon"
else
brandIcon="$fileVaultIcon"
fi
# Start by setting result to UNDEFINED
result="UNDEFINED"
MissingSecureTokenCheck() {
# Get the currently logged-in user and go ahead if not root.
userName=$(/bin/ls -l /dev/console | /usr/bin/awk '{ print $3 }')
# This function checks if the logged-in user has Secure Token attribute associated
# with their account. If the token_status variable returns "0", then YES is set.
# If anything else is returned, NO is set.
if [[ -n "${userName}" && "${userName}" != "root" ]]; then
# Get the Secure Token status.
token_status=$(/usr/sbin/sysadminctl -secureTokenStatus "${userName}" 2>&1 | /usr/bin/grep -ic enabled)
# If there is no secure token associated with the logged-in account,
# the token_status variable should return "0".
if [[ "$token_status" -eq 0 ]]; then
result="NO"
fi
# If there is a secure token associated with the logged-in account,
# the token_status variable should return "1".
if [[ "$token_status" -eq 1 ]]; then
result="YES"
fi
fi
# If unable to determine the logged-in user
# or if the logged-in user is root, then UNDEFINED is returned
}
MissingSecureTokenCheck
if [[ $result = "NO" ]]; then
# Current user does not have a secure token. Need to generate one.
# Granting user needs to be an admin. Get all the admin users on the computer.
adminUsers=$(dscl . read /Groups/admin GroupMembership | cut -d " " -f 2-)
# For each user, check if they have a secure token
for EachUser in $adminUsers; do
TokenValue=$(sysadminctl -secureTokenStatus $EachUser 2>&1)
if [[ $TokenValue = *"ENABLED"* ]]; then
SecureTokenUsers+=($EachUser)
fi
done
# List out the users with a secure token
if [[ -z "${SecureTokenUsers[@]}" ]]; then
# If no secure token admin users, show dialog stating such
/usr/bin/osascript -e "display dialog \"\" & return & \"There are no secure token admin users on this device.\" with title \"Grant Secure Token\" buttons {\"OK\"} default button 1 with icon POSIX file \"$brandIcon\""
exit 0
else
# Have user select a secure token user they know the password for
adminUser=$( osascript -e "set ASlist to the paragraphs of \"$(printf '%s\n' "${SecureTokenUsers[@]}")\"" -e 'return choose from list ASlist with prompt "Select a user you know the password for:"' )
# Get a secure token users password
adminPassword=$( /usr/bin/osascript -e "display dialog \"To grant a secure token\" & return & \"Enter login password for '$adminUser'\" default answer \"\" with title \"Grant Secure Token\" buttons {\"Cancel\", \"Ok\"} default button 2 with icon POSIX file \"$brandIcon\" with text and hidden answer
set adminPassword to text returned of the result
return adminPassword")
# Exit if user cancels
if [ "$?" != "0" ] ; then
echo "User aborted. Exiting…"
exit 0
fi
fi
# Try the entered password
passCheck=`dscl /Local/Default -authonly "${adminUser}" "${adminPassword}"`
# If the credentials pass, continue, if not, tell user password is incorrect and exit.
if [ "$passCheck" == "" ]; then
echo "Password Verified"
else
echo "Password Verification Failed. Please try again."
/usr/bin/osascript -e "display dialog \"\" & return & \"Password Verification Failed. Please try again.\" with title \"Grant Secure Token\" buttons {\"OK\"} default button 1 with icon POSIX file \"$brandIcon\""
exit 1
fi
# Get the logged in user's password via a prompt
echo "Prompting ${userName} for their login password."
userPassword=$( /usr/bin/osascript -e "display dialog \"To grant a secure token\" & return & \"Enter login password for '$userName'\" default answer \"\" with title \"Grant Secure Token\" buttons {\"Cancel\", \"Ok\"} default button 2 with icon POSIX file \"$brandIcon\" with text and hidden answer
set userPassword to text returned of the result
return userPassword")
# Exit if user cancels
if [ "$?" != "0" ] ; then
echo "User aborted. Exiting…"
exit 0
fi
echo "Granting secure token."
# Grant the token
sysadminctl -secureTokenOn ${userName} -password ${userPassword} -adminUser ${adminUser} -adminPassword ${adminPassword}
# Check for bootstrap token escrowed with Jamf Pro
bootstrap=$(profiles status -type bootstraptoken)
if [[ $bootstrap == *"escrowed to server: YES"* ]]; then
echo "Bootstrap token already escrowed with Jamf Pro!"
else
# Escrow bootstrap token with Jamf Pro
echo "No Bootstrap token present. Escrowing with Jamf Pro now…"
sudo profiles install -type bootstraptoken -user "${adminUser}" -pass "${adminPassword}"
fi
elif [[ $result = "YES" ]]; then
echo "Current user already has a secure token. No action necessary."
/usr/bin/osascript -e "display dialog \"\" & return & \"$userName already has a secure token. No action necessary.\" with title \"Grant Secure Token\" buttons {\"OK\"} default button 1 with icon POSIX file \"$brandIcon\""
else
echo "Undefined secure token status"
/usr/bin/osascript -e "display dialog \"\" & return & \"Could not determine secure token status.\" with title \"Grant Secure Token\" buttons {\"OK\"} default button 1 with icon POSIX file \"$brandIcon\""
exit 1
fi
view raw Grant Current User Secure Token.sh hosted with ❤ by GitHub

Re-enabling Jamf Connect Login after an in-place macOS Upgrade

When macOS is upgraded from one major version to the next the login window mechanisms are reset to their default values. This disables the custom Jamf Connect login window.

If Jamf Connect (or NoMAD Login AD) are used in your environment, this may be problematic, and we will need a way to re-enable the login screen automatically after an OS upgrade occurs. This post will go over my process for doing this with Jamf Pro and Jamf Connect v2, but it can be adapted for use with Jamf Connect v1, or NoMAD Login AD and other management solutions.

The main mechanism used here is a script run at startup, and a local plist file that stores the last known operating system build version of a given macOS device. The last known build version is compared to the current build version at startup, if they differ we know that the OS was updated. With this information, we can then run a policy to perform any post-update maintenance we want, in this case re-enabling Jamf Connect.

The first prerequisite is to ensure you have the Jamf startup script enabled. Navigate to Settings > Computer Management > Check-In and ensure that the boxes for Create startup script and Check for policies triggered by startup are checked. This ensures our script will run each time the computer boots. You could just as easily create your own LaunchDaemon here, but Jamf has already done that for us, so we might as well use the built in mechanism.

Additionally, we will need a smart computer group to identify devices with Jamf Connect installed. If you are using Jamf Connect v2.x this is as simple as Application Title is Jamf Connect.app

Next we need a policy to re-enable Jamf Connect. Here is an example:

  • General
  • Name: Enable Jamf Connect Login
  • Trigger: Custom (enable-jamfconnectlogin)
  • Frequency: Ongoing
  • Files and Processes
  • Execute Command: /usr/local/bin/authchanger -reset -jamfconnect
  • Note that the above command is for Jamf Connect v2.x. If you are using Jamf Connect v1.x, or NoMAD Login AD, use the appropriate authchanger command for that version.
  • Scope
  • Targets: Jamf Connect Installed (smart group from earlier)

Now we can upload our script to Jamf Pro. The script performs the following actions:

  1. Gets the current local operating system build.
  2. Checks if there is an existing local plist file for the macOS build version, and creates it if needed.
  3. If the current OS version matches the local plist we assume the OS was not updated, exit with status 0.
  4. If the current OS version does not match the the local plist, we assume the OS was updated, and perform some maintenance.
  5. Check to see if Jamf Connect Login is already enabled. If not, we call the custom trigger to enable it on devices in scope.
  6. Update inventory (the OS was updated, after all).
  7. Update the macOS build in the local plist with the new build version.

The script is available below:

#!/bin/sh
# Location of macOS Build plist for comparison
# Subsitute your org name for anyOrg, or place in another location
buildPlist="/usr/local/anyOrg/macOSBuild.plist"
# Get the local os build version
# Using build version accounts for supplimental updates as well as dot updates and os upgrades
localOS=$( /usr/bin/sw_vers | awk '/BuildVersion/{print $2}' )
# If the macOS Buld plist key does not exist, create it and write the local os into it
if ! /usr/libexec/PlistBuddy -c 'print "macOSBuild"' $buildPlist &> /dev/null; then
echo "macOS Build plist does not exist. Creating now…"
defaults write $buildPlist macOSBuild $localOS
else
echo "macOS Build plist already exists. Skipping creation…"
fi
# Get the os from the macOS build plist now that we have ensured it exists
plistOS=$( defaults read $buildPlist macOSBuild )
# If the local OS does not match the plist OS do some maintainance
if [[ $localOS != $plistOS ]]; then
# Check for Jamf Connect Login status and re-enable if needed
if [[ ! $( /usr/local/bin/authchanger -print | grep JamfConnectLogin ) ]]; then
# If JCL is disabled, re-enable it with a policy (scope carefully)
/usr/local/bin/jamf policy -event enable-jamfconnectlogin
else
echo "Jamf Connect Login is enabled on this device. Nothing to do here…"
fi
# Update inventory
/usr/local/bin/jamf recon
# Update the local plist file for next time
defaults write $buildPlist macOSBuild $localOS
else
echo "macOS was not updated. Nothing to do here."
fi
view raw Re-enable Jamf Connect Login.sh hosted with ❤ by GitHub

With this script uploaded to Jamf Pro, the last step is to create a policy that runs it.

  • General
  • Name: macOS Update Maintenance
  • Trigger: Startup
  • Frequency: Ongoing
  • Scripts
  • Select script uploaded previously.
  • Scope
  • Targets: All Managed Clients or All Computers

Now each time one of our Jamf Pro managed macs boots, it will run this script. The script will determine if the macOS build version has changed, then re-enable Jamf Connect if it is disabled.

And there is the added bonus of also performing a recon so that our inventory records are updated immediately after an OS update is done by the user!