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.
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.
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
