A look at Jamf Connect (formerly NoMAD Pro) and how it helps with identity management on macOS

macOS identity management issues

Before we dig in, we should go over some of the identity management trends and issues facing macOS today:

• First, macOS has supported binding with Active Directory for years, but most Mac admins consider this brittle and unreliable, and instead, local user accounts are the way to go.
• By now you’ve probably heard that macOS provisioning is changing. Automated MDM enrollment (a.k.a. DEP) is the way forward, and High Sierra, the T2 chip, and Mojave have killed off imaging.
• Automated MDM enrollments need some help with authentication, because DEP and MDM just don’t have all the modern identity components needed to secure it. (I explored this issue last week.)
• As with Windows, most IT organizations want to avoid giving admin rights to Mac users.
• Lastly, this is all happening at a time when identity concepts like conditional access, multi-factor authentication, SAML, and “zero trust” are really spreading.

What Jamf Connect actually does

The easiest way to understand what Jamf Connect does is to look at the enrollment process step by step.

When a Mac is turned on and connected to the internet for the first time, it checks in with Apple. If the serial number is part of the Device Enrollment Program, Apple will redirect it to the associated MDM server. Here, as I wrote last week, there’s an option to authenticate the user via LDAP, but we want stronger authentication at some point.

As part of the initial MDM enrollment, you can push a package to the device, using the Install Enterprise App command.

So, you can push Jamf Connect, and use the Await Configuration command to make sure that it gets fully installed while the device is in setup assistant mode—i.e., the device will tell the user to hold on while it sets everything up, and the user can’t mess it up or anything.

Then, Jamf Connect will pop up before the standard native login window. Jamf Connect can ask the user to authenticate, using modern practices like multi-factor authentication, conditional access, and cloud identity providers.

Now that the user is authenticated and authorized, Jamf Connect will create the local user account in macOS. It does this (along with some other cool stuff that I’ll talk about next) thanks to an integration with the macOS authorization database, a SQLite database that the operating system uses to handle all sorts of tasks. What about the password? I’ll get to that later. But by the way, at this point, since the user has been strongly-authenticated, you’re also clear to install sensitive data and configurations.

Subsequent logins will generally take place using the native login window, but there are a few other places where Jamf Connect comes up. Thanks to Jamf Connect’s integration with the macOS authorization database, it can also be used to gate other sensitive actions, like various settings in Systems Preferences, and sudo commands. This means that you don’t have to give users admin rights (not even temporarily), and instead, Jamf Connect is dealing with the authorization by adjusting rules in the database. This also helps you deal with apps that would previously only work with admin rights.

Passwords and IdP integrations

Jamf Connect can create the the local user account, but what about setting the password? Since we’re talking about a local account, the authentication is happening right there on the machine. You either have to sync the password and write it to the local user account, or just let the user set it, and be okay with it being different than the cloud IdP. Your options here depend on how you’re integrating with your IdP.

The first cloud IdP that Jamf Connect integrated with was Okta (this was prior to the acquisition). This integration uses Okta’s proprietary APIs. Users type their passwords into the Connect app, which sends it to the Okta APIs, but at the same time, Connect can also see the password and set it in the local account. Connect also steps in with a browser extension.

If you’re integrating Jamf Connect with your IdP via SAML, the authentication happens in a web view, and Connect can’t “see” the password, so there’s no way to keep it in sync. This is how the Azure AD integration works. They’re planning to do Google support next, as well as other generic IdPs, and they’ll all work this way, too.

Really, though, not having the same password is not the end of the world—instead, it’s indicative of where things are going. On a mobile device, you don’t worry about keeping the local PIN the same as the password on the user’s account. And going forward, the user might not even use a password as their primary authentication method with their IdP.

A few notes about the product

The open-source, free versions of NoMAD (NoMAD and NoMAD Login) are still available. These work with traditional Active Directory, but don’t support cloud identity providers.

What’s cool is that all versions of NoMAD and Jamf Connect can actually work with any Mac management platform—they’re all configured and pushed using profiles and MDM.

Could Apple come out in a year or three and make a macOS account that speaks SAML and other modern identity concepts? That would be great, but for now, this is where we are.

Joel is really excited about conditional access and all the other modern identity concepts, so if Apple did suddenly do more here, I’m sure he would find a good way to build on it.