Mostly Mac

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:

• Nudge GitHub Wiki
• Introduction to Nudge – Alan Siu
• Basic default behavior in Nudge – Alan Siu
• A Nudge in the right direction – Neil Martin (2021 MacAdmins Conference Session)
• Nudge users to keep macOS up-to-date – Dan Snelson (2021 JNUC Session)

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]*$

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.

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:

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

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.

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.

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.

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!