ЕВГЕНИЙ СИНЕЛЬНИКОВ, директор обособленного подразделения, г. Саратов, «Базальт СПО»

Реализация групповых политик
Active Directory в Linux-клиентах

Групповые политики – это набор правил и настроек для серверов и рабочих станций, реализуемых в корпоративных решениях. Реализация групповых политик требует тесной интеграции множества независимых модулей ОС. Рассмотрим особенности реализации поддержки групповых политик Active Directory в Linux-клиентах

Групповые политики как набор механизмов

Существует два основных вида так называемых групповых политик. Это политики для компьютеров и политики для пользователей. Прием пользователей обычно добавляют в группы, что вносит неоднозначность в то, о каких группах и политиках идет речь. Если о группах пользователей, то при чем тут компьютеры? Если об отдельных объектах пользователь или компьютер, то почему политики групповые?

Так вот, кроме групп безопасности (в которые обычно включаются пользователи), в протоколе LDAP предусмотрена иерархия объектов, хранящихся в дереве каталогов (и в соответствующей иерархической базе данных). При этом объекты «пользователи» и «компьютеры» в этом дереве объектов могут быть созданы в разных контейнерах и могут переноситься из одного контейнера в другой. А группировка объектов, на которые распространяются групповые политики, прежде всего распространяется именно на расположение объектов в этих контейнерах. В Active Directory такие контейнеры принято называть организационными подразделениями (organizational units).

За применение групповых политик отвечают клиенты. При этом даже серверы и сами контроллеры домена являются по отношению к настройкам в групповых политиках клиентами. И даже службы, которые обеспечивают работоспособность домена Active Directory, применяют настройки групповых политик, как клиенты. Например, настройки сложности и сроки действия пароля, а также другие параметры KDC (Key Distribution Center – службы, обеспечивающей централизованную аутентификацию) относятся к политикам безопасности, которые применяются из настроек в групповых политиках.

Особенности реализации групповых политик в Linux-клиентах

Задача реализации поддержки групповых политик в Linux-решениях отличается прежде всего тем, что связана скорее с клиентской стороной и проблемой «как применить те или иные политики?», а не только с тем, «где их хранить и как их получить на клиенте?». Тем не менее на Linux-клиентах для Active Directory второй вопрос становится тоже очень важным, поскольку исходное хранилище настроек изначально ориентировано только на клиентские рабочие станции на базе Microsoft Windows.

Стоит отметить, что подходы по управлению конфигурациями на уровне компьютеров (так называемый Configuration Management) уже давно существуют в виде решений на базе Chef, Puppet, Ansible и т.п. инструментов.

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

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

Хотя на уровне средств администрирования групповыми политиками пользовательские политики управляются единообразно, технически их можно разделить на следующие категории:

• политики, применяемые при входе пользователя – в Plugable Authentification Modules (PAM) на этапе аутентификации (PAM auth), смены пароля (PAM password), создания сессии (PAM session) и назначении групп (NSS initgroups);
• пользовательские политики, требующие административных привилегий (подключение сетевых каталогов, настройка сервера печати CUPS и любых других локальных сервисов);
• политики, требующие контекст графической сессии, выполняемые с пользовательскими привилегиями (настройка фона рабочего стола, дополнительные ярлыки на рабочем столе и т.п.).

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

То есть модуль применения групповых политик на Linux-клиентах может быть полноценно интегрирован только в такое дистрибутивное решение, для которого он специально подготовлен.

Чтение и применение групповых политик Active Directory

Механизмы применения групповых политик в Active Directory предполагают, что ответственность за их чтение и применение лежит на клиентах. То есть в каждой версии очередного дистрибутива требуется учитывать особенности интерпретации обобщенных настроек, которые «прилетают» из групповых политик. Это в равной степени относится и к пользовательским политикам, и к политикам компьютеров.

На текущий момент наиболее полная реализация чтения групповых политик под Linux реализована только в рамках отдельных клиентов – в клиентах проекта samba (samba-gpupdate) и в PAM-модулях проекта sssd. Также ряд наработок доступен в репозиториях разработчика из Samba Team и сотрудника компании Suse Дейвида Малдера (https://github.com/dmulder). В целом задача чтения и применения групповых политик Active Directory для Linux-клиентов не имеет полноценного решения.

Рассмотрим далее детальный разбор механизмов чтения и применения групповых политик Active Directory, который сложился в рамках проекта gpom (group policy object manager, https://github.com/altlinuxteam/gpom) для дистрибутивов ALT компании «Базальт СПО».

Пример последовательности чтения групповых политик, представленный на рис. 1, выполняется для политик компьютера (текущего узла, от имени которого проводится аутентификация по протоколу Kerberos). Она включает в себя следующий набор шагов:

• запрос списка SID (глобальных идентификаторов компьютеров, пользователей и групп), относящихся к данному узлу через список групп безопасности, в которые входит данный компьютер;
• построение (через запрос к LDAP-серверу) последовательности ссылок (GPLink) объектов групповых политик (GPO), привязанных к данному узлу;
• запрос набора групповых политик для каждой полученной ссылки за исключением тех, для которых нет специальных ограничений через явный отдельный запрос на атрибут ntSecurityDescriptor для каждого полученного объекта групповых политик.

Рисунок 1. Последовательность чтения групповых политик

В данной последовательности шагов один из важных моментов – необходимость отдельного запроса для атрибута ntSecurityDescriptor, а также формирование правильного порядка в списке полученных GPO.

Рассмотрим далее детальный разбор последовательности действий по применению нескольких групповых политик (для объекта «компьютер» это может быть установка дополнительного программного обеспечения, для объекта «пользователь» – смена настроек рабочего стола или установка принтера). Цепочка действий по применению групповых политик представлена на рис. 2:

• для каждого допустимого GPO на клиенте проводятся проверка, фильтрация и отображение существующих политик на уже реализованные для данного клиента;
• чтение из общего системного сетевого каталога Sysvol (на уровне списка расширений групповых политик – GPE и на уровне настроек конкретных клиентских расширений – CSE) [2].

Рисунок 2. Последовательность применения групповых политик

Проект gpom разрабатывается для дистрибутивов на базе Sisyphus как открытый проект, распространяемый по свободной лицензии. Следующий шаг по включению данного механизма в дистрибутивы ALT предполагает дальнейший разбор и классификацию существующих групповых политик, включение дополнительных сервисов, которые позволят применять групповые политики без перезагрузки и выхода пользователя из системы, а также распределение различных видов политик в рамках соответствующих системных сервисов – например Restricted Groups [3] на уровне SSSD или дополнительного NSS-модуля.

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

Ключевые слова: групповые политики, Active Directory, серверы, контроллеры домена.

Комментарии могут оставлять только зарегистрированные пользователи