Business case for a NoMAD Login deployment

New Contributor II

I need to come up with a business case for deploying NoMAD Login within my organization. We already deploy the NoMAD utility, but still bind our Macs to AD as our 802.1X Wi-Fi network requires eligible systems to be domain joined. However, in the medium term I'm hoping to go down the NoMAD Login + Jamf AD-CS Connector route instead.

My superiors are asking for a bit more technical detail on how exactly NoMAD Login works i.e. how passwords are obtained and stored, and how the product can ensure it remain secure. I've googled, but any content I have come across is a little light on detail.

Has anyone been through these cycles and can offer me any pointers?

Your advice is very much appreciated!


Contributor III

The first thing to do is to share this WWDC session with them. Mike Boylan goes into some detail into the circumstances under which Mobile Accounts via the AD plug-in are supported (in general they're not recommended.)
Someone else may correct me, but I believe NoMAD Login obtains passwords similarly to NoMAD which you may have already seen here
Password storage is all done on the OS side, so there's no difference in how a password is stored using the AD plug-in vs. NoMAD with the exception of the optional Keychain entry you can create to facilitate an SSO like experience between NoMAD Login and NoMAD (the menu app.)

New Contributor II

NoMAD Login and NoMAD uses all the Apple built in mechanisms for kerberos password verification and changing. These are the same mechanisms used by the internal macOS binding mechanisms.

eg. gss_aapl_initial_cred() and gss_aapl_change_password()

The password is never stored on disk outside of the macOS user account database with binding also utilizes, and is cleared from memory once utilized to perform necessary tasks.

As for a business use case, It very much depends on your deployment methodology. The biggest thing I say though is that in a mobile account environment with remote employees you CAN NOT do a filevault recovery using the recovery key. This is due to the fact that during the password change in recovery mode the device must reach out to your domain controller to perform authentication. Obviously in a remote employee scenario this is not possible. The local account nature of NoMAD Login created accounts makes this not an issue.

If you haven't checked out the NoMAD Security page I recommend doing so:

Also I gave a presentation giving a State of the Union on binding at this years JNUC: