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.
Step One: Inform your users what’s going on
The jump from the macOS login window, to NoMAD Login, to Jamf Connect can catch some users off-guard. 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. Inform users about how the menu bar agent will change from Carrie the Caribou to the Jamf logo (or your custom organizational logo). If you’re using Okta, inform users about the shortcut to logging into Okta resources with the “Connect” option in the menu bar agent. 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.
Step Two: Disable NoMAD Login
Create a Jamf Pro policy to run a command on all computers that have NoMAD Login enabled:
/usr/local/bin/authchanger -reset
If you’re not using Jamf Pro, be sure to run the command using sudo.
This will reset the login window to the standard macOS login screen. Users will still be able to log in locally with their local user account credentials.
Step Three: Remove NoMAD components
Remove the NoMAD applications, launch agents, and preferences. Refer to this script by @sumnert as an example for how to remove all installed components for NoMAD.
NOTE: This will log the user out if using Jamf Connect Login or NoMAD Login
Step Four: Deploy Jamf Connect configurations
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. Check out the JNUC session Deploying Jamf Connect at Scale for different ways to implement Jamf Connect in your environment.
The only must have — include the option for MigrateUsers set to TRUE. This will take care of any issues where a user’s username from the identity provider does not match the local username on the computer exactly. This may occur if a user was initially allowed to make their own short name (say, NoMAD wasn’t around at the time) or the possible name change for the user since they first started up their computer.
If the local user name doesn’t match the identity provider username exactly, the user will be presented with a list of local users and asked to choose what accounts is theirs. Be sure to use the key for MigrateUsersHide to hide any extra administrator accounts or the Jamf Pro management account.
Step Five: Deploy Jamf Connect installer and optional launch agent
If you’re using Jamf Pro, make a Smart Computer Group where the criteria are Profile Name has the name of your Jamf Connect Configuration profiles for login and the menu bar agent. It will look something like:
Next, create a policy to install the Jamf Connect to:
- All Computers in the Smart Computer Group
- Policy runs once per computer
- Trigger is Recurring Check-in
And that’s it. NoMAD is removed, and Jamf Connect is configured, deployed, and ready to go.
by Category:
Have market trends, Apple updates and Jamf news delivered directly to your inbox.
To learn more about how we collect, use, disclose, transfer, and store your information, please visit our Privacy Policy.