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.
The secret sauce to making this all work is
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
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
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
Three preferences control
KeychainReset. Since this is already well documented
here’s a description direct from the official
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.
KeychainCreate controls if NoMAD Login should create a Keychain if it doesn’t exist.
KeychainReset controls if NoMAD Login should reset the Keychain if the login pass doesn’t match.
Boolvalue. 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
KeychainAdd 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.
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
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.
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
/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
KeychainAdd writes the
LastUser key into NoMAD’s preference file at
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
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
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
and automatically sign in.
In the totally unedited 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.