Automation for Jamf Connect fixing itself after system upgrades

thebrucecarter
Contributor II

Greetings all,

It is documented in the Jamf Connect manual that Jamf Connect will lose its control over the login process after a system upgrade.  It shows issuing the authchanger command to re-establish the control.  We don't have control (at this point) over when people run system upgrades, so we would like to automate this process so that any time that linkage to Jamf Connect is broken it gets reconnected.  Does anyone already have this process set up and working?  It was suggested to use a script in Self Service, but we do not want to leave this step to the tender mercies of our end users.  We want this to be as unobtrusive (invisible) and bullet-proof as possible.  We're looking at the authchanger -print output and grepping for pertinent information, but we are hoping that somebody has run into this already.

 

Thank you for any suggestions!

3 REPLIES 3

DBrowning
Valued Contributor II

I have an EA that looks to see if JamfConnectLogin is in the list of mechanisms:

#!/bin/sh

check=$(/usr/local/bin/authchanger -print | grep JamfConnectLogin)

if [ "$?" == 0 ]; then
	echo "<result>Okta</result>"
else
	echo "<result>No</result>"
fi
exit 0


Then we have a smart group for devices that the EA is No.  Then have a policy to run authchanger -reset -jamfconnect on devices in that smart group.

Greetings @DBrowning,

Does that kick off soon enough to prevent them from seeing the Apple loginwindow?  We tried a script that ran as a loginDaemon, but while it made the change it made it after loginwindow was already up.  So, we built in a restart after making the change (to keep everything clean) but then that broke the software update process.  Next we're going to try killing loginwindow, but it would be better, I think, if we could detect if an update was in process and then not do the reboot until it was done...  Still working on alternatives.

mickgrant
Contributor II

I have a smart group setup that targets OS versions, for example, "Running Monterey" that I scope a policy to that runs at startup, network state change, and reoccurring check-in  with a frequency of Only Once that runs a files and processes payload executing the following Command 

/usr/local/bin/authchanger -reset -jamfconnect

 

this has been working pretty flawlessly for me