To bind or not to bind: how we manage the identity of corporate "Macs"

I hope today's topic will be interesting to system administrators and user support engineers on the macOS platform. We will talk about Active Directory and alternatives to this solution, discuss whether it makes sense to introduce macOS computers into the domain and how it should all work.

Introducing Macs into the domain: what are the problems

Why introduce Macs into the domain? First of all, of course, to manage their identity - the account. That is, to understand who is the user of each specific computer. We want to be sure that the user's account password complies with the company's password policies and other security requirements, is rotated on time, and does not repeat. We also want to give employees simple and quick access to company services through, for example, SSO authentication: to solutions for file sharing, collaborative document editing, secure printing, and much more.

Active Directory

In the past, integrating Macs with Active Directory on a local network did not create major problems. AD as a technology was designed for use on stationary workstations with a constant local network, where both network file resources and the domain controller, which stored the user's credentials, and even the home directory, always available over the network, were always available. And it worked well.

But technologies and working conditions are changing: now most people work on laptops, use network storage less and less, and constant local networks are gradually becoming a thing of the past. The corporate working environment for employees is increasingly being placed in cloud services, which means that the old principles of building corporate infrastructure using AD are losing relevance.

This is where problems arise: instead of network accounts in macOS, "mobile" accounts have appeared, which, although they use the company's internal AD controller for periodic user authentication, can cache the password and allow remote work without access to the local corporate network.

However, sometimes access to the local network with the controller is still needed, and this can provoke various effects when working on macOS in such a configuration, for example, a long login to the account or the inability to do this without a VPN or local network.

In earlier versions of macOS, there were settings that allowed you to influence the timeouts of the operating system's interaction with the domain controller, which in some cases made it possible to reduce the frequency of negative effects. However, in the current versions of macOS, this method no longer works.

Another potential problem with the AD bind configuration is that a computer account in AD is required for authentication. The account has a password that is stored in macOS in the System Keychain. Various unpleasant things can happen with this password: for example, if you restore the system using time machine, the old password may be restored, which will break the bind and potentially lead to the user being unable to change the password of their account.

Password change on mobile accounts

Mobile accounts may also have problems changing the password if the user has forgotten it. For them, macOS has a restriction: it cannot be reset on the computer itself. And if we change the password of such an account in some non-standard way, a lot of problems arise.

To understand why and how this happens, let's see how the mobile account works on macOS.

In macOS, there are several entities at the system security level encrypted with the user's account password: keychain, secure token, and FileVault 2. When a user with a mobile account changes the password in the standard way through System Preferences, macOS first tries to change the password in AD for the domain account. AD, in turn, checks the new password for compliance with all policies, and only after changing the password in AD, macOS successfully replaces the password that encrypts all the previously mentioned entities. In this case, everything continues to work as expected.

Problems start when the user forgets the password. Of course, we can change or reset the password in AD, but all important entities in macOS encrypted with the old password will not update the password this way. As a result, secure token and keychain are lost in almost all cases, which in modern macOS means the breakdown of critical macOS security subsystems.

To fix the problem, you need either a spare local account or to ensure that the bootstrap token is pre-deposited in your MDM solution. The repair process is laborious and often impossible without key conditions, and it all ends with wiping the device and reinstalling from scratch. In general, the situation is difficult.

Complexity of remote setup

A separate task is the remote preparation of "Macs" that need to be bound to AD. If they need to be added to AD, you first need to create a temporary local account for the user "on the other end," under which a temporary VPN tunnel with a temporary secret and access to AD is set up. This is done to add the computer to AD and only then create a mobile account on it. It is important to follow a number of conditions to ensure that all important entities related to security subsystems remain in "good" condition on the mobile account and work as expected. The process is complex, unreliable, and lengthy.

Are there alternatives?

Some companies use regular local accounts on macOS and maintain a registry of "computer-user" compliance. You can use Cloud IdP (Identity Provider): Okta or similar — with a tool like Jamf Connect or NoMAD Login. But there are risks in using cloud IdPs. As for Yandex, we have a rather complex internal SSO, which makes such solutions inconvenient for us.

Kerberos SSO to the rescue

Kerberos SSO Extension is a technology from Apple itself that allows you to implement a modern version of macOS integration with AD. Using local accounts and working directly with user-level Kerberos tickets, this extension synchronizes the AD account password with the local account password on macOS. This allows you to change passwords in all entities at the same time.

Another important point is the absence of AD bind. If the old password is forgotten, it can be reset by the standard procedure both on the AD side and on macOS, since a local account can be used in this configuration. In this case, macOS changes the password on all related entities to the new one, and we avoid those very scary problems.

Kerberos SSO appeared in macOS Catalina (10.15) and at that time looked a bit scary: the design of the dialog boxes for the user was technically intimidating, and it could not be customized. In Ventura, in our opinion, the solution has been improved, and now it looks nice.

Kerberos SSO is configured only by an MDM profile, and it cannot be installed locally. That is, having an MDM is a mandatory requirement for using Kerberos SSO. Network connection to AD will be required, but now only at the moments of initial setup and user password synchronization.

What the Kerberos SSO configuration profile looks like

The PayloadType value is com.apple.extensiblesso, which is used for all SSO. Interestingly, there is an ExtensionIdentifier key where we specify that Kerberos SSO is used. Next are the fields that always look the same: Apple and Credential, although the Type can be URL if we use another type of SSO.

Realm in uppercase is the name of the AD domain. In Hosts, these are the domains and domain masks where Kerberos SSO authentication should be used. Note the strange notation: a dot is used as a wildcard, not an asterisk, as is usually the case in other cases. This needs to be remembered.

Next, we see the ExtensionData key, inside which is a dictionary with plugin settings. An important setting is syncLocalPassword, which says that we want to propagate the password from AD to the local account. And even more useful keys with which we can specify that we respect AD password complexity, set the minimum length, and much more:

• pwReqComplexity (true/false),

• pwReqLength,

• pwNotificationDays,

• customUsernameLabel,

• helpText,

• DelayUserSetup (true/false).

In addition, we can customize and make the user interface more user-friendly. For example, add text at the bottom: "Hello! If you didn't succeed, contact ServiceDesk".

We need to go deeper…

Kerberos SSO has a CLI — a command line interface that is convenient to use when creating automations. The CLI can be called by any method you like: from a launch agent, MDM policy, installation package — however you like. But let's not forget that Kerberos SSO works in the context of the user, so you will have to be tricky and pretend to be a user through launch if you call the CLI through MDM.

With the CLI, we can get information about the current logged-in user: when their password expires, who they are, whether they are logged in through the command line, etc. We get this data using the command app‑sso ‑i REALM. You can also initiate user login by specifying their login:app‑sso ‑a REALM ‑u user_login ‑R ‑q.

And you can dig even deeper and see when the user last synchronized the password. This field remains empty until the first sync, and it can be useful to consider when creating automations. For example, during onboarding, we do not want to let the user into the system until they have synchronized the password for the first time, and we set up such automation.

By the way, at the end of the article there will be a link to the repository where you can view and take ready-made settings for this and many other interesting scenarios.

How to change the password

Convenient and simple: a new icon (menu extra) appears in the macOS menu bar, where we see the current status of the login to Kerberos SSO and a drop-down menu with the option to "properly" change the password - through AD and immediately on the local account.

If we do not want the user to be able to change the password in the standard way (only on the local account), you can use a configuration profile and the dontAllowPasswordResetUI settings key in the com.apple.preference.security category. This key is responsible for the ability to use the standard way to change the password through "System Preferences", but does not affect the operation of the Kerberos SSO Extension.

What happens if the password is still changed from the AD side? Kerberos SSO, once configured, periodically compares the password change dates of the local account with the change date of the AD account. And if a mismatch is detected, it initiates a window for the user in which they are prompted to re-synchronize their password with the AD account password. This procedure will update the password on all dependent entities we talked about earlier.

If the old password is unknown to the user, it can be reset on the local account using macOS Recovery. You can get there using the Personal Recovery Key from the FileVault 2 encryption system. This method will keep the secure token working and immediately change the encryption password to a new one. Unfortunately, the user keychain will not save this, but at least it will keep all the subsystems and entities responsible for macOS security working, and you will not need to prepare the "Mac" from scratch again. After the first login after the reset, Kerberos SSO will prompt the user to synchronize their password with the AD account password.

Remote preparation becomes easier

Using Kerberos SSO instead of AD bind can significantly reduce the complexity of remote preparation of "Macs". You can configure the first local account created by the user as a working one. It already has all the necessary entities in good condition, which significantly reduces the time and complexity of the entire process. Our operators, who are engaged in remote preparation, were very pleased with the new configuration with Kerberos SSO.

Distributed Notifications and what they are for

After setting up Kerberos SSO on an employee's account, we are interested in controlling that the user is logged into this very SSO. macOS has an internal mechanism for developers called Distributed Notifications. It allows applications or macOS components (distributors) to distribute certain messages in the system, while other applications and components (consumers) can receive and respond to them.

This same mechanism is built into Kerberos SSO, which allows you to receive signals from it at the right moments and process them in a convenient way. In the Apple documentation there is an example script for reading notifications, but there is a much simpler option than writing everything yourself.

The Bugle Phenomenon

Bugle is an open-source tool that can work with notifications and launch customizable actions upon receiving them. It is designed to work with Kerberos SSO and already knows about the notifications that can be received from it. Among them are such as "internal network appeared", "TGT updated", "password changed" — there are many types of events, you can see them in the documentation.

Bugle has a configuration file in plist format with settings where you can specify how to respond to a notification. In our case, which script to run.

For example, in response to the event "internal network appeared", we can check if the user is logged into SSO and initiate a window asking to log in if not.

Setting up Bugle is very simple: it has a CLI, and you can also edit its configuration plist manually directly.

The key is the name of the plugin and the event in Distributed Notifications, and the string is the script that we run. You can run it manually or with the Bugle launch agent asking to listen and do what is written in the settings, execute our script. Very convenient!

Thus, with Distributed Notifications and Bugle, we get a reliable mechanism that motivates the user to be logged in to Kerberos SSO, and at the same time, their password will always match the account password in AD.

Account Conversion

The last topic, important in the context of "Macs" and Active Directory, is account conversion. Suppose you are determined to move from bind in AD to Kerberos. What to do next?

The most radical way is to reinstall the computer, but there are other options. You can try to convert mobile accounts to local ones. In fact, a mobile account is almost the same as a local one, but with a set of additional attributes. Essentially, to convert, you just need to remove these attributes, break the bind with AD, and restart opendirectoryd.

A well-known admin in narrow circles, Rich Trouton, author of the blog Der Flounder, wrote a script that converts mobile accounts to local ones. Here's what it does:

• unbinds the "Mac" from Active Directory,

• removes signs of the mobile account, turning it into a local one,

• does it quickly, conveniently, and (almost) painlessly,

• in the original version, requires user interaction, but this is fixable.

The script can be used in different ways: adapt it to your system and convert accounts en masse or not. It is better, of course, to do this gradually and carefully.

And to make life easier for the user, you can add a little UI. To do this, go to the app store, for example, the same Self Service, take IBM Notifications or another notifier. Make a beautiful window where the user presses the button at a convenient time (for example, when they can contact the ServiceDesk) and converts the account.

So, what did we get after all the manipulations described in the article?

• Employees are happy that the login process is faster. It is also much easier and faster to reset a forgotten password and restore system functionality.

• ServiceDesk specialists are happy that they can prepare new computers remotely faster and incidents with forgotten passwords are much easier to fix.

• The security service is happy that the necessary password policies are in place on all accounts and passwords are rotated.

Isn't it great?

If you have any questions on the topic, I will be happy to answer them in the comments! And here is the promised link to the repository with scripts, profiles, and links for those who want to use our developments and Rich Troughton's ideas in their work.