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…: NoMAD Login+ Okta, soon JamfConnect…

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

As you all know, Jamf acquired NoMAD from Orchard & 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 matching local 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 admin a 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: admin@domainname, member of the groups “Admins” and “Jamf”
Standard: standard@domainname, member of the groups “Standard” and “Jamf”
No Access: na@domainname, member of the group “Jamf”
Test: test@domainname, member of the group “Jamf”

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

Creating the users:

Don’t forget to set the password “by admin” and untick “user must change password on first login”. We’ll see how we can ask the user to change the password later.
Create the standard, admin, no access and test account as said above.

Creating the groups:

Create the groups and add a description if you want:
Admins, Jamf, Standard

Adding the users to the groups:

Add the users to the following groups:
admin@domainname, member of the groups “Admins” and “Jamf”
standard@domainname, member of the groups “Standard” and “Jamf”
noaccess@domainname, member of the group “Jamf”
test@domainname, member of the group “Jamf”

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:

Disregard the 2 existing apps I have here or now. Let’s just create an app called “NoMAD Login+ test” for instance.

Select native app

Give your app a name and choose a URI. You may set this to any URI that you like, but the NoMAD Login Admin Guide suggests using “nomadoauth://oauth-callback/okta” or something similar that would not be in use by any other application.

Next you have to edit the app and tweak the grant types. Select Implicit (Hybrid) and allow both options.

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.
Add 00_ to the policy name to make sure it runs as first policy amongst other “enrolment complete” policies.

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 (test@domainname).

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!

Log in with the Admin test user we created!

Although we commented the “CreateAdminUser” command out of the script, the user is now getting administrator privileges based on the Okta group.

Log out of the Admin user and try the Standard test users.

Right! Standard privileges!

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…:

Very handy if you want to point your users to a FAQ webpage!

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:

Go back to you “Login app” and have a look at the Sign On tab

At the bottom you see that by default all users assigned to the app are allowed.

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

Add a new Sign On policy and apply it to the “No Access: test user you created earlier. Put the Access on Denied.

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:

nomadLoginOkta.shDownload

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:

I’m using the Okta Verify app with Push Notification.

Go to Factor enrolment and add a policy to require the use of the Okta Verify app for MFA. I renamed my existing MFA policy to “Jamf” here and assigned it to my “Jamf” group.

Once you add the policy, you have to add a rule. This will force users to set up MFA on their next login.
! Don’t forget to exclude your LDAP service account if you are using the Okta LDAP Interface !

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.

The user logs in with his/her Okta username and temporary password.

And Okta will instruct the user to configure MFA.

After clicking on setup and following the instructions to download the Okta verify iOS app, the user can easily configure MFA from within the NoMAD Login+ screen.

And change the password, as we asked to do so at first login when we created the user in Okta.

Click “done”.

And log in again.

MFA kicks in!

And after approving, the local user is created!

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:

User will be asked to change the temporary or expired password, and log in again.

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