Integrating NoMAD and NoLo to Auto Sign In

Published October 1, 2018 / 1051 words / ~5 minutes to read

Integrating with NoMAD has been one of the most requested features since NoMAD Login was first released. More specifically, the ability to securely pass a user’s credentials so that user is automatically signed into NoMAD. Well, the time has come. May your deployment workflows rejoice! NoMAD Login is now at a point where most users will never have to sign into NoMAD, or maybe not even know NoMAD is doing all those AD things for them in the background.

KeychainAdd

The secret sauce to making this all work is KeychainAdd, an authorization mechanism responsible for taking credentials used at NoMAD Login to create a NoMAD keychain entry, and create or reset a keychain if needed. If you haven’t already head on over to the project page to download and install the latest version of NoMAD Login - https://files.nomad.menu/NoMAD-Login-AD.zip. In that .zip file are two packages - NoMADLogin.pkg and NoMADLogin-authchanger.pkg. Install NoMADLogin.pkg.

authchanger is a binary that adds or removes mechanisms from the authorization database which NoMAD Login can then reference. For a more detailed look at how authchanger works see my last post Moving to authchanger with NoMAD Login. Otherwise all you need to do is run the commands below.

sudo authchanger -AD
sudo authchanger -print

The very last line of output after running sudo authchanger -print should read NoMADLoginAD:KeychainAdd,privileged.

Preference Keys

Three preferences control KeychainAdd - KeychainAddNoMAD, KeychainCreate, and KeychainReset. Since this is already well documented here’s a description direct from the official wiki.

Use both KeychainCreate and KeychainAddNoMAD to create a NoMAD keychain item on login.

KeychainAddNoMAD controls if NoMAD Login should add a NoMAD entry into the user’s login keychain. Bool value.

KeychainCreate controls if NoMAD Login should create a Keychain if it doesn’t exist. Bool value.

KeychainReset controls if NoMAD Login should reset the Keychain if the login pass doesn’t match. Bool value. This has the potential for user data loss. Use with caution.

That about sums it up. I have never had a need for KeychainReset since NoMAD Login is almost always used as a way to provision new accounts in my environment. Be careful though as it can delete an entire keychain. No matter your situation, KeychainAddNoMAD and KeychainCreate both need to be set for a keychain entry to be created. This can either be done through a profile or defaults commands. Below is an example postinstall script which uses defaults and a variable to set both preference keys. Since both preferences will always be included I used the same variable.

NoMAD ACL

Great, NoMAD Login is configured and ready to go. It’s NoMAD at this point which needs some attention. In order to create a functional keychain entry, NoMAD must already be installed. Without NoMAD, NoMAD Login has nothing to reference and can’t create an access control list (ACL) entry for that keychain item. The result will be a series of annoying authentication prompts asking to give NoMAD rights.

This ACL is one of the first things to check for when troubleshooting and can be found by navigating to Keychain Access > login keychain > NoMAD > Access Control. In traditional NoMAD deployment a keychain item would be created when UseKeychain is enabled and a user signs in. However, KeychainAdd is doing all that work instead. The solution is as simple as installing NoMAD first.

I haven’t tested if setting UseKeychain is necessary, but my guess is it only controls whether or not a keychain item is created, not if it’s used to automatically sign in. I’m also assuming most people already use this feature since signing in for each Kerberos ticket isn’t very user friendly.

NoMAD.app Path

The next less obvious place KeychainAdd can go wrong is the path at which NoMAD is installed. Most environments use /Applications/NoMAD.app, but I decided to use /Applications/Utilities/NoMAD.app since I don’t really want users seeing or launching it alongside the rest of their applications. And hey, it’s a utility so why not. The trouble with this is KeychainAdd hard codes the path to /Applications/NoMAD.app. If you’re like me and decide you know better, then the only current solution is to manually change the path and build from source.

There’s an open feature request to allow the path to be set with a preference. If this is of any interest to you then please upvote.

Using KeychainAdd in Production

By default NoMAD doesn’t look for a keychain item to sign in with unless a user has manually done so before. Therefore it won’t attempt to use a NoMAD Login created keychain item on first login without additional intervention. As a solution, KeychainAdd writes the LastUser key into NoMAD’s preference file at ~/Library/Preferences/com.trusourcelabs.NoMAD.plist. LastUser acts as a signpost to trick NoMAD into thinking a user, this user, actually has signed in before and to use the keychain item created by NoMAD Login.

This can be finnicky though since it means NoMAD has to initialize after the system recognizes LastUser has been set. In most cases a launch agent is used to start NoMAD after login. That method is still recommended, but sometimes it launches too quickly before all the required pieces are in place. If the NoMAD Login to keychain to LastUser to NoMAD juggling act doesn’t happen exactly as planned with precision timing then the user won’t be signed in automatically.

However, there are a couple tricks to gently massage the process along. Both can be run as part of a deployment script or with a tool like outset. The command below will force NoMAD to run its update cycle which will then recognize LastUser.

open nomad://update

If running a Jamf Pro policy the script will be running as root so you may need to begin the command with sudo -u $user like so.

sudo -u $user open nomad://update

The other less graceful (but very effective!) method is to kill the NoMAD process. When managing through a launch agent with KeepAlive enabled it will launch again after being killed. On restart NoMAD will correctly read LastUser and automatically sign in.

killall NoMAD

In the partially edited video below the workflow runs as expected.

NoMAD Login > keychain item created > LastUser key written > NoMAD launches with user automatically signed in

Any questions or feedback on this post please join us on the MacAdmins Slack team in #nomad-login.