Виды интеграции с AD

Службы Active Directory (AD) позволяют удобно управлять доступами к корпоративным ресурсам. Это здорово, потому что администратору удобно иметь единую точку управления всеми учетными записями и доступами, а пользователям удобно помнить только один пароль. Всё портит один момент: чтобы всё работало, как задумано, все ваши сервисы должны поддерживать интеграцию с AD.

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

Первый — использование учетных записей AD для логина в веб-интерфейс MDM-системы.

Второй — связывание клиентских устройств с учетными записями AD в веб-интерфейсе MDM-системы.

Третий — использование учетных записей AD для авторизации непосредственно на клиентских устройствах.

Первый вариант покрывает задачи управления администраторами MDM-системы, особенно при наличии поддержки групп и групповых прав. Создаем группы, сопоставляем их с группами AD, назначаем различные права — и вот уже нет никакой необходимости управлять доступом к админке через саму админку.

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

Для поддержки этих двух опций MDM обычно требует для себя доступ к AD на чтение и проводит либо периодическую синхронизацию данных, либо отправляет запрос прямо в момент обращения к тем полям, данные из которых подтягиваются из службы каталогов.

Третий отличается от предыдущих двух тем, что он выходит за рамки ответственности MDM-систем, но для тех, кто раньше не использовал подобные решения, это не всегда очевидно. Некоторые вендоры MDM-решений разрабатывают свое собственное ПО для использования учеток AD на клиентских устройствах, но это единичные случаи и, если не брать их в расчет, то опции у нас остаются примерно такие:

Механизмы bind очень стары и уже давно живут без особых изменений. Они подключают машину к AD, в каталоге появляется запись об устройстве, а на Маке появляется возможность входа с реквизитами учетной записи AD прямо на экране входа в систему. Разные манипуляции с конфигурациями позволяют настроить, какие группы из AD могут входить в систему и кто будет получать права администратора на машинах. Учетные записи, создаваемые при входе в систему, будут мобильными: у них есть определенные ограничения и для некоторых инсталляций они могут быть критичными. В целом это неплохой вариант для стационарных машин, но при использовании для мобильных устройств придется регулярно сталкиваться с разными багами и проблемами с привязкой устройства к AD.

Kerberos SSO Extension – более новое решение и куда более простое. В теории этот механизм дает возможность разным сервисам реализовывать свои механизмы SSO для macOS, но на практике вы столкнетесь только со встроенным плагином для Kerberos (то есть для локальной AD) и сторонним плагином от Microsoft для Azure. В отличие от механизма привязки, расширения для SSO не позволяют прямо с экрана логина вводить реквизиты от AD или Azure, и придется сначала как-то создать локальную учетную запись, и только после входа в нее расширение запустится, позволит залогиниться и попытается синхронизировать пароли локальной и SSO-учетки. И в этом вся суть — это утилита, которая запускается после входа пользователя в систему и после ввода логина и пароля через GUI в строке меню Apple забирает с сервера тикеты/токены, которые использует для доступа к различным сервисам, требующим авторизации. Плюс проверяет совпадение пароля SSO с локальным и при расхождении активирует механизмы синхронизации. Ломаться почти нечему, работает нормально, критичных багов не замечено.

NoMAD когда-то создавался как замена бинду и работает только с локальной службой каталогов. Изначально его работа была очень похожа на работу SSO Extension: после входа пользователя в систему он видел значок в строке меню Apple, который открывал доступ к интерфейсу, через который можно было залогиниться и получить тикеты Kerberos для доступа к корпоративным ресурсам. Через некоторое время NoMAD дополнился отдельным приложением NoMAD Login, которое стало выгодно отличать его от SSO Extension тем, что оно подменяло экран входа в систему и позволяло входить в учетную запись на компьютере с реквизитами AD. Учетные записи при этом создаются не мобильные (менеджмент которых имеет свою специфику), а обычные локальные. В итоге мы имеем что-то, что дает пользовательский опыт сравнимый с привязкой к AD (мы можем просто войти в учетку с реквизитами AD и ни о чем больше не думать), но при этом с простотой реализации SSO Extension. Минус в том, что NoMAD уже не обновляется, но это не мешает ему нормально работать даже на современных системах.

Xcreds по общему впечатлению похож на NoMAD, но на этот раз работает только с облачными IdP. Подробнее прочитать про него можно здесь.

Помимо этих четырех решений есть еще одно, к тому же проприетарное — Platform SSO for macOS, которое было анонсировано достаточно давно и мы ждем, когда оно будет реализовано теми же Microsoft. Самое главное отличие от SSO Extension — это возможность ввода реквизитов на экране входа в систему. Конечно, после релиза мы всё сами проверим на практике и напишем еще одну статью.

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