Binding to Active Directory: Consider the Alternatives

Not too long ago, binding Mac computers to Active Directory (or other directory services) was standard practice in Apple device management. At the time, keeping domain and certificate services onsite was the only option, and binding was just a part of that system. 

We hear from many admins who are still doing it to this day. If you’re one of them, if perhaps you’ve been told by higher-ups that your organization is committed to binding, we would politely ask you (or those higher-ups), why? 

We would also encourage you to consider a more modern approach. These days there are few compelling reasons to bind Mac computers to Active Directory (or other directory services). The practice no longer serves the purpose it once did, and there are plenty of better alternatives.

What Is Binding?

Just so we’re on the same page at the outset: Binding means connecting a device—in this case, a Mac computer—to a central directory service such as Microsoft Active Directory. (Active Directory has been the most common, but there have certainly been others, including Apple’s own Open Directory.) Such services can store user credentials, which can then be used to authenticate users and their devices for access to network resources. Computers can have their own directory accounts as well, created when they are bound for the first time.

The idea behind binding was that you set up a persistent connection to a directory service, so users wouldn’t have to keep submitting their credentials every time they needed access to a resource. Those resources knew the user was okay because they were authorized by the directory services. Directory services also allowed IT teams to apply domain password policies and settings from a central console. 

Binding the Mac to Active Directory was especially popular in Windows-centric environments. It allowed IT to see those Mac computers in the same window as all those Windows devices. 

The big advantage of binding for users was that it allowed them to have a consistent username and password on any device and when accessing any network resource. This was a big deal back in the day when, if you normally used Computer A but then wanted to log in to Computer B, you’d have to set up a new username and password on that new device. 

With an on-premises directory such as Active Directory storing credentials centrally, a user could use them on any device or to access any service on the network. Microsoft was the real driver in extending directory services beyond device logins. Active Directory, for example, allowed you to use the same username and password to access email, a Wi-Fi access point, or an intranet site as you used to log into your computer.

The Problem with Binding 

Binding was once an effective way to solve the real-world problems that organizations were facing. Users wanted a single set of credentials, binding supplied it, and that made life easier for IT. But as time went on, binding became less useful and even began to introduce some new challenges.

For starters, the moment you introduce laptops, which leave the office and lose their persistent connections to an on-premises directory service, binding is no longer an efficient solution. All kinds of problems crop up when a user is detached from the directory service.

Let’s say a user is working remotely, they forget their password, and then a password change takes place while the device is not actively connected to Active Directory. It’s all too easy to get into a situation where they can't log in at all due to the FileVault and user passwords going out of sync.

Binding made sense when every device was a computer and all those computers were inside the firewall. But with the rise of the cloud, data and services—even Exchange—moved outside that wall. The model went from on-prem to cloud software as a service (SaaS). 

Then came the pandemic and the swift shift to remote work. Suddenly everyone—not just the travelers or the occasional work-from-homers—was outside the wall. Bound devices must be in constant communication with the directory. With so many people connecting remotely, that introduces security risks: Do you really want to expose your Active Directory to the outside, even across a VPN?

Also, Active Directory in particular has had limitations when it came to Apple devices. For one thing, there’s no way to bind an iPhone or an iPad to Active Directory—a pretty big blocker as those devices became more common in the workplace. For another, there’s only so much you can do in Active Directory to manage Apple devices generally.

Of course, clever admins developed ways of working around those limitations—for example, setting up a ”magic triangle” (a.k.a. a “golden triangle”) in which you get policies from a Mac directory and authentication from a Windows directory, or extending Active Directory schema so you could leverage Apple tools such as Workgroup Manager to store policy information within Active Directory. Such workarounds were particularly useful for configuring an Apple user to have a home folder served from the organization’s Windows infrastructure. 

But even just including Mac computers in Active Directory has required some convoluted workflows, including scripts to rename computers to fit Active Directory’s formulae.

Again, clever Apple people came up with some clever solutions, such as Enterprise Connect, which allowed you to get many of the benefits of Active Directory binding, including password syncing and Kerberos-based authentication, without binding the Mac. Enterprise Connect was subsequently replaced by Apple’s Kerberos-friendly Single Sign-On extension. Third-party solutions such as NoMAD were also developed to deliver the benefits of Active Directory without needing to bind.

Alternatives to Binding

But the real reason to give up binding is that there are so many alternatives available now—alternatives that fit much more comfortably in today’s cloud-centric, remote-friendly environment. Those alternatives include:

• MDM solutions (such as Kandji) have taken on many of the configuration chores that Active Directory handled. And many of them (including Kandji) are built specifically for Apple devices.
• Cloud-based identity providers (including Azure Active Directory) take care of managing user accounts and authentication. Such IdPs can also make multifactor authentication work. (Note that Kandji Passport can sync IdP passwords to devices.)
• Other cloud-based services, such as Microsoft 365 or Google Workspace, make applications that were formerly housed on the network—including email, calendar, and document collaboration—available from anywhere with an internet connection.
• If you’ve ever worked with iPhone or iPad devices in a corporate setting, you know you can use certificates to manage their access to organization resources such as Wi-Fi. Obviously, you can also use certificates—instead of binding—to help Mac computers authenticate. You can push certificates out to Mac computers using MDM and configure things like Wi-Fi access points to trust those certificates. If you still use on-premises Active Directory Certificate Services (AD CS) you can use an MDM solution like Kandji, which offers an AD CS Connector to facilitate creating and distributing certificates without binding.
• Single sign-on services are the modern, cloud-based alternative to binding and mobile accounts. Leveraging standards such as OAuth and OpenID, they obviate the need to check with an IdP for each unlock attempt. Rather, the identity provider is called only when a user attempts to use a new password at unlock.

Switching from Binding

Lest you think we’re being glib in suggesting that you switch away from binding, we understand: Sometimes, in some corner cases, binding still makes sense. Perhaps your users need to navigate a complex Distributed File System (DFS) namespace. In some government environments, users aren’t given Active Directory passwords, in order to prevent social engineering attacks; in such cases, IT teams rely on Active Directory–based smart card workflows for authentication. 

Even without such hard requirements, we know that switching away from Active Directory can be a hard pill for many organizations to swallow. It’s been the Way Things Are Done for a long, long time. Higher-ups on the executive or security teams may be reluctant to fix what isn’t (yet) completely broken. As an admin or IT manager, you’ve no doubt got enough on your plate already without adding a migration away from Active Directory to your load.

But we’d argue that it’s better to make that shift now, while you can control it, than later, when you might not be able to. It’s possible that a future iteration of macOS will make Active Directory even harder—if not impossible—to work with.

It’s also possible to make the transition gradually. You can consider a hybrid approach—binding Mac computers solely to get a certificate to get on Wi-Fi, then using some kind of third-party solution to manage login credentials. 

That stopgap would give you time to start the persuasion process. The message we’d urge you to convey to those who resist the switch away from Active Directory: You don't want stuff to break. If you want to future-proof your organization, binding is definitely a thing of the past. You don’t want to have to scramble when something snaps. You want to be in control of your environment. And that means making a measured, well-planned migration away from Active Directory.

About Kandji

Kandji is the Apple device management and security platform that empowers secure and productive global work. With Kandji, Apple devices transform themselves into enterprise-ready endpoints, with all the right apps, settings, and security systems in place. Through advanced automation and thoughtful experiences, we’re bringing much-needed harmony to the way IT, InfoSec, and Apple device users work today and tomorrow.