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!

4 thoughts on “Re-enabling Jamf Connect Login after an in-place macOS Upgrade”

  1. Pingback: Update Inventory (Immediately) After macOS Update – Mostly Mac

  2. so as an alternative, and to leave jamf pro out of it, could you have a launchdaemon run every start, use authchanger to check tho login stack, if wrong reset it then kill login window, if correct do nothing?

    Like

    Reply

    1. Absolutely! This is basically the same thing, but Jamf supplies the launchdeamon for you. It should be easy enough to roll your own.

      Like

      Reply

  3. just currently testing this I think its failing for me as the plist isnt currently getting the right permissons. It currently has system Read & write permissons but this doesnt seem to be enough I though it would be.

    Can this plist file be created anywhere on the mac?

    Like

    Reply

Leave a comment