This is something slightly new in the latest version of Jamf Connect - the authchanger command reads and activates itself automagically based on the presence of the Jamf Connect configuration profiles. NOTE: This will log the user out if using Jamf Connect Login or NoMAD Login Step Four: Deploy Jamf Connect configurations
#WHAT IS JAMF CONNECT HOW TO#
Refer to this script by as an example for how to remove all installed components for NoMAD. Remove the NoMAD applications, launch agents, and preferences. Users will still be able to log in locally with their local user account credentials. This will reset the login window to the standard macOS login screen. If you’re not using Jamf Pro, be sure to run the command using sudo. Step Two: Disable NoMAD LoginĬreate a Jamf Pro policy to run a command on all computers that have NoMAD Login enabled: /usr/local/bin/authchanger -reset
And lastly, if you’re using any identity provider other than Okta, let the users know that asking for the password twice, once to authenticate to your identity provider (with support for multi-factor authentication) and once again to log in locally, is expected behavior. If you’re using Okta, inform users about the shortcut to logging into Okta resources with the “Connect” option in the menu bar agent. Inform users about how the menu bar agent will change from Carrie the Caribou to the Jamf logo (or your custom organizational logo). Make sure you inform users of what is coming - we’re disabling NoMAD Login, your login will look different for a day, and when you see the new login screen with the new organization logo and wallpaper, you know you’re all set. The jump from the macOS login window, to NoMAD Login, to Jamf Connect can catch some users off-guard. Step One: Inform your users what’s going on
Overview: This post documents how to move from Active Directory-based local accounts on Mac, managed via NoMAD and NoMAD Login, to leveraging a cloud-based identity provider and Jamf Connect.