Posted on 01-19-2022 05:14 AM
Hello everyone.
So how we use Jamf Connect login is only on the first login for new hires. This is just to provision the account properly and do all of the magic.
After that we run an onboarding script which contains authchanger -reset to kill the login window and just use the menu bar for password resets and whatnot. For us it just works better for our users when they have the native login. If they are out of internet and then looking for the local login button etc etc.
The issue is that it seems after a major OS update for existing users the Jamf Connect Login window comes back as the login mechanism.
I'm wondering if anyone has a good solution for this for existing users/upgrades?
Posted on 01-19-2022 06:46 AM
You can probably create an EA to verify if the Jamf Connect login is configured. Create a smart group and use the EA as the criteria to get the list of Macs that has the Jamf Connect login configured. Then, finally create a policy with the autchanger script and scope to that smart group. There should be an existing Jamf Connect status EA
Posted on 01-20-2022 06:45 AM
Thanks for the tip. Will give this a try.
Posted on 05-24-2023 09:06 AM
We are running into this same issue. This solution seems to make the most sense. When creating the EA what data point are you referencing?
02-06-2022 05:11 PM - edited 02-06-2022 05:14 PM
We use a smart group to mark which systems have pending updates. Then 2 config profiles are scoped based on that. If a system has pending updates they get a profile to disable jamf connect with "authchanger -reset", and once updates are complete, they get a profile to enable jamf connect with a profile for "authchanger -reset jamfconnect". This prevents an issue with T2 macs getting stuck at a grey screen where they won't finish OS updates because Jamf Connect interrupts the update process, while also ensuring the users see our 2factor login screen.
Check out the jamf connect admin guide for an example config profile