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:
- Gets the current local operating system build.
- Checks if there is an existing local plist file for the macOS build version, and creates it if needed.
- If the current OS version matches the local plist we assume the OS was not updated, exit with status 0.
- If the current OS version does not match the the local plist, we assume the OS was updated, and perform some maintenance.
- Check to see if Jamf Connect Login is already enabled. If not, we call the custom trigger to enable it on devices in scope.
- Update inventory (the OS was updated, after all).
- Update the macOS build in the local plist with the new build version.
The script is available below:
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!
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?
LikeLike
Absolutely! This is basically the same thing, but Jamf supplies the launchdeamon for you. It should be easy enough to roll your own.
LikeLike