"Touchless" macOS deployment utilizing JAMF Connect and InstallApplications
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.
The workflow:
{.alignnone
.size-full .wp-image-2258 width=”980” height=”3065”}
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
- DEPNotify
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:
{.alignnone
.wp-image-2268 width=”260” height=”185”}
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.
Machine Configuration
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 SignInCommand configuration.
{.alignnone
.size-full .wp-image-2273 width=”285” height=”117”}
Which then steps the user through a customized welcome via DEPNotify...
Items of Note
Yubikey Provisioning
- 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
Temp password
- 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
{.alignnone
.size-full .wp-image-2261 width=”546” height=”72”}
{.alignnone
.size-full .wp-image-2260 width=”554” height=”78”}- 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...
{.alignnone
.size-full .wp-image-2262 width=”550” height=”75”}
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
{.alignnone
.wp-image-2264 width=”444” height=”55”}
Other items not explored
- Filevault
- 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