How to use NoMAD Login+ Okta with Jamf Pro? - Travelling Tech Guy (2023)

Warning… this is going to be a long one… grab a coffee, or maybe a few as I’ve tried to be as complete as possible on this one! ☕️☕️☕️

As said, time to step away from LDAP blogging for a moment. But rest assured, not for long, I still have Microsoft Azure on my to do list for the blog, and guess what… that moment I published the previous blog about Okta LDAP Interface, Jamf announced the upcoming compatibility with Google Cloud Secure LDAP… so yeah, whenever I’ll get my hands on that I’ll have to do another post on it. There is no way around LDAP it seems… 🙂

Anyway, for this post we’ll have a look at something cool, although it is still closely related to Directory and Identity services…: NoMADLogin+ Okta,soon JamfConnect…

Jump to the tech tutorial and skip the small talk here.

As you all know, Jamf acquired NoMAD fromOrchard & Grove and this means that NoMAD Pro, NoMAD Login+ and PKINIT join the Jamf family and will fold into a single solution (rebranded Jamf Connect). This while the open-source version of Nomad remains open-source (with free Jamf chat support).

I have no insight in what this single solution will look like at the moment, for sure “Jamf-style cool”, but in this post I’ll just cover the NoMAD Login+ Okta, as it is today. Once the rebranded single solution is available we’ll have a look at it again. The idea behind this part of the solution will most likely remain the same I guess.

So, what is NoMAD Login+ Okta? Well, first of all, the other product, NoMAD, gives you the possibility to step away (as far as you can for your own sanity as a Mac sys admin) from binding Macs to Active Directory (see link for more details). And this while still keeping the benefits of AD binding. It’s like getting all the rewards, without doing any effort for the job…

NoMAD Login on the other hand, allows you to authenticate with AD users at the macOS login screen. Both at initial deployment as later when the Mac has been configured. Logging in with AD users on a Mac? Not that special when Macs are bound to AD, but pure magic without the bind! The power of the tool lays in the fact that endusers can use their Directory credentials, without being bound, to create a matchinglocal user account on the Mac. And this allows you to start the initial configuration of the Mac (or user environment) with best practices (read: not binding your Macs if you don’t really need to). This makes your life as a sys admina lot easier further down the road. Trust me!

Add NoMAD as a next step after NoMAD Login and forget about all the hassle of managing all kind of issues you might have with binding Macs to AD… keychain issues to start with!

I’ll for sure dedicate one of my next posts to NoMAD (or maybe by then it will be JamfConnect), but let’s limit it to NoMAD Login for today, and more specifically: NoMAD Login+. While NoMAD Login is made for Active Directory, NoMAD Login+ is developed to authenticate against Okta.

So this nicely fits in line with my previous post about the Okta LDAP Interface.

For those who are not using NoMAD Login+Okta yet, have a look here and download the trial if you want to take it out for a spin. The DMG you’ll download will also include the admin guide… always handy!

Tutorial

So, allow me to go through the workflow I followed to deploy NoMAD Login+ Okta in my testlab:

First, aside from having an Okta account of course (get your free dev account here), we need soms users and groups in Okta. For the purpose of this tutorial I made the following users and groups:

Admin: [emailprotected], member of the groups “Admins” and “Jamf”
Standard: [emailprotected], member of the groups “Standard” and “Jamf”
No Access: [emailprotected], member of the group “Jamf”
Test: [emailprotected], member of the group “Jamf”

I’ll come back to why I created different users and groups later.

Creating the users:

Creating the groups:

Adding the users to the groups:

Next, we need an Okta app. One app to start is enough, but I’ll come back to why I created more apps later in this post.

Create the app:

Finally you’ll have to assign users to your app. Let’s assign it to the “Jamf” group we created (with our test account as member):

Done! This Okta setup would basically be enough for a first trial run in Jamf Pro, but to make the first test deployment look a bit nicer I created a PKG in Composer with a logo and a desktop wallpaper (add a path to a folder on the hard disk where you’d like to put a copy of the files):

Upload this PKG and the NoMAD Login+ PKG to your distribution point and add to following script to Jamf Pro. The script below is a stripped version of the original script made by SRABBITT. See below for the full version.

#!/bin/bash
 #NoMAD Plus / Jamf Connect Login Okta preferences file creation.
#Writes a NoMAD+ Login preferences file.
 #Argument 4 Address of your Okta server. Example is dev-1234.oktapreview.com
#Argument 5 Fully qualified path to background image for CheckOkta window
#Argument 6 Fully qualified path to login logo image
 #Usage: Use as a script in Jamf Pro to set the preferences file after you've installed the Jamf Connect Login package
#Rev: 1.0 — SRABBITT September 27, 2018 9:43 AM
 TheURLOfYourOktaServer=$4
pathToBackgroundImage=$5
pathToLogo=$6
 #AuthServer - Set the Okta domain you want to authenticate against
defaults write /Library/Preferences/menu.nomad.login.okta.plist AuthServer -string "$TheURLOfYourOktaServer"
 #CreateAdminUser - Makes the new users on the machine an Admin
defaults write /Library/Preferences/menu.nomad.login.okta.plist CreateAdminUser -bool TRUE
 #LoginLogo - Path to an image to use for the logo at login
defaults write /Library/Preferences/menu.nomad.login.okta.plist LoginLogo -string "$pathToLogo"
 #BackgroundImage - Path to an image to use for the background of the CheckOkta mechanism.
defaults write /Library/Preferences/menu.nomad.login.okta.plist BackgroundImage -string "$pathToBackgroundImage"

The final step is creating a policy to deploy this to our test Mac. For the purpose of this post I used my DEP test device, but you could test it with any other deployment trigger. I actually used a Virtual Machine which I configured with a serial number and some other attributes to behave like my DEP test device. I’ll put a tutorial on how to achieve this on my “blog to do list”, but don’t hesitate to contact me if you’re interested in doing so. I would advice using a VM for testing to allow you to take a snapshot before deploying NoMAD Login+, allowing you to quickly revert back and do additional tests. I’m using a DEP prestage where I asked to skip the user creation and most of the Setup Assistant steps.

Note: Since macOS High Sierra you have to be careful not to skip too much if you want to keep the "Location Services" prompt. Due to the fact that Location Services, App Analytics and Siri are now combined in the "Express Setup" screen you have to leave those prompts enabled. Skipping one of those options will skip the "Express Setup" screen entirely.

Trigger: enrolment complete
Frequency: ongoing
Packages: logo/wallpaper.pkg and the NoMAD Login+ Okta pkg
Script: add the script we just created and define the variables according to your Okta server and logo/wallpaper path
Scope: add your test Mac, or scope it to a Smart Group linked to the prestage of your test device.

Let the Mac enrol and explore the Magic!

The result should be that the login screen of macOS gets replaced by your NoMAD Login screen with logo and wallpaper, and you should be able to login with one of the test users you created earlier ([emailprotected]).

Cool right? Try it out, and have a look at the account in the system preferences… this should be an Administrator because we added the “CreateAdminUser” preferences to our script.

Note: For one reason or another the Sign In button does not work for me, I had to hit “return/enter” for it to work… I’ll investigate that later.

Also, using a VM gave me some inconsistent behaviour. Amongst other things macOS did not honour the “skip user creation” of my prestage. Hence the “create user” screen shows up, but just ignore it, and wait… NoMAD Login+ is deploying in the background and will suddenly kick in. I tried it on a physical machine, and all worked fine. Must be a VM thing…

I’m not adding screenshots of the full flow where the users gets created etc as I want to take it to the next level! Just for fun!

Like I said, I created multiple Apps in Okta. So let’s delete the test app we created earlier and create 2 new apps:

Create 2 apps called “…Admins” and “…Login”. Assign the Admin App to the “Admins” group and the Login App to the “Jamf” group. No need to change anything else. The URI can be the same, and Okta will automatically create different Client ID’s. Just name and assign them differently.

Now we’ll change our script, and add a few extra settings:

Remove or comment the "CreateAdminUser" command:
#CreateAdminUser - Makes the new users on the machine an Admin
#defaults write /Library/Preferences/menu.nomad.login.okta.plist CreateAdminUser -bool TRUE
Add the following commands. You will need the Client ID's of the Login and Admin apps we created in Okta:
#OIDCAccessClientID - OIDC application to use for access to the Mac.
defaults write /Library/Preferences/menu.nomad.login.okta.plist OIDCAccessClientID -string "0oagmv3au34YraqIM0h7"
#OIDCAdminClientID - OIDC application to use to determine who is an admin when a local account is created.
defaults write /Library/Preferences/menu.nomad.login.okta.plist OIDCAdminClientID -string "0oagmp9gu63723BAY0h7"
And to use another cool feature, add a command to display a "Help Page" to your users:
#HelpURL - URL to show at the loginwindow to allow for onboarding or Okta enrollment
defaults write /Library/Preferences/menu.nomad.login.okta.plist HelpURL -string "https://www.travellingtechguy.blog"

Now, revert your test Mac to a state before you deployed NoMAD Login+ Okta earlier, and let it go through the DEP process again (or rerun the policy). Let’s have a look!

There you go! Admin and/or standard user privileges according to the Okta groups of your users!

Also, have a look at the NoMAD login screen and hit the help button…:

Note: see below on how to use this “help page” even better (see MFA).

Now, one more thing! Imagine there is a specific Mac you don’t want certain users to use. Well, you could off course change your app assignment strategy, and assign the login app to specific groups, but there is another way of achieving it by using the Sign On policies for the Login app:

By adding additional Sign On Rules you can tweak access privileges through NoMAD Login+:

Go back to your test Mac and try to authenticate with the “No Access” users… right no access 🙂

Those are just a few of the features which are available in NoMAD Login+ Okta, but have a look at the Admin Guide for all the available options to configure. Below you’ll find the full script with all the options listed. Just uncomment what you need and adjust where needed:

So, after all this awesomeness, that’s it right? Well, not yet! Let’s push it even further and see what else we can do!

Remember my previous post about the Okta LDAP Interface and MFA? What about adding MFA to this NoMAD Login+ workflow? Let’s have a look!

First we enable MFA in Okta:

Now, create another NEW test user, set the temporary password, require to change it at first login, add the user to the test group “Jamf”, and try to log in with this user on the test Mac:

Because this new user did not configure MFA yet, NoMAD Login+ will ask the user to do so and show the Help page…

So, how will the enduser without access to his/her Mac be able to “Sign in to Okta to set up MFA”? Well, by pointing the “Help page” to your Okta portal in the script we deployed for NoMAD Login +.

#HelpURL - URL to show at the loginwindow to allow for onboarding or Okta enrollment
defaults write /Library/Preferences/menu.nomad.login.okta.plist HelpURL -string "https://YOUROKTAPORTALURL"

So I changed the Help page URL to my Okta portal.

You could also point it to an internal FAQ page which has the link to Okta… but to allow users to configure a Mac via DEP from wherever they are located (outside company network) using the Okta portal as Help page might be handy.

How cool is that! This actually avoids the chicken or the egg situation I mentioned in my previous post about using LDAP authentication during DEP. The only disadvantage we have with using Okta through NoMAD Login this way, is the fact that without the LDAP authentication, the devices are not automatically assigned to the users in the Jamf Pro inventory. This can however be fixed with post enrolment scripts or Jamf API tools, or maybe an idea for a feature request for JamfConnect…

Apart from using MFA, I just want to add one last thing. What if you only require the new user to change the temporary password at enrolment, without setting up/using MFA. Well no worries, just remove the “prompt for factor” in the Okta sign on policy (for the …Login app) and you would get something like this when the user signs in:

Now, that’s really it folks! Enough restoring VM snapshots madness for today. Time for ?

Have a look at the NoMAD Login+ Okta Manual for additional features like enabling Filevault, forcing an Okta login for already existing users, resetting the Login Screen to the macOS default etc…

Let me know if I missed something major, and don’t hesitate to make corrections or suggestions!

As always, if you liked this post hit the like button, tell your friends about this blog and leave a comment below!

Grtz,

TTG