With multifactor too!
This post will take a high level view of using and MDM (SimpleMDM), JAMF Connect and InstallApplications for “touchless” deployment of macOS. This deployment method uses Munki as the primary tool for package management, and has been in place since the “NoMAD Days.”
Big assumptions. You are familiar with MDM and the process surrounding macOS, and have some knowledge of InstallApplications. You are using Okta as an IdP, have the needed services and are paying/testing JAMF Connect.
Whats happening here…
This was born out of the following scope:
- “Touchless” Deployment of macOS
- Manage user accounts and provisioning
- Desire for 2FA for login/SSO
- Users are “managed”
User gets a machine
They power on and… Assuming your MDM workflow is setup correctly and you’ve configured Install Applications for your needs…
- Munki (and Middleware)
- Jamf Connect (Login+ Okta, LaunchAgent and Sync)
- Images/Assets for branding
After the initial setup process, the machine will load those aforementioned tools and assets prior to the login screen, giving your user a branded JAMF Connect Login screen. I’ve completely disabled the ability to create an account on the machine via the MDM.
User Account Creation
Account setup in Okta
This is controlled through JAMF Connects OIDC groups as outlined in the NoMAD Login+ Admin Guide.
Using OpenID Connect Applications to Manage Authentication NoMAD Login+Okta can use native applications created in the Okta admin dashboard to shape the login process. This allows for live management of who can authenticate at the loginwindow from the Okta admin dashboard without having to update configurations on the local machine. Also this makes it easy to work NoMAD Login+ into your existing Okta account creation workflow.
Woot! So even if a user account exists, it can only login if it is in the
OIDCAccessClientID group. This is also extended by
OIDCAdminClientID group which allows the user to be admin when they are logged in, and the
OIDCSecondaryLoginClientID which is used to determine who can create local accounts after an initial user has been created.
JAMF Connect Also allows for the managed setting of
DenyLocal which will force a login through Okta (there are
LocalFallback options which won’t be explored here).
As well… the Login Window mechanism knows if a user is flagged for a change of password and will redirect to an Okta captive portal.
This forces a user to change their password and setup their multifactor because the login window redirects to predefined Okta url where the Okta account settings are enforced.
Machine Login – Local Account Creation
Once the user has setup their MFA and reset their password via Okta, the user can then login to their machine, whichis forced to auth through Okta and use a MFA, for example it could look like:
After authenticating with their username/password then verifying their mfa JAMF Connect creates the local user as prescribed by the OIDC groups as assigned to the user in Okta when the user logins to the machine for the first time.
At this point with InstallApplications already having run before login and running any additional items in the user space as needed, I have Munki run in the background to start downloading packages, but I held the actual notifications via DEPNotify until the user logged in with the JAMF Connect Sync item via its
Which then steps the user through a customized welcome via DEPNotify…
Items of Note
- Yubikey’s must be provisioned and added into Okta before the user logs into Okta for the first time. Using YubiKey Authentication in Okta
- This restriction/limitation doesn’t come into place with the Okta Push or a TOTP code
- User is provided with a temp password in on boarding materials with an assigned hardware token
DEPNotify Slack Alerts
- May be over kill, but you can integrate this process into a webhooks into you DEPNotify to notify when this process is started/finished on clients
- This will not scale well.. but if you want a little more insight into a smaller shop this is handy.
- As well as if you have an optional install into the JAMF Connect provisioning…
MDM Slack Alerts
- Again, probably doesn’t scale well… and depending on your MDM…
- SimpleMDM allows for webhooks, then you can use something like this to receive notifications on device enrollments/unenrollmcnts as well
Other items not explored
- Escrowing Keys
- Securetoken Limitations
- JAMF Connect “Demobilization” & AD
- This assumes you are using Okta as your IdP and machines are not bound to AD
- If you have Okta syncing from or mastered by your directory service, its not a stretch to see the potential for management here….
- InstallApplicatoins Package Delivery
- You’ll need to host these items publicly for the initial enrollment to work