Level Up Your Deployment with Enrollment Customization

Apple is famous for the out-of-box experience new users get when they open up a Mac, iPhone, or iPad for the very first time. Kandji can help make that unboxing moment even better—for you as an Apple admin and for your users—with enrollment customization, by requiring users to sign in with their Single Sign-on (SSO) credentials the first time they boot up a new device. It’s a streamlined experience for you and for them; as they authenticate, they can be automatically matched from your user directory and assigned to their devices. 

Kandji recently added support for enrollment customization. Kandji’s Head of Solutions, Weldon Dodd, recently hosted a webinar to talk about how this new feature works. Here’s what he had to say.

Enrollment Customization and SSO

We’re going to talk today about enrollment customization—what Kandji is doing with it and how you can utilize it for your organization.

Enrollment customization is Apple's term for customizing the Setup Assistant experience that many of us are familiar with. When you start up a new Mac for the first time, it will boot to Setup Assistant, which guides you through configuring the computer, making choices about language and region, connecting to a network, and so on.

What enrollment customization allows you to do as an admin is insert some screens into that Setup Assistant sequence via MDM. What we've done specifically here at Kandji is to let you insert authentication screens, so you can ask users to enter their SSO credentials for whatever identity provider (IdP)—Azure AD, Google Workspace, any SAML 2.0 provider—your company uses, the same credentials they use for signing in to other services and tools.

That gives you the ability to authorize enrollment into Kandji. As the device enrolls, you're going to deliver configurations, security settings, certificates, and so on to it. Having a step in there to make sure that this user is authorized to enroll into Kandji allows you to be confident that the device to which you're pushing those configurations, settings, and certificates is in the hands of a user that you trust. This step also allows you to associate the device with a specific user in Kandji.

You can limit or control access to authorization on the IdP side. Using Okta as an example, you could place restrictions on what zone they're in—whether they're in the United State, for example—or what group that user belongs to. 

Customizing Setup Assistant

To make this happen, you first need to create an SSO connection in the Kandji Web App (Settings > Access). Then, in the Automated Device Enrollment (ADE) Library item, you can select the Require Authentication option with the new SSO connection. You can also specify which Setup Assistant screens you want to present or whether you want to automatically advance through all of the screens.

Once ADE is set up, when the user gets the device out of the box and starts it up, they’ll get to a screen where they can enter their SSO credentials, That authorizes enrollment, and they can then proceed with the rest of the process. 

When the device is ready to add user accounts, there are two ways you can do it. You can allow users to create their own accounts—they pick the username and password. You can choose whether or not to make those accounts Administrator or Standard. 

But there’s also an option in Kandji’s ADE setup to Provision Local Administrator Account. That enables you to create an admin account on the user’s device. One of the tricks here is that you can use global variables to pre-fill some of the information required to create that account.

So if, for example, you want to use the user's email prefix—everything before the "@" symbol—as the default username, you can pre-fill that information. You can also pre-fill a password. But note: Every account created this way would have the exact same password initially. So as part of your process, you'd want to make sure these users change their passwords after they're logged in.

Cloud vs. Local Credentials

Just to be clear: SSO credentials are used only for enrollment. Kandji uses that information on the back-end to say, this user signed in to this device. But that information is not used to set up the local computer account and password. As I said, there’s a way to do some of that with global variables in the Kandji Web App, but that may not create the user experience you're looking for.

Some companies choose instead to allow users to pick their own local computer account names and passwords and use those credentials in a way that's similar to the way that they’d pick PIN codes on their iPhones. No one really expects that the PIN code on their phone will match their corporate SSO credentials. You unlock the device first, then you sign in separately to corporate accounts and services using SSO. You can treat the macOS login experience the same way, where there’s a local account that unlocks the device, then the user signs in with IdP credentials to get access to additional services and applications that are tied to that SSO.

There's definitely a desire to have local and cloud credentials in sync, just because it would reduce some of the support tickets and help desk requests—"I forgot my password" or "I can't remember which password to use in which situation." But it's still very much the case that the local computer account is separate from cloud identity.

Extensible Enterprise SSO

With some identity providers it’s possible to sync the user's local password with the IdP. That process is enabled through the Extensible Enterprise SSO framework that Apple provides. 

Today that means, if you have a local on-prem Active Directory domain controller, you can use the Kerberos SSO extension to enable password synchronization between the local account and Active Directory. That works very well; a lot of Kandji customers do that. It's really a superior experience to what you may have experienced with binding to Active Directory, because it allows for a loosely coupled integration between the local account and Active Directory.

By loosely coupling through the Kerberos extension, if you reset the password in Active Directory, the user can still sign in to their computer with their existing local computer account credentials. But the next time they authenticate with the Kerberos extension, they'll see a prompt saying, “Hey, your password for Active Directory is different from your local computer account.” That allows those passwords to be updated in all the right places at the same time.

That's available today with Active Directory. The Azure AD extension is available in a public preview, but the password sync feature is not yet enabled there. Other providers such as Okta are working on adding their own extensions to this process. That's coming in the months ahead.

It's exciting to look forward to a time when we can automate the process of configuring the account. Having that enrollment customization piece in there now can help you make sure that you've got the device in the hands of the right person, to authorize the enrollment, and to preconfigure some of the account settings. From there, Apple's SSO extension framework enables the ability to synchronize the local account password with the IdP. That process does depend on Apple and the identity providers working together to create their own extensions. Kandji, of course, is prepared to deliver those extensions and install them as part of what we do with MDM.