Using NoMAD to Replace Traditional AD Binding on macOS

Another day, another problem with Apple's implementation of Active Directory bindings on macOS. Our current issue is that employee laptops, which are bound to AD, do not reliably authenticate over WiFi. We have applied a Configuration Profile that is supposed to use the credentials entered on the login screen to sign in to WiFi, which should then allow it to authenticate to AD, but this does not work consistently, either - only some accounts can log in, and even then only after a few tries. Our networking team has confirmed all of our settings, so it seems like there is some fundamental issue with the combination of macOS, AD bindings, and our WiFi setup.

One potential solution to this chicken-and-egg problem is to create a special account that Macs could use to pre-sign in to WiFi on the login screen, which would allow users to enter their AD credentials and log in just like if they were on Ethernet. You could then use a logon Policy to disconnect from the WiFi network, and then the user would log in with their own credentials. However, this doesn't address some of the other problems that AD-bound Macs have, such as the problems in synchronizing their account credentials with FileVault 2, and the difficulty with SecureTokens in newer versions of macOS if Macs are set up with DEP-based PreStage Enrollments, and therefore never have a local account manually created.

So, since Apple seems to be slowly breaking their AD implementation bit by bit with new features that don't integrate well with it, the more manageable solution is to forgo binding Macs to AD altogether - at least those that will be used primarily on WiFi, or those that need to have FileVault 2 encryption enabled. Local accounts just work better. Unfortunately, it's also a lot of work to make sure that users are updating their local account passwords when their Domain account credentials change, and eventually people may just give up.

NoMAD - from IT's perspective

Enter NoMAD. NoMAD is an application that replaces the traditional AD binding on a Mac with a combination of local accounts and a utility to help synchronize passwords between the two whenever either credential changes. In our implementation, we deploy the NoMAD installer .pkg using Jamf, along with a LaunchAgent to start the application whenever a user logs in, and a default Preferences file with settings provided by NoMAD for customization and setup purposes.

The LaunchAgent script is a simple cat command that creates a .plist file in /Library/LaunchAgents. In this location, the .plist is run for any user who logs into the machine, running under their own session and with their own credentials. Therefore, any changes that may be made in the application are applied only to that user, which is important for an application like NoMAD that deals with AD credentials.

The LaunchAgent script is similar to the following:

#!/bin/bash
cat > /Library/LaunchAgents/com.example.NoMAD.plist <<EOF
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key>
<string>com.example.NoMAD</string>
<key>LimitLoadToSessionType</key>
<array>
<string>Aqua</string>
</array>
<key>ProgramArguments</key>
<array>
<string>/Applications/NoMAD.app/Contents/MacOS/NoMAD</string>
</array>
<key>KeepAlive</key>
<true/>
</dict>
</plist>
EOF

NoMAD also supplies a .pkg that creates a LaunchAgent for you, if you prefer to use that instead.

We use another script to create a default preferences file, /Library/Preferences/com.trusourcelabs.NoMAD.plist:

#!/bin/bash
cat > /Library/Preferences/com.trusourcelabs.NoMAD.plist <<EOF
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<!DOCTYPE plist PUBLIC "-//Apple/DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>ADDomain</key>
<string>domain.com</string>
<key>KerberosRealm</Key>
<string>DOMAIN.COM</string>
<key>LocalPasswordSync</key>
<true/>
<key>UseKeychain</key>
<true/>
</dict>
</plist>
EOF

So, we combine the NoMAD installer .pkg with the two scripts above into a Policy, then add our laptops into the scope, and at the same time we unbind them from AD to prevent any possible issues. Deployment proceeds as with any other application.

One implication of this setup is that user accounts must be created locally before they can be used, in contrast to AD/mobile accounts that are created on first sign-on. This could be done via SSH or Jamf Remote, or manually, depending on the situation. Happily, since NoMAD handles synchronization of passwords between local accounts and AD, the technician who creates the account can just give it a password like "password", and NoMAD will prompt the user to change it after their first login.

NoMAD - from the user's perspective

The user will probably not interact directly with NoMAD very much - mostly, they only need to use it when their password changes, in order to update their local account to match. On first login, the user enters the local account credentials provided by IT in order to sign in to macOS. Once there, they sign in again, this time into NoMAD, using the menubar icon.

NoMAD prompts for the user's AD credentials, which it then uses to authenticate against the AD server specified in the Preferences file.

Once this is done, the Mac works more or less the same as if it were joined to Active Directory, with the added benefits that things like FileVault 2 password synchronization actually works as it should, since it is actually using local account credentials.

Fix "Network accounts are unavailable" on macOS Login Screen with a caffeinate LaunchDaemon

On Macs that are bound to Active Directory, you may from time to time see this popup next to the username box on the macOS login screen:

In most cases, assuming that the Mac is in fact connected to a wired Ethernet connection, this is not actually true, and if you try to log in with your AD credentials you will be successful, and if you wait 30 seconds or so, the message will go away. This message usually appears when the Mac has not been in use for a while and fallen asleep, or after booting up.

It seems that this is probably caused by a decision to show the login screen as quickly as possible, to the point that the network stack and/or AD connection is not fully initialized by the time it is visible. When you try to log in, it kick-starts the OS into loading everything, and should let you right in. However, if you are bothered by this, or have users who are, there is a simple fix that has some other benefits: creating a LaunchDaemon running caffeinate.

caffeinate is a macOS Terminal command that creates an "assertion" to keep certain parts of the computer from going to sleep. These assertions inform the System Management Controller (SMC) that the Mac should not sleep because an application requires it to stay awake, because a user is currently active, etc. Different assertions have different effects, which are reflected in caffeinate's different options. For example, to keep a Mac from putting its display to sleep, you can use caffeinate -d, and, to keep the disk from sleeping, use caffeinate -m.

To keep the Mac from going into idle sleep, which is the state in which the network stack appears to turn off, causing the popup, you can use caffeinate -i for desktop Macs, and caffeinate -s for mobile Macs. This difference is important: -i creates an assertion that does not let the Mac go into idle sleep at all; -s creates an assertion that is only valid when the system is running on AC power, meaning that a laptop will not stay awake in a bag, or other potentially damaging situation, as long as it is disconnected from its charger.

You can also use the caffeinate command to create an assertion that is only valid for a certain number of seconds, with caffeinate -t <seconds> -<mode>, or to create one that stays valid as long as a certain command is running, such as caffeinate -i make to keep the Mac awake as long as make is running.

So, with all of that out of the way, how can you use caffeinate to prevent that message from popping up on the login screen? Use a LaunchDaemon. LaunchDaemons run at system startup, and continue running regardless of whether a user is on the machine or not. I use a LaunchDaemon like this, located at /Library/LaunchDaemons, to keep the popup from appearing on our lab desktop Macs:

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE plist PUBLIC "-//Apple Computer/DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<dict>
<key>Label</key>
<string>com.example.caffeinate.plist</string>
<key>Program</key>
<string>/usr/bin/caffeinate</string>
<key>ProgramArguments</key>
<array>
    <string>/usr/bin/caffeinate</string>
    <string>-s</string>
</array>
<key>RunAtLoad</key>
<true/>
</dict>
</plist>

Install that LaunchDaemon and reboot the Mac to make it take effect. The popup will still appear for 30 seconds or so after a reboot, as the OS hasn't had a chance to initialize everything yet, but it should not reappear afterwards. This still allows the screen to go to sleep, as well as the HDDs, but keeps the rest of the OS awake so that the popup does not appear.

Since this keeps the networking components of the OS awake, it also helps resolve situations where pinging a Mac that has gone to sleep can take several tries as it tries to wake up. This, therefore, makes the process of getting Macs to check in to Jamf or another management system more reliable.