Реализация групповых политик в решениях на базе дистрибутивов ALT (Евгений Синельников, OSSDEVCONF-2018)
Материал из 0x1.tv
- Докладчик
- Евгений Синельников
Групповые политики — это набор правил и настроек для серверов и рабочих станций, реализуемых в крупных корпоративных решениях. Реализация групповых политик требует тесной интеграции множества независимых модулей операционной системы. Данный доклад посвящён реализации поддержки групповых политик Active Directory в решениях на базе дистрибутивов ALT и Sisyphus.
Содержание
Видео
Посмотрели доклад? Понравился? Напишите комментарий! Не согласны? Тем более напишите.
Презентация
Thesis
Существует два основных вида так называемых групповых политик. Это политики для компьютеров и политики для пользователей. Причём пользователи обычно добавляются в группы, что вносит неоднозначность — о каких группах и политиках идёт речь? Если о группах пользователей, то причём тут компьютеры? Если об отдельных объектах пользователь или компьютер, то почему политики групповые?
Так вот, кроме групп безопасности (в которые обычно включаются пользователи) в протоколе LDAP предусмотрена иерархия объектов, хранящихся в дереве каталогов (и в соответствующей иерархической базе данных). При этом объекты пользователи и компьютеры в этом дереве объектов могут быть созданы в разных контейнерах и могут переноситься из одного контейнера в другой. А группировка объектов, на которые распространяются групповые политики, прежде всего, распространяется именно на расположение объектов в этих контейнерах. В Active Directory такие контейнеры принято называть организационными подразделениями (organizational units).
Задача реализации поддержки групповых политик в Linux-решениях отличается, прежде всего, тем, что связана скорее с клиентской стороной и проблемой, «как применить те или иные политики?», а не только с тем, «где их хранить и как их получить на клиенте?» Тем не менее, для Active Directory, второй вопрос становится тоже очень важным, поскольку исходное хранилище настроек изначально ориентировано только на клиентские рабочие станции на базе Microsoft Windows. И решению именно этого вопроса, а также момента о том, как интерпретировать неродные Windows политики на Linux клиентах и посвящён этот доклад.
Стоит отметить, что подходы по управлению конфигурациями на уровне компьютеров (Configuration Management) уже давно существуют в виде решений на базе Chef, Puppet, Ansible и т. п. инструментов. А вот увязка такого управления с управлением пользователями в рамках целостной инфраструктуры и единый подход к хранению и управлению этими конфигурациями — задача более высокого уровня. Эта задача включает в себя, со стороны клиента, не только механизм управления настройками отдельных приложений, но и интеграцию применения дополнительных настроек в процессе аутентификации и авторизации, а также управления элементами графического интерфейса и привязку этих настроек отдельным сессиям пользователей, причём не только локальным, но и сетевым.
В связи с этим, для применения пользовательских настроек в проекте gpom мы разделили пользовательские политики на следующие категории:
- политики применяемые при входе пользователя, на этапе создания сессии (PAM session и NSS initgroups);
- пользовательские политики, требующие административных привилегий (настройка CUPS и т.п.);
- политики, требующие контекст графической сессии, выполняемые с пользовательскими привилегиями (фон рабочего стола, дополнительные ярлыки на рабочем столе и т. п.).
На текущий момент в рамках проекта по применению групповых политик мы детально разобрали последовательность чтения групповых политик (рис. 1):
- хранение в LDAP (на уровне привязки (GPLink) объектов групповых политик (GPO) к LDAP-объектам пользователи и компьютеры);
- сценарий их применения (на уровне порядка действий по учёту специальных ограничений — ntSecurityDescriptor).
Кроме того, мы детально разобрали последовательность действий по применению нескольких групповых политик — установка программного обеспечения, смена настроек рабочего стола, установка принтера. Цепочка действий по применению групповых политик представлена на рис. 2:
- фильтрация и отображение существующих политик на уже реализованные;
- чтение из Sysvol (на уровне списка расширений групповых политик — GPE и настроек конкретных клиентских расширений — CSE) .
Следующий шаг по включению данного механизма предполагает дальнейший разбор и классификацию существующих групповых политик, включение дополнительных сервисов которые позволят применять групповые политики без перезагрузки и выхода пользователя из системы, а также распределение различных видов политик в рамках соответствующих системных сервисов — например Restricted Groups на уровне SSSD или дополнительного NSS-модуля.
Существует два основных вида так называемых групповых политик. Это политики для компьютеров и политики для пользователей. Причём пользователи обычно добавляются в группы, что вносит неоднозначность — о каких группах и политиках идёт речь? Если о группах пользователей, то причём тут компьютеры? Если об отдельных объектах пользователь или компьютер, то почему политики групповые?
Так вот, кроме групп безопасности (в которые обычно включаются пользователи) в протоколе LDAP предусмотрена иерархия объектов, хранящихся в дереве каталогов (и в соответствующей иерархической базе данных). При этом объекты пользователи и компьютеры в этом дереве объектов могут быть созданы в разных контейнерах и могут переноситься из одного контейнера в другой. А группировка объектов, на которые распространяются групповые политики, прежде всего, распространяется именно на расположение объектов в этих контейнерах. В Active Directory такие контейнеры принято называть организационными подразделениями (organizational units).
Задача реализации поддержки групповых политик в Linux-решениях отличается, прежде всего, тем, что связана скорее с клиентской стороной и проблемой, «как применить те или иные политики?», а не только с тем, «где их хранить и как их получить на клиенте?» Тем не менее, для Active Directory, второй вопрос становится тоже очень важным, поскольку исходное хранилище настроек изначально ориентировано только на клиентские рабочие станции на базе Microsoft Windows. И решению именно этого вопроса, а также момента о том, как интерпретировать неродные Windows политики на Linux клиентах и посвящён этот доклад.
Стоит отметить, что подходы по управлению конфигурациями на уровне компьютеров (Configuration Management) уже давно существуют в виде решений на базе Chef, Puppet, Ansible и т. п. инструментов. А вот увязка такого управления с управлением пользователями в рамках целостной инфраструктуры и единый подход к хранению и управлению этими конфигурациями — задача более высокого уровня. Эта задача включает в себя, со стороны клиента, не только механизм управления настройками отдельных приложений, но и интеграцию применения дополнительных настроек в процессе аутентификации и авторизации, а также управления элементами графического интерфейса и привязку этих настроек отдельным сессиям пользователей, причём не только локальным, но и сетевым.
В связи с этим, для применения пользовательских настроек в проекте gpom мы разделили пользовательские политики на следующие категории:
- политики применяемые при входе пользователя, на этапе создания сессии (PAM session и NSS initgroups);
- пользовательские политики, требующие административных привилегий (настройка CUPS и т.п.);
- политики, требующие контекст графической сессии, выполняемые с пользовательскими привилегиями (фон рабочего стола, дополнительные ярлыки на рабочем столе и т. п.).
На текущий момент в рамках проекта по применению групповых политик мы детально разобрали последовательность чтения групповых политик (рис. 1):
- хранение в LDAP (на уровне привязки (GPLink) объектов групповых политик (GPO) к LDAP-объектам пользователи и компьютеры);
- сценарий их применения (на уровне порядка действий по учёту специальных ограничений — ntSecurityDescriptor).
Кроме того, мы детально разобрали последовательность действий по применению нескольких групповых политик — установка программного обеспечения, смена настроек рабочего стола, установка принтера. Цепочка действий по применению групповых политик представлена на рис. 2:
- фильтрация и отображение существующих политик на уже реализованные;
- чтение из Sysvol (на уровне списка расширений групповых политик — GPE и настроек конкретных клиентских расширений — CSE).
Следующий шаг по включению данного механизма предполагает дальнейший разбор и классификацию существующих групповых политик, включение дополнительных сервисов которые позволят применять групповые политики без перезагрузки и выхода пользователя из системы, а также распределение различных видов политик в рамках соответствующих системных сервисов — например Restricted Groups на уровне SSSD или дополнительного NSS-модуля.
!.jpg)
Примечания и ссылки
Plays:48 Comments:0