Since, like, forever, we have had our Macs at school bound to our Active Directory. Initially this was to try and match the experience people were used to with logging into PCs, with a shared drive and a network ‘home’. But as we started to migrate to the cloud, the jobs of the trusty (or not) Windows server were increasingly given away elsewhere, e.g. using Google Drive for our shared drives and so on. This left the Macs just using network accounts purely to authenticate users. Was there a way to log onto the Macs using cloud credentials?

Defining the benefits

‘Moving to the cloud’ is something that is spoken of as an untrammelled good, but it’s useful to articulate the advantages. What would be the benefit of moving away from logging in on-premises Active Directory?

1. A service is the cloud is a service that is someone else’s problem if it breaks. Before we moved to Google Drive, all of the school’s really important documents just lived on a hard drive on a server in a cupboard. Whilst the data was backed up, it still was a rather fragile single point of failure. If the running of the server is handed over to people who actually know what they’re doing (e.g. Microsoft or Google), this is one less thing for a school to worry about.
2. A job that’s handled by the cloud is one less job for an on-premises server. Hopefully, if enough jobs can be given away, we can get rid of the server altogether!
3. Unifying the sign-in experience. We use Microsoft accounts in an ever-increasing variety of places, such as with federated Managed Apple IDs and as part of the initial setup process on an iPad, so if teachers are used to using the Microsoft account every day on the Macs, this will help them become more familiar with it.
4. Giving a more reliable experience. Whilst binding to AD has been part of the Mac since OS X and before, it feels like directory access is something that randomly breaks as the OS updates or upgrades. So if we just move beyond it, this removes one more point of failure.
5. Allowing remote users to log into their Macs. Since the COVID pandemic, there’s been an increasing number of users in school who need to be able to log into their Macs when not on the school network. If the Mac is still bound to the AD, this isn’t necessarily possible.
6. Moving with where things are going. Back in 2015, we moved from managing our Macs with a Mac Server running Workgroup Manager (those were the days) to an MDM approach with Jamf Pro. Workgroup Manager continued ‘working’ for several more years of macOS updates after that before being discontinued with Yosemite, but it was good to be ahead of the curve and avoid running in a brick wall. Moving away from binding to AD feels like the same sort of thing.

Enter Jamf Connect

So, what to replace network accounts with? In 2018, Jamf acquired NoMAD, which was an open-source alternative to using Apple’s directory tools for authenticating users. It then turned into Jamf Connect, a paid solution that offers it’s own login screen and a menu bar tool. How does it work?

• Installation of Jamf Connect requires a ‘jump start’, a remote support session from a Jamf technician to set it all up in your environment. A great way to get it all working!
• There is a Jamf Connect Configuration Tool that is required to set up the different settings, such as which identity provider you’re going to use as well as a plethora of different options.
• We then set up the login screen (complete with custom wallpaper) so that users were required to sign into the Mac using their Microsoft account. If an existing AD account was already there, this was converted from a ‘mobile‘ account to a standard Mac user account. The login process then asks for the user to enter their password for a second time, which then unlocks the account on the Mac itself.
• Once logged in, we configured it so that the Jamf Connect menu bar item was automatically logged in with the Microsoft account, which then kept the local Mac password in sync with the cloud password.

Once we had installed the Jamf Connect software and configuration options, and told staff what to expect on their new login screen, it seemed to work just fine!

Things to watch out for

It wasn’t entirely a plain sailing from this point however. The way Macs are set up at school is that, whilst a particular Mac may only be used by a subset of users, it could potentially be logged into by any member of the staff team. If a user had changed their password since logging into a Mac and then returned to that Mac, the local password would be the old one. When using network accounts, the Mac would happily log in using the new password and then would prompt the user for the old password to update the keychain password. If the user didn’t know their old password, the old keychain would be replaced with a new password.

With Jamf Connect, this scenario gets more complicated. If the user’s account is still a ‘mobile’ account and has not been converted to a ‘standard’ account as part of the initial login with Jamf Connect, the Mac can still talk to Active Directory to at least still let the user into the local account before it is then ‘demobilised’. (Please see Jamf’s documentation for more information about this.) For this reason, it’s important to not unbind the Macs from the Active Directory until you’re sure there are no remaining ‘mobile’ accounts on it. I found some handy ‘extension attribute’ scripts that will tell you which Macs on Jamf Pro still have network accounts on them.

If a user’s account is a normal ‘standard’ account, either because they’ve demobilised an existing network account or have just signed in fresh with Jamf Connect, and they then change their password outside of using the Mac and return to the Mac, there thankfully is a solution to getting back into this account. I found a handy blog post that explains the commands you can use to change the password on a given user account. I turned this into a script that can be run from Self Service, which prompts the user for the username of the account you’re trying to change the password of. You need to actually be logged into a machine to do this, which can be done with a local admin account or something like that. In the script I made it change the password to something that only your tech team can know, preventing any unscrupulous users changing the password of another account and then trying to log in! The next time the user logs in via Jamf Connect, they can then enter the temporary password as the known local account password, which Jamf Connect will then change to the user’s cloud password once they’re logged in.

Below is the script in question:

#!/bin/bash
#Freddie Cox for Knox County Schools
#Edited by Tim Lings
#2021
set -x

sleep 1

userName=`/usr/bin/osascript <<'EOT'
 tell application "System Events"
    activate
    set userName to text returned of (display dialog "Please enter affected username:" default answer "" with icon 2)
end tell
EOT`

#Reset local password
/usr/bin/dscl . -passwd /Users/"$userName" temporarypassword

One last thing we discovered is that some users had figured out that they could click ‘local account’ the login screen and then login with their normal AD credentials, rather than having to put in their cloud Microsoft account. It is possible to set the configuration for the Jamf Connect login window using ‘DenyLocal’ to prevent this happening (with the option to also specify local admin logins that you still want to allow).