NoMAD Login AD and DEPNotify

While continuing my journey in finding efficient workflows to manage Secure Tokens and FileVault on Mojave, I side-tracked to testing NoMAD Login AD in combination with DEPNotify.

I’ll come back to which workflow I’m using it for in my next post, but for now, just imagine a more general scenario where you want to create a local account based on AD credentials. But also avoiding the BIND and all its disadvantages (including potential keychain, FileVault and Secure Token issues) and use the power of DEPNotify to inform the user about what’s going on when they login.

NoMAD Login AD is your friend here! Similar to NoMAD Login+ Okta, where you base the account on Okta users. With NoMAD Login AD you benefit from having the local account credentials to be the same as the AD account. A good start for adding Jamf Connect/NoMAD later in the deployment.

Note: Just remember that NoMAD Login AD/NoMAD Login+ Okta have different purposes than the NoMAD/JamfConnect products. While the 'Login' products are used to create user accounts based on AD/Okta, the NoMAD/JamfConnect tool is used within the user session to handle keychain, kerberos tickets, password sync, etc... Have a look at nomad.menu for more details.

Initially I tried to deploy NoMAD Login AD and DEPNotify ‘@Enrollment Complete’, and trigger the launch of DEPNotify via a ‘login policy’. The problem I had here was that, when you log in with NoMAD Login, it hangs on ‘checking for policies’. AFAIK this makes sense because NoMAD Login is creating the account, while the login hook already tries to launch my DEPNotify script. So a policy running at login was not the way to go.

This brought me to trying a Launch Daemon to call a the DEPNotify script, and after many tries I finally got it to work! Timing is crucial here, as the script needs to run when the user is fully logged in. Not earlier because the login window will break the process.

So, let’s see what solution I came across – also (update 30th of November) check out the JNUC 2018 video below!

DISCLAIMER: as always, all scripts and workflows are provided as proof of concept. Test and evaluate before using it in a production environment.

Click here to jump to the workflow.

First of all, let’s have a look at NoMAD Login AD, aka NoLoAD. Download the installer from nomad.menu. This will give you 2 installer pkg’s and some additional files for testing purposes. To deploy NoLoAD you need to add the NoMADLoginAD-1.2.1.pkg and NoMADLoginAD-1.2.1-authchanger.pkg to a policy @Enrollment Complete, as well as create a script or a plist to configure the settings. 

I think the plist or mobile config file is the preferred way of doing things, but I find the script handy because I can just tweak things quickly in the Jamf Pro settings. The script uses the ‘defaults write’ command to write some settings in the ‘menu.nomad.login.ad.plist’. Below is a quick example I used, setting a few options via the script variables in Jamf Pro. Very basic, but those are actually the most important settings to start with. Have a look at the NoLoAD admin guide (see files you get when downloading the installer) or the wiki for more options.

Once your script is ready, add it to a Jamf Pro @Enrollment Complete policy and add the 2 NoLoAD installers. Because I’m setting a custom logo and wallpaper, I’m also adding some additional pkgs to install those. Yes, this could all be done a bit cleaner by combining everything in one package, but this gives me more flexibility when testing.

Note: Jamf Pro 10.9 beta includes the option to deploy a pkg during the DEP process, as part of the pre-stage. This would actually allow you to deploy NoLoAD and custom images, as well as DEPNotify (see below), in one big pkg and use a 'post-install' script to put everything in place. To be tested, for now I'll stick with the current functionality of Jamf Pro 10.8.

That’s it for the installation of NoLoAD. The installers are going to put everything in place, and the script is going to swap the normal macOS Login Window with the NoLoAD login window. Scope it, enrol a test machine, and log in with any AD Account. NoLoAD creates the local account, and if you granted admin rights (‘CreateAdminUser -bool true’) you even get your oh so important Secure Token :-). I’ve been using NoLoAD for a long time now and it just works awesomely well!

But then I tried to combine it with DEPNotify….
Well, let’s first have a look at DEPNotify on its own.

The way DEPNotify works is similar to NoLoAD. A bit different, but similar. You launch the app and control it by echoing commands in a control file. As stated here. I could create the control file, but again, I prefer the scripting method for more testing flexibility. Have a look here to see all commands you can configure.

Looking at how to deploy and run DEPNotify with Jamf Pro, we have multiple options. The general idea is however that we deploy the app and a control file/script to run/control it. The triggers to use will depend your deployment strategy, but you need to make sure the app launches when the user is logged in. When enforcing settings on a new Mac, you want to make sure DEPNotify runs ASAP when the end user logs in but not before. You don’t want to start DEPNotify when the Mac is still at the login screen or in the setup assistant. Hence additional scripting might be needed.

As said above, this was exactly the challenge I faced when adding DEPNotify to a NoLoAD workflow.

Therefor, as well as the fact that I’m not a big fan of the ‘login’ trigger in general, I went for another option: putting my faith in something else, Daemons! Well, Launch Daemons that is!

NoLoad and DEPNotify workflow

Update 30th of November:

While going through some JNUC 2018 videos yesterday, I came across the following presentation. As I did not attend JNUC this year I was not aware of this keynote. First of all, if I would have known, this would have saved me so much time :-). But yeah, you learn by doing! 

Secondly, it seems that in my search to find a solution, I via via got parts of the script they made at Uarts. Hence, hereby all credits to John Malhman (Uarts) as he actually also has the part I was missing to nicely clean up some files without quitting DEPNotify too early. Have a look at my journey below, but check out this video to complete the script

Quick overview of the workflow:

1. End user boots a new or wiped Mac and goes through the pre-stage
2. Because we skip the account creation, the user is temporarly stuck at the login screen. This should only be seconds to a few minutes, depending other @Enrolment Complete policies
3. @Enrolment Complete policy installs DEPNotify and the Daemon,  user still stuck at the login screen
4. @Enrolment Complete installs NoLoAD, the login window swaps to NoLoAD and the user can log in
5. In the mean time the Launch Daemon is waiting for the user to be logged in and launches DEPNotify ASAP

First of all we create the Launch Daemon. I’m using a script which I’ll add as post-install on the DEPNotify package:

This little Daemon is going to try calling our launch DEPNotify script, and do so every 10 seconds. However, we need to make sure that the user is logged in and the Mac is not sitting at the NoLoAD screen. Hence we need an ‘if’ statement to make sure that the following conditions are met: user logged in AND Dock & Finder are loaded. Next we set some variables, create some files and echo commands and status updates into the NoLoAD control file. More info on how to use those here.

This example is creating some dummy actions, inform the user the setup is done and ends with a logout button. This can be handy, especially when you are enforcing FileVault with a Jamf policy as part of your DEPNotify workflow. Because of the ‘logic’ in the script, DEPNotify would exit at the end of the ‘if statement’. So I added a sleep of 3600 seconds. I should take the time to review the logic but for now, as a proof of concept, this should do. After 1h the DEPNotify would exit, but this would actually be the same if the endusers just kills the Mac and reboots.

Additional logic will be needed to check setup conditions and relaunch DEPNotify if needed. As well as cleaning up some files, like deleting the app, control file and the Daemon. Time permitting I will work on this and update when applicable. Update 30th of November: check out the JNUC 2018 video here for a clean way to fix this, as well as his github.

Commands in the example above can be replaced by custom triggers for Jamf  Pro policies, such as: 

echo “Status: Enabling FileVault” >> #DNLOG
$JAMFBIN policy -event DN_requirefilevault

Next we put Jamf Composer into action! In the script to launch DEPNotify I’m relying on DEPNotify to be installed in the ‘/var/tmp/’ folder. So that’s where I’ll put both the app and the script, as well as the custom logo.

Finally, before creating the pkg, let’s add the post-install script which will launch the Daemon:

Hereby the result: a pkg installing DEPNotify, the launch script and the logo in ‘/var/tmp/’, running a post-install script to create the Daemon.

Upload it to Jamf Pro and create the @Enrolment Complete policy.

That’s it! Boot your test Mac and let it go through the pre-stage process:

That’s it! A DEPNotify workflow compatible with NoLoAD (or when binding to AD).

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

Brgds,
TTG