Службы Active Directory (AD) позволяют удобно управлять доступами к#nbsp;корпоративным ресурсам. Это здорово, потому что администратору удобно иметь единую точку управления всеми учетными записями и#nbsp;доступами, а#nbsp;пользователям удобно помнить только один пароль. Всё портит один момент: чтобы всё работало, как задумано, все ваши сервисы должны поддерживать интеграцию с#nbsp;AD.
Поэтому совсем не удивительно то, что вопрос о поддержке AD клиенты задают нам довольно часто. Но в рамках управления компьютерами Apple ответ на этот вопрос становится немного не очевидным, потому что есть целых три совершенно отдельных способа интеграции AD как в систему MDM, так и на устройства пользователей.
Первый#nbsp;— использование учетных записей#nbsp;AD для логина в#nbsp;веб-интерфейс MDM-системы.
Третий#nbsp;— использование учетных записей#nbsp;AD для авторизации непосредственно на#nbsp;клиентских устройствах.
Первый вариант покрывает задачи управления администраторами MDM-системы, особенно при наличии поддержки групп и#nbsp;групповых прав. Создаем группы, сопоставляем их#nbsp;с#nbsp;группами AD, назначаем различные права#nbsp;— и#nbsp;вот уже нет никакой необходимости управлять доступом к#nbsp;админке через саму админку.
Второй позволяет дополнить инвентарную информацию о#nbsp;клиентских машинах и#nbsp;начать более удобно ориентироваться в#nbsp;том, каким пользователям выданы какие компьютеры. Также в#nbsp;некоторых MDM-системах можно использовать эти данные для определения зоны действия политик и#nbsp;профилей, если вы#nbsp;вдруг решили при распределении настроек на#nbsp;клиентские устройства отталкиваться не#nbsp;от#nbsp;компьютеров, а#nbsp;от#nbsp;их владельцев.
Для поддержки этих двух опций MDM обычно требует для себя доступ к#nbsp;AD на#nbsp;чтение и#nbsp;проводит либо периодическую синхронизацию данных, либо отправляет запрос прямо в#nbsp;момент обращения к#nbsp;тем полям, данные из#nbsp;которых подтягиваются из#nbsp;службы каталогов.
Третий отличается от#nbsp;предыдущих двух тем, что он#nbsp;выходит за#nbsp;рамки ответственности MDM-систем, но#nbsp;для тех, кто раньше не#nbsp;использовал подобные решения, это не#nbsp;всегда очевидно. Некоторые вендоры MDM-решений разрабатывают свое собственное#nbsp;ПО для использования учеток#nbsp;AD на#nbsp;клиентских устройствах, но#nbsp;это единичные случаи и, если не#nbsp;брать их#nbsp;в#nbsp;расчет, то#nbsp;опции у#nbsp;нас остаются примерно такие:
встроенный в#nbsp;macOS механизм привязки устройства к#nbsp;AD, который называется bind;
Kerberos SSO Extension;
связка NoMAD/NoMAD Login;
Xcreds.
Механизмы bind очень стары и#nbsp;уже давно живут без особых изменений. Они подключают машину к#nbsp;AD, в#nbsp;каталоге появляется запись об#nbsp;устройстве, а#nbsp;на#nbsp;Маке появляется возможность входа с#nbsp;реквизитами учетной записи#nbsp;AD прямо на#nbsp;экране входа в#nbsp;систему. Разные манипуляции с#nbsp;конфигурациями позволяют настроить, какие группы из#nbsp;AD могут входить в#nbsp;систему и#nbsp;кто будет получать права администратора на#nbsp;машинах. Учетные записи, создаваемые при входе в#nbsp;систему, будут мобильными: у#nbsp;них есть определенные ограничения и#nbsp;для некоторых инсталляций они могут быть критичными. В#nbsp;целом это неплохой вариант для стационарных машин, но#nbsp;при использовании для мобильных устройств придется регулярно сталкиваться с#nbsp;разными багами и#nbsp;проблемами с#nbsp;привязкой устройства к#nbsp;AD.
Kerberos SSO Extension – более новое решение и#nbsp;куда более простое. В#nbsp;теории этот механизм дает возможность разным сервисам реализовывать свои механизмы SSO для macOS, но#nbsp;на#nbsp;практике вы#nbsp;столкнетесь только со#nbsp;встроенным плагином для Kerberos (то#nbsp;есть для локальной AD) и#nbsp;сторонним плагином от#nbsp;Microsoft для Azure. В#nbsp;отличие от#nbsp;механизма привязки, расширения для SSO не#nbsp;позволяют прямо с#nbsp;экрана логина вводить реквизиты от#nbsp;AD или Azure, и#nbsp;придется сначала как-то создать локальную учетную запись, и#nbsp;только после входа в#nbsp;нее расширение запустится, позволит залогиниться и#nbsp;попытается синхронизировать пароли локальной и#nbsp;SSO-учетки. И#nbsp;в#nbsp;этом вся суть#nbsp;— это утилита, которая запускается после входа пользователя в#nbsp;систему и#nbsp;после ввода логина и#nbsp;пароля через GUI в#nbsp;строке меню Apple забирает с#nbsp;сервера тикеты/токены, которые использует для доступа к#nbsp;различным сервисам, требующим авторизации. Плюс проверяет совпадение пароля SSO с#nbsp;локальным и#nbsp;при расхождении активирует механизмы синхронизации. Ломаться почти нечему, работает нормально, критичных багов не#nbsp;замечено.
NoMAD когда-то создавался как замена бинду и#nbsp;работает только с#nbsp;локальной службой каталогов. Изначально его работа была очень похожа на#nbsp;работу SSO Extension: после входа пользователя в#nbsp;систему он#nbsp;видел значок в#nbsp;строке меню Apple, который открывал доступ к#nbsp;интерфейсу, через который можно было залогиниться и#nbsp;получить тикеты Kerberos для доступа к#nbsp;корпоративным ресурсам. Через некоторое время NoMAD дополнился отдельным приложением NoMAD Login, которое стало выгодно отличать его от#nbsp;SSO Extension тем, что оно подменяло экран входа в#nbsp;систему и#nbsp;позволяло входить в#nbsp;учетную запись на#nbsp;компьютере с#nbsp;реквизитами#nbsp;AD. Учетные записи при этом создаются не#nbsp;мобильные (менеджмент которых имеет свою специфику), а#nbsp;обычные локальные. В#nbsp;итоге мы#nbsp;имеем что-то, что дает пользовательский опыт сравнимый с#nbsp;привязкой к#nbsp;AD (мы#nbsp;можем просто войти в#nbsp;учетку с#nbsp;реквизитами#nbsp;AD и#nbsp;ни о#nbsp;чем больше не#nbsp;думать), но#nbsp;при этом с#nbsp;простотой реализации SSO Extension. Минус в#nbsp;том, что NoMAD уже не#nbsp;обновляется, но#nbsp;это не#nbsp;мешает ему нормально работать даже на#nbsp;современных системах.
Xcreds по#nbsp;общему впечатлению похож на#nbsp;NoMAD, но#nbsp;на#nbsp;этот раз работает только с#nbsp;облачными IdP. Подробнее прочитать про него можно здесь.
Помимо этих четырех решений есть еще одно, к#nbsp;тому#nbsp;же проприетарное#nbsp;— Platform SSO for macOS, которое было анонсировано достаточно давно и мы ждем, когда оно будет реализовано теми же Microsoft. Самое главное отличие от#nbsp;SSO Extension#nbsp;— это возможность ввода реквизитов на#nbsp;экране входа в#nbsp;систему. Конечно, после релиза мы#nbsp;всё сами проверим на#nbsp;практике и#nbsp;напишем еще одну статью.
И#nbsp;тут самое время снова упомянуть о#nbsp;том, что все эти интеграции, реализуемые на#nbsp;клиентских устройствах, не#nbsp;имеют прямого отношения к#nbsp;MDM и#nbsp;это отдельная вещь, которую нужно выбирать, настраивать и#nbsp;тестировать. MDM, в#nbsp;свою очередь, позволит установить выбранное решение и#nbsp;настроить его на#nbsp;пользовательских устройствах.