At my day job our team manages a lot of laptops, some of which are Macbooks. Since the Macs account for a fairly small share, we never implemented an MDM solution like Jamf, so we largely depend on using scripts to deploy software, and we manually adjust settings. As a mostly Microsoft shop, we use on premise Active Directory, and our Macs use LDAP to bind to the AD domain. Apple’s LDAP implementation is extremely clunky in 2020, and from what I can tell, hasn’t been updated in well over 10 years. After the upgrade to High Sierra in 2017 we even had an issue with LDAP accounts getting completely locked out.

This setup isn’t ideal. Recent versions of macOS struggle to show the “Other users” prompt to enter AD credentials at login screen, and sometimes we have to wait for a few minutes until we can login a new user. We’re also unable to leverage these credentials for 802.1x authentication on wired or wireless networks. And lastly, password sync is incredibly slow as well.

Despite this, it’s still worth it as we often re-deploy laptops and it saves admin time. The Macs are set to allow administration by domain admins, but we also configure a local admin account for backup. Most of our staff doesn’t have local admin access, and with many applications getting updates from the App Store now, this works fairly well. That is — until the user actually needs admin access for something. During normal times, we often provide this in person or over screen share. During COVID times though, it’s all remote.

As we transitioned to WFH, things worked reasonably well for a few months, until we received a ticket about updating some Adobe software, something fairly routine. However, once we remoted in, our local admin password did not work. Nor did the 20 other combinations we tried in case it was initially misspelled. To make things worse, none of the domain admins logged in to this machine previously, so the local admin was the only account with admin access. While there used to be a few ways to recover OSX passwords back in the day, they require physical access to the machine, and file access to the OS drive. Now that macOS uses FileVault disk encryption by default, I don’t think these solutions work anymore. For regular home users, they can use Apple ID to reset the password, but our backup admin wasn’t configured with one.

Now, we wanted to get into this machine without having to wipe it, as reinstalling everything remotely would take a while. Since the machine was bound to our AD domain, our first attempt was to log in with a domain admin account through the terminal. We could log in while connected via VPN, but we were not in the sudoers file, so no admin access was available. A quick Google search suggested that Apple adds LDAP users to sudoers during login process. So the next step was to try to login at the login screen as a domain admin. However, we soon realized that macOS can’t maintain a VPN connection if you return to the login screen, not even if you’re just attempting to switch users. So I had another idea — what if we establish a VPN connection outside the computer, and then bridge it to the Mac? This would be fairly simple on my home network, but way too involved for one of our staff. However, what if we built a small VPN gateway and shipped it to our colleague?

Here’s what the plan was:

• Get a Raspberry Pi and 2 USB ethernet adapters (since new Macbooks don’t have Ethernet any more) + 2 ethernet cables
• Set up an OpenVPN server on premises (our firewall’s vpn client doesn’t support ARM architecture so it won’t work on a Raspberry Pi — learned this the hard way)
• Install Raspbian on Raspberry Pi, install openvpn and isc-dhcp-server
• Use built in Ethernet as WAN. Leave as default (DHCP)
• Configure static IP for USB Ethernet adapter, and enable DHCP server on that adapter
• Configure DHCP server on an obscure subnet so it doesn’t conflict with the user’s home network nor our corporate network
• Configure routing and NAT between “WAN port” (built in ethernet) and “LAN port” (USB Ethernet)
• Configure OpenVPN and set it to auto start
• Configure firewall rules on premises to allow traffic and NAT from user’s home connection

This plan seemed so simple and foolproof, and I quickly tested it using my 2006 black Macbook. This was the critical mistake, as we would soon find out — this laptop did not have FileVault enabled. Everything worked without issues! I connected the “WAN port” to my local network, the “LAN port” from the USB adapter to the Macbook (didn’t even need the second USB adapter since in 2006 Apple still had ethernet on their laptops). Voila, I had the keys to the kingdom. I quickly packed up the whole thing and mailed it to my colleague.

A few days later I am speaking to them over video. They’ve properly connected the RPi to their router and the Macbook. They get the “Other users” prompt. I give them temporary admin credentials to type in. macOS loads. And then they get the SecureToken prompt to unlock FileVault:

This was it. Despite the LDAP config allowing administration to AD domain admins, the latest versions of macOS still require an existing SecureToken admin to create a mobile account and (I assume) add them as an administrator. If the user select “Bypass”, the LDAP user will be created, but it won’t have admin access. We eventually just wiped the machine, since we already wasted a few days trying to make this solution work.

FileVault has (reportedly) been marked as default on Macs since macOS 10.10 (2014), so presumably this solution wouldn’t have worked on most Macs in recent years (if they have FileVault enabled, of course).

This was a disappointing end to what seemed like a fun and quick solution to something that wouldn’t have been a problem back when we all worked in offices together.