To bind or not to bind: как мы управляем identity корпоративных «Маков»

Привет! Меня зовут Павел, и я руководитель офисной IT-инфраструктуры Apple и Linux в Яндексе. Не один год своей работы в той или иной степени я посвятил «Макам» и другим Apple‑устройствам. А в компании их сейчас уже больше 20 тысяч, и управлять таким парком — задача нетривиальная.

Надеюсь, что сегодняшняя тема будет интересна системным администраторам и инженерам поддержки пользователей на платформе macOS. Поговорим об Active Directory и альтернативах этому решению, обсудим, имеет ли смысл вводить компьютеры на macOS в домен и как это всё должно работать.

Ввод «Маков» в домен: какие есть проблемы

Для чего вводить «Маки» в домен? В первую очередь, конечно, чтобы управлять их identity — учётной записью. То есть понимать, кто является пользователем каждого конкретного компьютера. Мы хотим быть уверены, что пароль аккаунта пользователя соответствует парольным политикам компании и другим требованиям безопасности, а также ротируется вовремя и не повторяется. Также мы хотим дать сотрудникам простой и быстрый доступ к сервисам компании через, например, аутентификацию SSO: к решениям для шеринга файлов, совместного редактирования документов, безопасной печати и ко многому другому.

Active Directory

В прошлом интеграция «Маков» с Active Directory в локальной сети не создавала больших проблем. AD как технология была спроектирована для использования на стационарных рабочих станциях при наличии постоянной локальной сети, где всегда были доступны и network‑файловые ресурсы, и контроллер домена, на котором хранились учётные данные пользователя, и даже home‑директория, всегда доступная по сети. И это работало хорошо.

Но технологии и условия работы меняются: сейчас большинство людей работает на ноутбуках, network‑хранилищами пользуются всё реже, и постоянные локальные сети постепенно уходят в прошлое. Корпоративную рабочую среду для сотрудников всё чаще размещают в облачных сервисах, а значит, прежние принципы построения корпоративной инфраструктуры с использованием AD утрачивают актуальность.

Здесь и появляются проблемы: на замену сетевым учётным записям в macOS появились «мобильные», которые хоть и используют для периодической аутентификации пользователя внутренний AD‑контроллер компании, но могут кешировать пароль и позволяют работать удалённо без доступа к локальной корпоративной сети.

Но всё же иногда доступ в локальную сеть с контроллером нужен, и это может провоцировать разные эффекты при работе на macOS в такой конфигурации, например долгий вход в учётную запись или невозможность сделать это без VPN или локальной сети.

В ранних версиях macOS были настройки, дающие возможность повлиять на тайм‑ауты взаимодействия операционной системы с контроллером домена, что в некоторых случаях позволяло сократить частоту негативных эффектов. Однако в актуальных версиях macOS этот способ уже не работает.

Ещё одна потенциальная проблема в конфигурации с биндом к AD — для аутентификации требуется компьютерный аккаунт в AD. У аккаунта есть пароль, который хранится в macOS в System Keychain. С этим паролем могут происходить разные неприятные вещи: например, если вы восстанавливаете систему с помощью time machine, может восстановиться старый пароль, что сломает bind и потенциально приведёт к тому, что пользователь не сможет сменить пароль своей учётной записи.

Смена пароля на мобильных аккаунтах

На мобильных аккаунтах также могут возникать проблемы со сменой пароля, если пользователь его забыл. Для них в macOS действует ограничение: его нельзя сбросить на самом компьютере. И если мы меняем пароль такой учётной записи каким‑то нестандартным способом, возникает масса проблем.

Чтобы разобраться, почему и как это происходит, давайте посмотрим, как работает мобильный аккаунт на macOS.

В macOS существует несколько сущностей на уровне безопасности системы, зашифрованных паролем учётной записи пользователя: keychain, secure token и FileVault 2. Когда пользователь с мобильной учётной записью меняет пароль стандартным путём через настройки System Preferences, то сперва macOS пытается поменять пароль в AD для доменной учётной записи. AD, в свою очередь, проверяет новый пароль на соответствие всем политикам, и только после смены пароля в AD macOS при успехе заменяет пароль, которым зашифрованы все ранее упомянутые сущности. В этом случае всё продолжает работать штатно.

Проблемы начинаются, когда пользователь забыл пароль. Конечно, тогда мы можем изменить или сбросить пароль в AD, но все важные сущности в macOS, зашифрованные старым паролем, таким путём пароль не обновят. В итоге secure token и keychain теряются практически в любом случае, что на современных macOS означает поломку критичных для безопасности macOS подсистем.

Чтобы исправить проблему, нужно либо иметь запасной локальный аккаунт, либо заботиться о том, чтобы bootstrap token был заблаговременно депонирован в ваше MDM‑решение. Процесс починки трудоёмкий и часто при отсутствии ключевых условий невозможен, и всё заканчивается затиркой техники и перезаливкой с нуля. В общем, ситуация непростая.

Сложность удалённой наливки

Отдельная задача — удалённая подготовка «Маков», которые необходимо биндить к AD. Если их нужно ввести в AD, сначала нужно создать пользователю «на том конце» временный локальный аккаунт, под которым настраивается временный VPN‑туннель с временным секретом и доступом к AD. Это делается, чтобы завести компьютер в AD и только после этого создать на нём мобильную учётную запись. При этом важно соблюдать ряд условий, чтобы все важные сущности, относящиеся к подсистемам безопасности, остались в «хорошем» состоянии на мобильной учётной записи и работали штатно. Процесс получается сложный, ненадёжный и долгий.

Есть ли альтернативы?

Некоторые компании используют обычные локальные аккаунты на macOS и ведут реестр соответствия «компьютер — пользователь». Можно использовать Cloud IdP (Identity Provider): Okta или подобные — с помощью инструмента наподобие Jamf Connect или NoMAD Login. Но в использовании облачных IdP есть свои риски. А что касается Яндекса, то у нас довольно сложно устроена внутренняя SSO, из‑за чего подобные решения нам неудобны.

Kerberos SSO спешит на помощь

Kerberos SSO Extension — это технология от самих Apple, которая позволяет реализовать современный вариант интеграции macOS с AD. Используя локальные учётные записи и работая непосредственно с Kerberos‑тикетами пользовательского уровня, это расширение синхронизирует пароль от учётной записи в AD с паролем локальной учётной записи на macOS. Это позволяет одновременно менять пароли во всех сущностях.

Другой важный момент — отсутствие AD bind. Если старый пароль забыт, его можно сбросить штатной процедурой как на стороне AD, так и на macOS, поскольку в этой конфигурации может использоваться локальная учётная запись. В этом случае macOS меняет пароль на всех связанных сущностях на новый, и мы избегаем тех самых страшных проблем.

Kerberos SSO появился в версии macOS Catalina (10.15) и на тот момент выглядел немного страшненько: дизайн диалоговых окон для пользователя был технически пугающим, а кастомизировать его было нельзя. В Ventura, на наш взгляд, решение доработали, и теперь оно выглядит приятно.

Kerberos SSO настраивается только профилем из MDM, и его нельзя установить локально. То есть наличие MDM — это обязательное требование для использования Kerberos SSO. Сетевое подключение к AD потребуется, но теперь только в моменты изначальной настройки и синхронизации пароля пользователя.

Как выглядит конфигурационный профиль Kerberos SSO

Значение PayloadType — com.apple.extensiblesso, которое используется для всех SSO. Из интересного — есть ключ ExtensionIdentifier, где мы уточняем, что используется именно Kerberos SSO. Дальше — поля, которые всегда выглядят одинаково: Apple и Credential, хотя в Type может быть URL, если мы используем другой тип SSO.

Realm в верхнем регистре — это название AD‑домена. В Hosts — собственно, домены и маски доменов, где должна использоваться аутентификация через Kerberos SSO. Обратите внимание на странную нотацию: в качестве wildcard — точка, а не звёздочка, как обычно бывает в других случаях. Это нужно запомнить.

Дальше мы видим ключ ExtensionData, внутри которого — словарь (dictionary) с настройками плагина. Важная настройка — syncLocalPassword, которая говорит, что мы хотим пропагейтить пароль из AD в локальный аккаунт. И ещё больше полезных ключей, с помощью которых мы можем указать, что уважаем комплексити паролей AD, задать минимальную длину и многое другое:

• pwReqComplexity (true/false),

• pwReqLength,

• pwNotificationDays,

• customUsernameLabel,

• helpText,

• DelayUserSetup (true/false).

К тому же мы можем кастомизировать и сделать дружелюбнее пользовательский интерфейс. Например, добавить текст внизу: «Привет! Если у тебя ничего не получилось, обращайся в ServiceDesk».

We need to go deeper…

У Kerberos SSO есть CLI — интерфейс командной строки, которым удобно пользоваться при создании автоматизаций. CLI можно вызвать любым методом, который вам нравится: из launch‑агента, политики MDM, установочного пакета — как угодно. Но не будем забывать, что Kerberos SSO работает в контексте пользователя, поэтому вам придётся пойти на хитрость и притвориться пользователем через launch, если вы вызываете CLI через MDM.

С помощью CLI мы можем узнать информацию о текущем залогиненном пользователе: когда у него истекает пароль, кто он такой, залогинен ли через командную строку и т. д. Получаем мы эти данные с помощью команды app‑sso ‑i REALM. Также можно инициировать логин пользователя, указав его логин: app‑sso ‑a REALM ‑u user_login ‑R ‑q.

А можно зарыться ещё глубже и посмотреть, когда пользователь в последний раз синхронизировал пароль. Это поле остаётся пустым до первого синка, и его бывает полезно учитывать при создании автоматизаций. Скажем, во время онбординга мы не хотим пускать пользователя в систему до того, как он в первый раз синхронизовал пароль, и настраиваем такую автоматизацию.

Кстати, в конце статьи будет ссылка на репозиторий, где можно посмотреть и забрать себе готовые настройки для этого и многих других интересных сценариев.

Как происходит смена пароля 

Удобно и просто: в menu bar macOS появляется новая иконка (menu extra), где мы видим текущий статус залогона в Kerberos SSO и выпадающее меню с опцией «правильной» смены пароля — через AD и сразу на локальной учётной записи.

Если мы не хотим, чтобы пользователь имел возможность сменить пароль стандартным путём (только на локальной учётной записи), можно воспользоваться конфигурационным профилем и ключом настроек dontAllowPasswordResetUI в категории com.apple.preference.security. Этот ключ отвечает за возможность использования стандартного способа смены пароля через «Системные настройки» (System Preferences), но при этом не влияет на работу Kerberos SSO Extension.

А что происходит, если пароль всё‑таки сменили со стороны AD? Kerberos SSO, будучи один раз настроенным, периодически сверяет даты изменения пароля у локальной учётной записи с датой изменения у учётной записи в AD. А если обнаруживается несовпадение, инициирует окошко для пользователя, в котором ему предлагается заново синхронизировать свой пароль с паролем учётной записи в AD. Эта процедура обновит пароль на всех зависящих сущностях, о которых мы говорили ранее.

Если старый пароль пользователю неизвестен, сбросить его на локальной учётной записи можно с помощью macOS Recovery. Попасть туда можно, используя Personal Recovery Key от системы шифрования FileVault 2. Такой способ сохранит работающим secure token и сразу поменяет пароль шифрования на новый. К сожалению, пользовательский keychain это не сохранит, но, по крайней мере, сохранит в рабочем состоянии все подсистемы и сущности, отвечающие за безопасность macOS, и подготавливать «Мак» заново с нуля не потребуется. После первого входа после сброса Kerberos SSO потребует у пользователя синхронизировать свой пароль с паролем от учётной записи в AD.

Удалённая подготовка становится проще

Используя Kerberos SSO вместо AD bind, можно значительно сократить сложность удалённой подготовки «Маков». Настраивать можно первый локальный аккаунт, созданный пользователем в качестве рабочего. У него, в свою очередь, уже есть все необходимые сущности в хорошем состоянии, благодаря чему весь процесс значительно сокращается по времени и сложности. Наши операторы, которые занимаются удалённой подготовкой, были страшно рады новой конфигурации с Kerberos SSO.

Distributed Notifications и для чего они нужны

После настройки Kerberos SSO на учётной записи сотрудника нам интересно контролировать, что пользователь залогинен в эту самую SSO. В macOS есть внутренний механизм для разработчиков, который называется Distributed Notifications. Он позволяет приложениям или компонентам macOS (distributors) распространять в системе некие сообщения, в то время как другие приложения и компоненты (consumers) могут получать их и реагировать.

Этот же механизм встроен и в Kerberos SSO, что позволяет получать от него сигналы в нужные моменты и обрабатывать их удобным способом. В документации Apple есть пример скрипта для чтения уведомлений, но есть вариант гораздо проще, чем писать всё самостоятельно.

Явление Bugle

Bugle — это опенсорс‑инструмент, который умеет работать с нотификациями и запускать настраиваемые действия на их получение. Он сделан для работы с Kerberos SSO и уже знает о нотификациях, которые можно от него получить. Среди них есть такие как «появилась внутренняя сеть», «обновился TGT», «изменился пароль» — типов событий много, посмотреть их можно в документации.

У Bugle есть конфигурационный файл в формате plist с настройками, где можно указать, на какую нотификацию как реагировать. В нашем случае — какой скрипт запустить.

Например, в качестве реакции на событие «появилась внутренняя сеть» мы можем проверить, залогинен ли пользователь в SSO, и инициировать окошко с просьбой залогиниться, если нет.

Настраивается Bugle очень просто: у него есть CLI, также можно редактировать его конфигурационный plist вручную напрямую.

Ключ — название плагина и ивент в Distributed Notifications, а строка — скрипт, который мы запускаем. Запускать можно как вручную, так и launch‑агентом Bugle с просьбой послушать и сделать то, что написано в настройках, выполнить наш скрипт. Очень удобно!

Таким образом, с Distributed Notifications и Bugle мы получаем надёжный механизм, который мотивирует пользователя быть залогиненым в Kerberos SSO, и при этом его пароль всегда будет соответствовать паролю учётной записи в AD.

Конвертация аккаунтов

Последняя тема, важная в контексте «Маков» и Active Directory — конвертация аккаунтов. Допустим, вы твёрдо решили переехать с bind в AD на Kerberos. Что делать дальше?

Самый радикальный способ — переналить компьютер, но есть и другие опции. Можно попробовать конвертировать мобильные аккаунты в локальные. На самом деле мобильный аккаунт — это почти то же самое, что и локальный, но с набором дополнительных атрибутов. По сути, чтобы конвертироваться, нужно просто удалить эти атрибуты, разорвать bind с AD и перезапустить opendirectoryd.

Известный в узких кругах админ Рич Траутон, автор блога Der Flounder, написал скрипт, который конвертирует мобильные аккаунты в локальные. Вот что он делает:

• отвязывает «Мак» от Active Directory,

• удаляет признаки мобильной учётной записи, превращая её в локальную,

• выполняет это быстро, удобно и (почти) небольно,

• в оригинальном исполнении требует взаимодействия с пользователем, но это поправимо.

Скрипт можно использовать по‑разному: адаптировать к своей системе и конвертировать аккаунты массово или немассово. Лучше, конечно, делать это постепенно и аккуратно.

А чтобы облегчить жизнь пользователю, можно добавить немного UI. Для этого идём в магазин приложений, например в тот же Self Service, берём IBM Notifications или другой нотификатор. Делаем красивое окошко, где пользователь сам нажимает кнопку в удобное ему время (например, когда у него есть возможность обратиться в ServiceDesk) и конвертирует аккаунт.

---

Итак, что мы получили после всех описанных в статье манипуляций?

• Сотрудники радуются, что логин происходит быстрее. А ещё можно гораздо проще и быстрее сбросить забытый пароль и восстановить работоспособность системы.

• Специалисты ServiceDesk радуются тому, что у них получается быстрее подготавливать новые компьютеры удалённо и гораздо проще чинятся инциденты с забытыми паролями.

• Служба безопасности радуется тому, что на всех учётных записях работают нужные парольные политики и пароли ротируются.

Разве не здорово?

Если у вас появились какие‑то вопросы по теме, буду рад ответить на них в комментариях! А вот и обещанная ссылка на репозиторий со скриптами, профилями и ссылками для тех, кто захочет воспользоваться нашими наработками и идеями Рича Траутона в своей работе.