24 thoughts on “How to use NoMAD Login+ Okta with Jamf Pro?”

    1. Yes, and I’ll go through a Jamf Connect Sync deployment in one of my next posts, but just remember that this is currently a different product than Nomad Login+ Okta. Nomad Login and Login+ is mainly “just in time user creation” at the login screen, while Jamf Connect Sync allows to authenticate local accounts to AD or Okta within the local user session.

  1. I got one question, so in a world where we dont use Jamf Pro, because of slower put through of users, or just low number of users, i can set this up manually per system, not ideal, but it gets the job done.

    How would i be able to force bootup login to go through NoMAD because right now, i still get prompted for the local admin login ,eventhough i granted access to the newly created Okta user in FileVault.

    Secondly you refer to the manual, but thats not even near a manual, i’ve been battling multiple pages and installs and file locations to find out how to set up the system, again im not going to use Jamf Pro because of costs.
    Is there anywhere besides your written blog a step-by-step to do stuff, because your script was new and made it work, but im still missing this i think need to be addressed, just not sure if it are features that arent created or arent documented.

    Lastly, wouldnt it be helpful to use the session for logging in, also stay running for Okta sign in when opening the browser, no i still need NoMAD pro to again validate, eventhough just seconds before i did the same thing.

    Love to chat!

    1. Hey HenkJan, thanks for your reply! Booting through NoMAD is not on option as such, NoMAD login is only creating the local user. The fact that you are asked for the local admin users must have something to do with the new local user (created by Nomad) not correctly having Filevault rights or secure token. The secure token is however a bit all over the place, I recently saw very inconsistent behaviors when going through DEP (or as Apple changed the naming: “automated MDM enrollment”). I have to do some additional testing to see why and how. Looking at your scenario I presume you had a Mac which was already in use, installed NoMAD login+, created a user and manually added it to the FileVault users via the original local admin?

      There are no additional step by step guides apart from the guide and some people in the community who blogged about it. Remember it has been open source till now, while it will remain open source, NoMAD products will be folded into JamfConnect. We’ll have to wait to see what Jamf does with it.

      Regarding the session, NoMAD login and NoMAD Pro are 2 separate products. Your idea to keep the Okta login active, might be handy, but not sure if that’s possible at macOS level. I know you can force the login to authenticate through Okta, via the NoMAD login settings, even if the local account was already created…but the way NoMAD login works it is only checking against Okta not really authenticating the user in macOS. I will dive into this and see what’s actually possible.

      Will let you know!

  2. Thanks for this tutorial, I finally got this to work. Just one question. How do we speed up the process from after enrollment to mac login to Nomad Login. I tried adding ‘/usr/bin/killall -HUP loginwindow’ to your post script but it take at least 15 seconds to finally see the nomad login window

    Thanks

    1. Not sure if there is anything else you can do to speed it up even more at the moment, the deployment of Nomad is based on the enrollment trigger and we don’t have exact control over this trigger during the DEP process. So it still has to download the Nomad installer on the Mac. You might however be able do to something with the “await device configuration” option, currently in Jamf 10.8 beta: https://www.jamf.com/jamf-nation/discussions/29521/jamf-pro-10-8-beta-now-available

  3. Felt it’s worth noting that at the time of writing this comment, LAPS user creation is broken in Mojave, including 10.14.1. The issue is known by JAMF/NoMAD and they’re working on it. In turn, enabling the LAPS User breaks EnableFDE. Removing any mention of LAPS from the preferences file, allows EnableFDE to work properly. Just wanted to mention that in case anyone is facing the issues I was.

    Also worth mentioning that the Enable Admin with the OIDC application works well, but with that enabled, I was having a hard time letting non-admins login, even with the “Access” OIDC set. Even removing the Access item in the preferences file didn’t help. Back to the drawing board for that one.

  4. Thanks for the guide, I got as far as getting the login screen to display, but could not log in with an Okta account, I could log in with a local account though.

    I’m not sure where I went wrong as all I needed to do was provide my Okta tenant URL (unless by now the functionality does not work correctly anymore due to the product changing to Jamf Connect).

    1. Hi!

      I’m not aware of any changes which might brake it. However, I can think of 2 things:

      – the Okta URL in the script parameter is without https://, just the rest of the URL
      – instead of clicking sign-in, try hitting enter after putting the password in. This while still having the cursor in the password field. The sign-in button does not work for me either.

      Let me know if any of this fixes it. If not, it must be one of the privilege settings discussed above.

      1. Hi, sorry for the late reply. My trials ran out for Jamf and Okta so needed to get them restarted.

        In your sample code, the first line is missing the #, maybe issues were because I copied the sample code with the missing #.
        I was also having issues with the script parameters, so instead of using them, I hard-coded the Okta server and image paths into the script. Also,

        Many thanks for the tutorial though!

          1. It is running now, works well too.
            I’m putting this together as a proof of concept to put forward to my company and this tutorial was a godsend. This takes care of authenticated login to machines (albeit by creating local accounts).
            Next up is to try and determine what the other products actually do, I asked our trial provider about trialling Jamf Connect and they gave me a jamfconnect.dmg which contains the packages jamfconnectsync and jamfconnectsyncLA.

            Anil

  5. Have you tried this with pre-stage enrollment packages yet in Jamf Pro 10.9?

    Would love to see a tutorial at some point

    1. Hi Ryan!

      No did not give that a try yet but that would indeed be a nice thing to do! I will have a look at it. I don’t expect any trouble in doing so.

      grtz,

      TTG

  6. I’m prompted to set up MFA but once I do, it doesn’t give me the option to use it on Login.

    I can set it up but can’t actually use it on the login window.

    Am I doing something wrong?

    1. Have you correctly configured the requirement for MFA in Okta? In the blogpost where I talk about: “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.”

  7. So after driving myself bonkers, is it normal to have the macOS login screen (for FileVault) on reboot/startup, then once the disk is unlocked, to be prompted by the JAMF Connect login screen? So, essentially, you need to login twice? Or is something wrong with our deployment?

    1. Hi Neil, I had a moment of confusion there as well, but I checked it. The official answer would be: “By default it will pass through the auth if the user is a valid local user, and you’ve not set DenyLocal. Login will let the OS attempt to auth the user passing the credentials provided at the FV screen.”

    2. Are you sure the FileVault password is in sync with the local password. Are you using Nomad Pro (Jamf Connect Sync) to do so?
      Do you have the DenyLocal key set?

Leave a Reply

Your email address will not be published. Required fields are marked *