Модуль 6. Управление политиками ALD Pro

Введение

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

Мы сравним техническую реализацию политик MS AD с политиками FreeIPA и ALD Pro, выполним настройку и отладку политик с использованием параметров, доступных из коробки, а также посмотрим, как создаются дополнительные параметры, с помощью которых можно организовать централизованное управление настройками любых корпоративных приложений.

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

Концепция групповых политик

Как известно, уникальные продукты никому не нужны, а у всех востребованных решений быстро появляются аналоги, поэтому, создавая политики, разработчики FreeIPA и ALD Pro ориентировались в первую очередь на передовой опыт Microsoft.

Для новых администраторов слово «политика» может показаться странным, т.к. обычно оно ассоциируется с чем-то серьезным про менеджмент на уровне государства, а в английском языке это слово означает просто «правила», например, «Правила поведения учащихся» у них называются «Школьной политикой» (англ. School policies).

Таким образом, «политики» в Windows — это правила, в соответствии с которыми отдельный компьютер выполняет настройку рабочей среды, а «групповыми» они называются потому, что мы можем группировать эти правила в так называемые объекты. Согласитесь, если бы технология называлась «сгруппированные правила», то было бы на порядок проще, хотя и не так красиво.

В домене Active Directory объекты групповой политики можно назначить на домены, сайты и структурные подразделения, настраивая типовым образом окружение для сотен и даже тысяч пользователей и компьютеров сразу. Это позволяет многократно снижать расходы на администрирование ИТ-инфраструктуры, чем и объясняется популярность групповых политик.

В настоящий момент сложно себе представить предприятие, где было бы более тысячи компьютеров и не применялись бы групповые политики. Поэтому навыки управления групповыми политиками являются обязательным минимумом для администратора домена уровня Senior.

Политики паролей

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

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

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

Изменить пароль можно по протоколу KPASSWD (464/TCP), через расширенную операцию LDAP+StartTLS (389/TCP) и просто записью нового значения в атрибут userPassword, опять же, по протоколу LDAP. Однако вне зависимости от того, какой способ будет выбран, пароль передается на сервер в открытом виде, что позволяет проверить его длину, сложность и другие параметры, после чего сгенерировать и сохранить совместимые хеши.

Политики паролей Windows

Раньше в домене Active Directory можно было задать только одну политику паролей через объект групповой политики Default Domain Policy. Да, вы можете создать несколько объектов и в каждом из них определить параметры из секции Password Policy, но ко всем пользователям в домене все равно будут применяться только те требования, которые определены в Default Domain Policy («Костыль?» — спросите вы. Не, ну в продуктах Microsoft такого не может быть!).

рис. 242 Политика паролей по умолчанию (Default Domain Policy)

Начиная с Windows Server 2008, в MS AD появились так называемые детальные политики паролей (Fine-Grained Password Policy, FGPPs), которые настраиваются в Центре администрирования Active Directory (Active Directory Administrative Center) путем создания контейнера настроек пароля (Password Settings Container). Каждый контейнер может быть назначен конкретным пользователям и группам, переопределяя их требования к паролям.

Следует обратить внимание также на атрибут Precedence, который определяет приоритет данной политики паролей. Если на пользователя AD действуют несколько политик, то к нему будет применена политика с меньшим значением приоритета.

рис. 243 Детальная политика паролей (Fine-Grained Password Policy, FGPPs)

Политики паролей FreeIPA

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

• Из контейнера «cn=cosTemplates,cn=accounts» отбираются шаблоны, под действие которых попадает текущий пользователь в соответствии с его участием в группах.

  В этих записях содержится минимальное количество информации, а расширенные наборы параметров представлены в контейнере «cn=kerberos» и связаны с шаблонами ссылками через значение атрибута krbPwdPolicyReference.

• Если на пользователя не распространяется действие ни одной политики, ему будет назначена глобальная политика (global_policy) по умолчанию, см. рис. 244

• Если пользователь попадает под действие сразу нескольких политик, то параметры политик не суммируются, а выбирается одна из них, приоритет которой будет иметь наименьшее значение, см. табл. 20, что аналогично действию параметра Precedence в политиках паролей Windows.

рис. 244 Запись глобальной политики паролей в LDAP-каталоге

табл. 20 Выбор политики в зависимости от приоритета

Параметр	Политика для группы А(приоритет 0)	Политика для группы В(приоритет 1)	Результат (используются параметры для группы А, приоритет 0)
Максимальный срок действия пароля	60 дней	90 дней	60 дней
Минимальная длина пароля	10 символов	0 символов (без ограничений)	10 символов

Проверки паролей ограничены возможностями MIT Kerberos, поэтому они поддерживают тот же самый набор параметров (см. табл. 21).

табл. 21 Параметры политик паролей

Параметр глобальной политики	Значение по умолчанию
Максимальный срок действия задает период в количестве дней, в течение которого система не будет требовать смены пароля	krbMaxPwdLife = 90 Пароль активен 90 дней, после чего пользователю будет предложено сменить его.
Минимальный срок действия задает период в часах, в течение которого система будет запрещать повторную смену пароля	krbMinPwdLife = 1 После смены пароля пользователь должен подождать 1 час перед повторной сменой.
Размер журнала определяет количество предыдущих паролей, которые нельзя использовать повторно	krbPwdHistoryLength = 0 Запрет на повторное использование паролей не налагается.
Классы символов – это параметр, который определяет требование по сложности пароля, указывая сколько разных классов символов должно быть использовано в пароле: цифры; буквы нижнего регистра; буквы верхнего регистра; символы UTF-8; все остальные символы, не вошедшие ни в одну из предыдущих групп, например, ! « # $ % и т.д. При использовании одного и того же символа более двух раз подряд сложность пароля будет занижена на один балл. Например, если сложность пароля «Secret1pwd» будет оценена в три балла (большие буквы + маленькие буквы + цифры), то для пароля «Secret111pwd» сложность снизится до двух баллов (минус один балл за повторы символа «1»).	krbPwdMinDiffChars = 0 Требований по сложности пароля по умолчанию нет. Интересный факт, что при подсчете повторов последний символ в пароле не учитывается, поэтому если повторяющиеся символы будут идти в конце строки, то нужно, чтобы их было не меньше четырех «Secretpwd1111», иначе штраф налагаться не будет.
Минимальная длина задает минимально допустимое количество символов в пароле.	krbPwdMinLength = 8 Пользователь не может использовать пароль короче 8 символов.
Максимальное количество ошибок определяет, сколько раз пользователь может неправильно ввести пароль, прежде чем его учетная запись будет временно заблокирована. Блокировка выполняется только на текущем контроллере, на другие сервера эта информация не передается.	krbPwdMaxFailure = 6 Пользователь будет временно заблокирован после 7 неверно введенных паролей подряд. Срок блокировки указан в параметре krbPwdLockoutDuration.
Интервал сброса ошибок задает период в секундах, по истечении которого счетчик неудачных попыток входа будет сброшен.	krbPwdFailureCountInterval = 60 Если пользователь выждет 1 минуту после 6 неудачных попыток введения пароля, то счетчик неудачных попыток обнулится.
Длительность блокировки задает период в секундах, в течение которого пользователь не сможет выполнить аутентификацию в домене. Блокировка накладывается после превышения количества разрешенных неудачных попыток входа. Блокировка выполняется только на текущем контроллере, на другие сервера эта информация не передается.	krbPwdLockoutDuration = 600 Временно заблокированный пользователь не сможет осуществить вход в систему в течение последующих 10 минут.

Следствием интеграции с MIT Kerberos является возможность использования таких атрибутов, как krbPrincipalExpiration и krbLastSuccessfulAuth. Например, с помощью команды ipa user-mod вы можете установить срок действия учетной записи, после которого пользователю станет недоступна Kerberos-аутентификация:

admin@dc-1:~$ ipa user-mod alexander.kuznetsov \
--principal-expiration='20330725115110Z'

Где срок действия учетной записи задается в формате временной метки GeneralizedTime:

• 2033 – год;

• 07 – месяц;

• 25 – день месяца;

• 115110 – часы, минуты, секунды;

• Z – часовой пояс по нулевому (Zero) меридиану.

Примечание

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

Однако, если у вас достаточно вычислительных ресурсов и хорошие каналы связи, то вы можете включить эти функции изменением конфигурации сервера. Для этого потребуется посмотреть текущие настройки и установить новое значение параметра ipaconfigstring, исключив из него значение «KDC:Disable Last Success»:

admin@dc-1:~$ ipa config-show | grep паролей
  Возможности подключаемого модуля паролей: AllowNThash, KDC:Disable Last Success
admin@dc-1:~$ ipa config-mod --ipaconfigstring='AllowNThash'
  Максимальная длина имени пользователя: 32
  Максимальная длина имени хоста: 64
  Основа домашних каталогов: /home
  Оболочка по умолчанию: /bin/bash
  Группа пользователей по умолчанию: ipausers
  Почтовый домен по умолчанию: ald.company.lan
  Ограничение времени поиска: 5
  Ограничение размера поиска: 500
  Поля поиска пользователей: uid,givenname,sn,telephonenumber,ou,title
  Поля поиска групп: cn,description
  Включить режим миграции: FALSE
  Основа субъекта сертификата: O=ALD.COMPANY.LAN
  Уведомление об окончании действия пароля (в днях): 4
  Возможности подключаемого модуля паролей: AllowNThash
  Порядок применения списка пользователей SELinux: guest_u:s0$xguest_u:s0$user_u:s0$staff_u:s0-s0:c0.c1023$sysadm_u:s0-s0:c0.c1023$unconfined_u:s0-s0:c0.c1023
  Пользователь SELinux по умолчанию: unconfined_u:s0-s0:c0.c1023
  Типы PAC по умолчанию: MS-PAC, nfs:NONE
  Главные IPA-серверы: dc-1.ald.company.lan
  Главный IPA-сервер с поддержкой PKINIT: dc-1.ald.company.lan
  DNS-серверы IPA: dc-1.ald.company.lan
admin@dc-1:~$ sudo ipactl restart
[sudo] пароль для admin:
Restarting Directory Service
Restarting krb5kdc Service
Restarting kadmin Service
Restarting named Service
Restarting httpd Service
Restarting ipa-custodia Service
Restarting smb Service
Restarting winbind Service
Restarting ipa-otpd Service
Restarting ipa-dnskeysyncd Service
ipa: INFO: The ipactl command was successful
admin@dc-1:~$ kinit admin
Password for admin@ALD.COMPANY.LAN:
admin@dc-1:~$ ipa user-show admin --all --raw | grep krbLastSuccessful
  krbLastSuccessfulAuth: 20241009095204Z

Настройка политики паролей

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

Откройте страницу Групповые политики ‣ Политики паролей и нажмите кнопку + Новая политика паролей. В поле «Наименование группы пользователей» выберите admins, установите наименьший «Приоритет», равный 0, и нажмите кнопку Сохранить. Далее вам станет доступна страница управления политикой, где вы можете задать необходимые настройки, как на нижеприведенной иллюстрации.

рис. 245 Создание новой политики паролей

Политику паролей можно создать из командной строки с помощью команды ipa pwpolicy-add:

admin@dc-1:~$ ipa pwpolicy-add admins \
--priority=0 --maxlife=45 --minlife=0 --history=12 \
--minclasses=5 --minlength=12 --maxfail=3 \
--failinterval=120 --lockouttime=1200
  Группа: admins
  Максимальный срок действия (в днях): 45
  Минимальный срок действия (в часах): 0
  Размер журнала : 12
  Классы символов: 5
  Минимальная длина: 12
  Приоритет: 0
  Максимальное количество ошибок: 3
  Интервал сброса ошибок: 120
  Длительность блокировки: 1200

Где:

• Ключ --maxlife=<число> — максимальный срок действия в днях;

• Ключ --minlife=<число> — минимальный срок действия в часах;

• Ключ --history=<число> — размер журнала;

• Ключ --minclasses=<число> —классы символов;

• Ключ --minlength=<число> — минимальная длина;

• Ключ --priority=<число> — приоритет политики;

• Ключ --maxfail=<число> — максимальное количество ошибок;

• Ключ --failinterval=<число> — интервал сброса ошибок в секундах;

• Ключ --lockouttime=<число> — длительность блокировки в секундах.

Изменить параметры уже существующей политики можно командой ipa pwpolicy-mod. Увеличим интервал сброса ошибок для политики группы admins с 120 до 3600 секунд, но уменьшим длительность блокировки с 1200 до 300 секунд:

admin@dc-1:~$ ipa pwpolicy-mod admins --failinterval=3600 --lockouttime=300
  Группа: admins
  Максимальный срок действия (в днях): 45
  Минимальный срок действия (в часах): 0
  Размер журнала : 12
  Классы символов: 5
  Минимальная длина: 12
  Приоритет: 0
  Максимальное количество ошибок: 3
  Интервал сброса ошибок: 3600
  Длительность блокировки: 300

Обратите внимание, что изменение максимального срока действия пароля сразу же ни на что не повлияет, т.к. проверка выполняется по значению пользовательского атрибута krbPasswordExpiration, которое устанавливается в момент смены пароля. Текущее значение этого атрибута можно уточнить командой ipa user-show:

admin@dc-1:~$ ipa user-show admin --raw --all | grep krbPasswordExpiration
krbPasswordExpiration: 20240414095400Z

Таким образом, чтобы изменения в части срока действия паролей вступили в силу, пользователь должен хотя бы один раз сменить свой пароль, но при необходимости вы можете установить значение krbPasswordExpiration вручную с помощью команды ipa user-mod. Это удобно также в тех случаях, когда вам нужно сбросить пользователю пароль, но вы не хотите, чтобы система сразу же требовала смены пароля.

admin@dc-1:~$ ipa user-mod admin --password-expiration 20240301010101Z
----------------------------
Изменён пользователь "admin"
----------------------------
Имя учётной записи пользователя: admin
Фамилия: Administrator
Домашний каталог: /home/admin
Оболочка входа: /bin/bash
Псевдоним учётной записи: admin@ALD.COMPANY.LAN, root@ALD.COMPANY.LAN
Окончание действия пароля пользователя: 20240701010101Z
UID: 1902000000
ID группы: 1902000000
Учётная запись отключена: False
Link to department: ou=ald.company.lan,cn=orgunits,cn=accounts,dc=ald,dc=company,dc=lan
Link to head department: ald.company.lan
Пароль: True
Участник групп: trust admins, ald trust admin, admins, lpadmin
Роли: ALDPRO - Main Administrator
Доступные ключи Kerberos: True

Группы с автоматическим участием

Область применения HBAC-правил можно задать с помощью групп пользователей и групп хостов, но в некоторых случаях может быть удобнее использовать для этого структурные подразделения. В этом случае вы можете воспользоваться вспомогательными группами и правилами автоучастия (от англ. automember).

Привязка объектов к структурным подразделениям в ALD Pro осуществляется с помощью атрибута rbtadp, в котором хранится ссылка на целевое подразделение в формате полного уникального имени записи (от англ. Distinguished name, DN). Например, если у вас в корне домена есть структурное подразделение «Московский офис», то значение атрибута rbtadp всех дочерних объектов будет «ou=Московский офис,ou=ald.company.lan,cn=orgunits,cn=accounts,dc=ald,dc=company,dc=lan».

Если вам потребуется ограничить выборку только прямыми наследниками, вы можете поставить символ подстановки «^» в начало строки, что позволит вам исключить объекты из подразделений, расположенных ниже по иерархии организационной структуры.

Создадим группу пользователей и правило автоучастия из веб-интерфейса:

1. Создайте группу пользователей. Для этого на странице Пользователи и компьютеры ‣ Группы пользователей нажмите кнопку + Новая группа, введите название группы «moscow-office-employees», выберите подразделение «Московский офис» и нажмите кнопку Сохранить.

2. Создайте правило автоучастия. Для этого потребуется воспользоваться интерфейсом FreeIPA https://dc-1.ald.company.lan/ipa/ui. Откройте страницу Идентификация ‣ Автоучастник ‣ Правила группы пользователей, нажмите кнопку Добавить, см. рис. 247. В диалоговом окне добавления правила выберите группу «moscow-office-employees» из списка и нажмите кнопку Добавить и изменить.

рис. 246 Переход к списку правил автоучастия для групп пользователей

рис. 247 Создание правила автоучастия для группы moscow-office-employees

1. На странице редактирования добавьте критерий отбора по атрибуту rbtadp и значению «ou=Московский офис,ou=ald.company.lan,cn=orgunits,cn=accounts,dc=ald,dc=company,dc=lan», см. рис. 248. Не забудьте нажать кнопку «Сохранить».

рис. 248 Редактирование правила автоучастия для группы moscow-office-employees

Пересчет правил автоучастия происходит не мгновенно, но вы можете ускорить применение этих правил с помощью команды ipa automember-rebuild:

admin@dc-1:~$ ipa automember-rebuild --type=group
--------------------------------------------------------------------
Automember rebuild task finished. Processed (5) entries in 0 seconds
--------------------------------------------------------------------

admin@dc-1:~$ ipa group-show moscow-office-employees | grep "Пользователи"
Пользователи-участники: asidorov, ppetrov, iivanov, vsidorova

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

Тоже самое можно сделать из командной строки:

1. Создать группу пользователей moscow-office-employees в подразделении «Московский офис»:

admin@dc-1:~$ ipa group-add moscow-office-employees
admin@dc-1:~$ ipa group-mod moscow-office-employees --setattr="rbtadp=ou=Московский офис,ou=ald.company.lan,cn=orgunits,cn=accounts,dc=ald,dc=company,dc=lan"
admin@dc-1:~$ ipa group-mod moscow-office-employees --desc='Группа, в которой будут все сотрудники московского офиса'

2. Создать правило автоучастия и определить критерий автоучастия:

admin@dc-1:~$ ipa automember-add moscow-office-employees --type=group
admin@dc-1:~$ ipa automember-mod moscow-office-employees --type=group --desc='Правило автоучастия для наполнения группы сотрудников московского офиса'
admin@dc-1:~$ ipa automember-add-condition moscow-office-employees \
--type=group --key=rbtadp --inclusive-
regex='ou=Московский офис,ou=ald.company.lan,cn=orgunits,cn=accounts,dc=ald,dc=company,dc=lan'

3. Принудительно обновить состав автоучастников (запускать команду нужно только 1 раз, в дальнейшем правила будут срабатывать автоматически изменении подразделения объекта):

admin@dc-1:~$ ipa automember-rebuild --type=group

Политики доступа к узлу (HBAC-правила)

Только представьте себе: новому сотруднику с задатками пентестера выдают ноутбук, блокнот, кружку и доменную учетную запись, а он вместо того, чтобы пойти за кофе, начинает сразу же ломиться на серверы по всем доступным протоколам. И если системный администратор не подумает об этом сценарии заранее, то пользователь прорвется на сервер, а далее останется уповать только на правильные настройки доступа к объектам файловой системы.

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

Политика локального входа Windows

В домене Active Directory управлять правами локального входа в систему можно с помощью двух параметров групповых политик, которые находятся в разделе Computer Configuration ‣ Policies ‣ Security Settings в подразделе Local Policies ‣ User Rights Assignment (Конфигурация пользователя ‣ Политики ‣ Параметры безопасности и Локальные политики ‣ Назначение прав пользователя):

• Allow log on locally (Локальный вход в систему) — определяет список пользователей и групп, которым разрешен локальный вход в систему.

• Deny log on locally (Запретить локальный вход) — определяет список пользователей и групп, которым запрещен локальный вход в систему. Если пользователь попадает под действие двух параметров сразу, то запрещающий параметр имеет больше приоритет, поэтому доступ будет заблокирован.

На контроллеры домена AD интерактивно могут заходить только пользователи шести административных групп, что определено параметрами объекта групповой политики Default Domain Controllers Policy, см. рис. 249.

рис. 249 Настройки параметра Allow log on locally в объекте групповой политики Default Domain Controllers Policy

Политики доступа к узлу FreeIPA

Для ограничения доступа к компьютерам в домене FreeIPA есть мощные правила управления доступом к хостам (от англ. host-based access control, HBAC), которые значительно превосходят по функциональности политики локального входа Windows. Они создают дополнительный слой авторизации, позволяя разрешить определенным пользователям использовать указанные службы на конкретных хостах.

Что такое «пользователи» и «хосты», обычно вопросов не вызывает, но понятие «служб» требует дополнительных пояснений. В контексте правил HBAC службами являются любые приложения, которые используют PAM-стек, и при этом не важно, являются ли эти приложения просто исполняемыми файлами или работают как демоны в фоновом режиме.

Как мы уже знаем, библиотека подключаемых модулей аутентификации (от англ. Pluggable Authentication Modules, PAM) обеспечивает унифицированный программный интерфейс для абстрагирования приложений (таких как login, sshd или sudo) от выполнения стандартных задач аутентификации.

Перечень необходимых модулей аутентификации для каждого приложения задается индивидуально с помощью конфигурационных файлов из директории /etc/pam.d, поэтому настройки могут быть изменены в любой момент, что не потребует повторной компиляции приложения. За обработку правил HBAC, например, отвечает модуль pam_sss.so, который является одной из клиентских библиотек службы sssd, обеспечивающей работу хоста в домене. Механизм работы правил HBAC отражен на рисунке рис. 250.

При подключении пользователя по ssh служба sshd обращается к библиотеке PAM, чтобы создать контекст безопасности для выполнения команд от имени этого пользователя. При вызове функции «pam_start» служба передает библиотеке свой идентификатор (PAM service name), который представляет собой простую строку, например, «sshd». Идентификатор службы обычно совпадает с именем исполняемого файла, но это не является обязательным условием, а некоторые приложения могут использовать даже несколько идентификаторов, например, утилита sudo может применять дополнительный идентификатор sudo-i. Идентификатор службы определяет имя файла из каталога pam.d, откуда библиотека PAM будет брать настройки стека модулей (например, для службы sshd настройки будут из файла /etc/pam.d/sshd).

Для вступления в силу изменений в настройках HBAC-правил вы можете воспользоваться на целевой машине командами sss_cache -E или sssctl cache-remove, чтобы очистить локальный кэш службы sssd.

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

рис. 250 Механизм работы HBAC-правил

Еще один важный момент. В силу особенностей FreeIPA в правилах HBAC не получится использовать следующие группы:

• группу пользователей ipausers, т.к. у нее нет POSIX-идентификатора, и поэтому на целевых хостах служба SSSD не отображает участие пользователей в этой группе;

• группу хостов ipaservers, т.к. у нее нет класса mepManagedEntry и соответствующих зависимостей.

Самый простой способ обойти указанные проблемы – это создать вспомогательные группы posix-ipausers/posix-ipaservers и сделать группы ipausers/ipaservers их участниками. В этом случае можно использовать вспомогательные группы в политиках без ограничений.

Настройка политик доступа к узлу

Ограничиваем доступ к серверам

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

Внести указанные настройки можно через веб-портал управления на странице Групповые политики ‣ Политики доступа к узлу ‣ allow_all ‣ Пользователи, см. рис. 251, или через командную строку:

admin@dc-1:~$ kinit admin
admin@dc-1:~$ ipa hbacrule-show allow_all
admin@dc-1:~$ ipa hbacrule-mod allow_all --usercat=''
admin@dc-1:~$ ipa hbacrule-add-user allow_all --group admins
admin@dc-1:~$ ipa hbacrule-mod allow_all --desc='Разрешает администраторам доступ к любому хосту в домене'

Где:

• hbacrule-mod — команда, с помощью которой можно модифицировать настройки существующей группы;

  • allow_all — имя правила, которые мы хотим модифицировать;

  • usercat (от англ. user category) — ключ, который позволяет изменить категорию для области применения в части пользователей. Может принимать значение „all“ или пустую строку „“;

• hbacrule-add-user — команда, с помощью которой можно расширить область применения правила в части пользователей;

  • allow_all — имя правила, которое мы хотим модифицировать;

  • group — ключ, который позволяет добавить группу пользователей в область применения HBAC-правила;

  • admins — имя группы, которая будет добавлена в область применения правила;

• hbacrule-show — команда, с помощью которой можно получить информацию о существующем HBAC-правиле;

  • allow_all — имя правила, по которому мы хотим получить информацию;

рис. 251 Настройка HBAC-правила allow_all.

Примечание

Если из-за неправильной настройки HBAC-правил доступ к хостам будет все же заблокирован, вы сможете подключиться к порталу управления с любого другого компьютера, который не находится в домене, чтобы исправить ошибку. Доступ к порталу управления не регулируется через механизм HBAC-правил.

Если ограничить область действия правила allow_all группой администраторов, то для остальных сотрудников компании нужно будет создать правило allow_computers, которое предоставит им право входа на обычные компьютеры в домене.

Сделаем все из командной строки:

admin@dc-1:~$ ipa hostgroup-add computers # создание группы компьютеров
admin@dc-1:~$ ipa hostgroup-mod computers --desc='Группа, в которой будут все обычные компьютеры домена' # описание
admin@dc-1:~$ ipa hostgroup-add-member computers --hosts pc-1 # включение в группу хоста pc-1
admin@dc-1:~$ ipa hbacrule-del allow_computers # удаление созданного ранее HBAC-правила
admin@dc-1:~$ ipa hbacrule-add allow_computers # создание HBAC-правила
admin@dc-1:~$ ipa hbacrule-mod allow_computers --desc='Разрешает всем пользователям доступ к обычным компьютерам в домене' # описание
admin@dc-1:~$ ipa hbacrule-mod allow_computers --usercat=all # установить область применения на всех пользователей
admin@dc-1:~$ ipa hbacrule-mod allow_computers --servicecat=all # установить область применения на все службы
admin@dc-1:~$ ipa hbacrule-add-host allow_computers --hostgroup computers # назначить правило на группу хостов

Где:

• Команда ipa hbacrule-add — создает HBAC-правила;

• Команда ipa hbacrule-mod — модифицирует правила, ключ --desc позволяет задать описание;

• Команда ipa hbacrule-add-host — команда позволяет определить область применения правила;

• Ключ --hostgroups — позволяет указать группу хостов.

Убедимся, что пользователь iivanov в данный момент имеет право входить на компьютер pc-1.

1. Войдем пользователем iivanov на компьютер pc-1 в режиме рабочего стола.

2. После успешного входа сменим сессию на пользователя admin и проверим журнал /var/log/auth.log:

admin@pc-1:~$ sudo grep -i iivanov var/log/auth.log | tail
. . .
Feb 2 12:12:55 pc-1 fly-dm[29087]: :0[29087]: pam_unix(fly-dm:auth): authentication failure;
logname= uid=0 euid=0 tty=/dev/tty7 ruser= rhost= user=iivanov@ald.company.lan
Feb 2 12:12:55 pc-1 fly-dm[29087]: :0[29087]: pam_sss(fly-dm:auth): authentication success;
logname= uid=0 euid=0 tty=/dev/tty7 ruser= rhost= user=iivanov@ald.company.lan
Feb 2 12:12:55 pc-1 fly-dm[29087]: :0[29087]: pam_sss(fly-dm:account): Access denied for user
iivanov@ald.company.lan: 6 (Доступ запрещен)
. . .
Feb 2 12:43:12 pc-1 fly-dm[29087]: :0[29087]: pam_unix(fly-dm:auth): authentication failure;
logname= uid=0 euid=0 tty=/dev/tty7 ruser= rhost= user=iivanov@ald.company.lan
Feb 2 12:43:12 pc-1 fly-dm[29087]: :0[29087]: pam_sss(fly-dm:auth): authentication success;
logname= uid=0 euid=0 tty=/dev/tty7 ruser= rhost= user=iivanov@ald.company.lan
Feb 2 12:43:12 pc-1 fly-dm[29087]: :0[29087]: pam_kiosk2(fly-dm:session): No
iivanov@ald.company.lan profile found, trying common profile
Feb 2 12:43:12 pc-1 fly-dm[29087]: :0[29087]: pam_unix(fly-dm:session): session opened for user
iivanov@ald.company.lan by (uid=0)
. . .

Из журнала видно, что при попытке входа пользователем iivanov до создания правила computers_allow эта учётная запись не прошла проверку в модуле pam_sss подсистемы аутентификации pam. Более того, по журналу мы видим, что доступ требовался службе с идентификатором fly-dm.

Гранулированный доступ к службам

Для тонкой настройки HBAC-правил необходимо тщательно анализировать типовые сценарии работы пользователей в части используемых служб. Например, для подключения по RDP потребуются fly-wm и xrdp-sesman, см. табл. 22:

табл. 22 Службы, необходимые для типовых сценариев работы

Сценарий работы пользователя	К каким идентификаторам служб следует предоставить доступ
Локальный вход в систему	fly-dm
Удаленный доступ к менеджеру окон по протоколу RDP	fly-wm, xrdp-sesman
Удаленное администрирование по протоколу SSH	sshd, sudo

Чтобы понять, к какой службе требуется предоставить доступ, проще всего выполнить необходимое действие на целевой системе и посмотреть, какие сообщения об ошибках появятся в журнале /var/log/auth.log. На приведенном ниже примере видно, что пользователю не хватает прав на запуск sshd:

root@pc-1:~# tail -f /var/log/auth.log
...
Mar 15 15:25:22 client 4 sshd[30424]: pam_sss(sshd:account): Access denied
for user alexander.kuznetsov: 6 (Permission denied)
...

После развертывания домена в системе уже есть список наиболее распространенных служб, но какие-то службы нам все равно потребуется добавить вручную. Давайте создадим «fly-dm», «fly-wm» и «xrdp-sessman». Сделать это можно через веб-интерфейс на странице Групповые политики ‣ Политики доступа к узлу ‣ Службы HBAC, см. рис. 252, или из командной строки:

admin@dc-1:~$ kinit admin
admin@dc-1:~$ ipa hbacsvc-add 'fly-dm' --desc='Локальный вход ALSE'
admin@dc-1:~$ ipa hbacsvc-add 'fly-wm' --desc='Доступ к оконному менеджеру ALSE'
admin@dc-1:~$ ipa hbacsvc-add 'xrdp-sesman' --desc='Доступ по RDP'

рис. 252 Добавление служб HBAC в интерфейсе портала управления ALD Pro

Допустим, нам нужно предоставить возможность разработчикам из группы dev-users удаленно подключаться к своим компьютерам из группы dev-computers через SSH/RDP и выполнять отдельные команды из-под sudo. Для этого откройте страницу Групповые политики ‣ Политики доступа к узлу ‣ Правила HBAC и нажмите кнопку Новое правило. Введите имя правила «allow_developers» и нажмите кнопку Сохранить. Настройте область применения правила: группа пользователей «dev-users», группа хостов «dev-computers», службы fly-dm, fly-wm, xrdp-sesman, sshd и sudo. Тоже самое можно сделать из командной строки:

admin@dc-1:~$ kinit admin
admin@dc-1:~$ ipa hbacrule-add allow_developers --desc='Доступ для разработчиков'
admin@dc-1:~$ ipa hbacrule-add-user allow_developers --groups dev-users
admin@dc-1:~$ ipa hbacrule-add-host allow_developers --hostgroups dev-computers
admin@dc-1:~$ ipa hbacrule-add-service allow_developers --hbacsvcs fly-dm
admin@dc-1:~$ ipa hbacrule-add-service allow_developers --hbacsvcs fly-wm
admin@dc-1:~$ ipa hbacrule-add-service allow_developers --hbacsvcs xrdp-sesman
admin@dc-1:~$ ipa hbacrule-add-service allow_developers --hbacsvcs sshd
admin@dc-1:~$ ipa hbacrule-add-service allow_developers --hbacsvcs sudo

Проверка HBAC-правил

Когда у вас в домене два-три правила, их довольно легко проверить напрямую, подключаясь к целевым хостам под тестовыми учетными записями. Но в реальной инфраструктуре потребуется управлять десятками правил, и упростить их отладку поможет команда ipa hbactest, которая работает как RSOP в Windows, моделируя применение правил по тому же алгоритму, который будет использовать служба SSSD.

Вы можете выполнить команду на любом контроллере домена и для любого сочетания пользователь-хост-сервис, чтобы получить ответ о том, есть ли в домене правило, которое соответствует этим критериям. Например, давайте проверим, что iivanov имеет доступ к службе sudo на хосте pc-1:

admin@dc-1:~$ ipa hbactest --user=iivanov --host=pc-1 --service=sudo
-------------------------
Доступ предоставлен: True
-------------------------
Соответствующие правила: allow_computers
Несоответствующие правила: allow_all
Несоответствующие правила: allow_computers_fly
Несоответствующие правила: allow_systemd-user

Выполним проверку конкретного правила allow_computers_fly с помощью ключа --rules, сможет ли пользователь ppetrov выполнить вход на компьютер pc-1, для чего ему нужна служба fly-dm:

admin@dc-1:~$ ipa hbactest --user=ppetrov --host=pc-1 --service=fly-dm --rules allow_computers_fly
-------------------------
Доступ предоставлен: True
-------------------------
 Соответствующие правила: allow_computers_fly

Политики повышения привилегий (SUDO-правила)

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

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

Запуск от имени другого пользователя в Windows

В операционной системе Windows запустить приложение от имени другого пользователя проще всего, если кликнуть по файлу правой кнопкой мыши, удерживая Shift, и выбрать в контекстном меню Run as different user. Того же эффекта можно достичь утилитой runas.exe и командлетом Start-Process с параметром -Verb RunAs. Но во всех этих случаях мы получаем функциональность, аналогичную возможностям утилиты su, поэтому нам потребуется передать пользователю пароль от привилегированной учетной записи.

Совсем недавно в Microsoft объявили о релизе утилиты sudo для Windows, которая в отличие от runas поддерживает запуск программ из-под администратора с применением механизма UAC (User Account Control) для верификации запроса, т. е. без запроса пароля. Превратится ли она в продвинутый способ выполнения команд с повышенными привилегиями — будем посмотреть.

Политики повышения привилегий FreeIPA

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

Например, вызовом следующей команды обычный пользователь может установить приложение htop, если ему разрешено запускать утилиту apt через sudo:

iivanov@dc-1:~$ sudo apt install htop

Правила SUDO можно определить не только в локальном файле /etc/sudoers, но и централизованно через службу каталога, создавая дополнительный слой авторизации, с помощью которого можно разрешить определенным пользователям на конкретных хостах выполнять отдельные команды с повышенными привилегиями.

В то время, как правила HBAC реализованы на уровне PAM-стека, правила SUDO проверяются непосредственно внутри утилиты sudo. Но обратите внимание, что утилита sudo в начале своей работы запускает PAM-контекст, поэтому, для того чтобы пользователь смог воспользоваться своими SUDO-правилами, ему нужно предоставить доступ в том числе к HBAC-службе sudo.

Мы уже рассматривали подробно утилиту sudo, ее правила и лучшие практики их использования в Модуль 10. Система аутентификации PAM и управление правами SUDO курса Часть 1. Astra Linux . Поэтому не будем подробно останавливаться на этом и сразу перейдем к особенностям работы правил SUDO в домене.

Список источников правил утилита sudo получает через библиотеку службы имен (Name Service Switch, NSS), настройки которой находятся в файле /etc/nsswitch.conf. Как мы знаем, в операционных системах Linux через этот механизм настраиваются источники для получения информации о пользователях, группах, DNS-записях и многом другом. Основные вызовы NSS реализованы в библиотеке libc, а та уже, в свою очередь, выполняет обращение к необходимым бэкендам, как показано на рис. рис. 253.

рис. 253 Архитектура диспетчера службы имен (Name Service Switch, NSS)

После установки freeipa-client в файле /etc/nsswitch.conf можно найти строку с настройкой базы данных /etc/sudoers. По умолчанию правила сначала берутся из локального файла, а затем через модуль sss, который отвечает за взаимодействие с LDAP-каталогом через службу SSSD.

admin@dc-1:~$ cat /etc/nsswitch.conf | grep sudoers
sudoers: files sss

Поддержка каталогов появилась в sudo c выходом модуля ldap для nss в 2004 году. Источником правил для модуля служили записи из DN «ou=sudoers,{basedn}=имя,{basedn}=домена,{basedn}=организации».

Модуль sudo работал с примитивной схемой хранения данных, которая повторяла синтаксис локального файла sudoers, игнорируя доступную в каталоге нормализацию данных, например, в части пользователей, групп и хостов. Поэтому при реализации поддержки правил SUDO разработчики FreeIPA создали новую схему, лишенную указанных недостатков. Информация о правилах SUDO во FreeIPA хранится в DN «cn=sudorules,cn=sudo,{basedn}=имя,{basedn}=домена,{basedn}=организации», и служба SSSD берет данные напрямую из этой ветки каталога.

Однако для обеспечения совместимости со старым модулем ldap служба каталога FreeIPA с помощью плагина Compat автоматически конвертирует настройки правил в старый формат, как показано на рисунке рис. 254. Например, если для правила в cn=sudorules установить ipaEnabledFlag=FALSE, то соответствующая запись в ou=sudoers будет автоматически удалена, но стоит вернуть атрибуту значение TRUE, и запись будет создана повторно.

рис. 254 Два источника правил SUDO для разных клиентов

Служба SSSD кэширует правила SUDO, что дает пользователям возможность повышать свои привилегии, даже если они не подключены к домену прямо сейчас. По умолчанию время кэширования составляет 5400 секунд, и для немедленного применения правил на клиентской машине можно выполнить удаление кэша, например, командой sudo sssctl cache-remove.

Настройка политики повышения привилегий

Создание правил SUDO

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

Учитывая, что пользователи и хосты уже есть в домене, настройку правил следует начать с создания команды. Сделать это можно, например, через портал управления ALD Pro на странице Групповые политики ‣ Политики повышения привилегий ‣ Команды Sudo, см. рис. 255, или из командной строки:

admin@dc-1:~$ kinit admin
admin@dc-1:~$ ipa sudocmd-add '/usr/bin/systemctl' --desc='Запуск systemctl'

Где:

• Команда ipa sudocmd-add – создает в системе новую команду SUDO.

  • Параметр /usr/bin/systemctl – полный путь к утилите. Название команды может содержать разрешенные параметры вызова.

  • Ключ --desc – позволяет задать описание команды.

рис. 255 Создание новой команды SUDO

Внимание

В названии команды можно использовать символы «a-z, A-Z, 0-9, -_./~» и пробелы (если только не в начале и конце строки).

Таким образом вы можете определить не только путь к утилите, но и параметры, с которыми вы разрешаете ее запускать. Например, можно разрешить только перезапуск службы sssd, если указать название команды как /usr/bin/systemctl restart sssd.service. В тоже время интерфейс ALD Pro версии 2.2.0 не позволяет использовать символ «=» в названии правил SUDO. Если вам вдруг понадобятся такие команды, вы всегда сможете их создать через командную строку или веб-интерфейс FreeIPA.

После того, как команда готова, нужно создать правило SUDO и назначить с помощью этого правила команду на пользователей и компьютеры из веб-интерфейса, см. рис. 256, или из командной строки:

admin@dc-1:~$ ipa sudorule-add 'systemctl'
admin@dc-1:~$ ipa sudorule-mod 'systemctl' --usercat=all
admin@dc-1:~$ ipa sudorule-mod 'systemctl' --hostcat=all
admin@dc-1:~$ ipa sudorule-add-allow-command 'systemctl' --sudocmds='/usr/bin/systemctl'

Где:

• Команда ipa sudorule-add — создает правило SUDO;

• Команда ipa sudorule-mod — изменяет правило SUDO;

  • Ключ --usercat — задает категорию пользователей, которой разрешено использование данного правила.

  • Ключ --hostcat — задает категорию хостов, на которых разрешено использование данного правила.

• Команда ipa sudorule-add-allow-command — добавляет команду в правило SUDO.

рис. 256 Создание правила SUDO

Пройдем по основным параметрам правила:

• Раздел Основные:

  • Порядок sudo (необязательный параметр) – целое число, которое определяет очередность выполнения правил. Чем больше значение, тем позже обрабатывается правило, а значит оно может переопределить те правила, которые стоят перед ним.

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

    Если у правила одновременно заданы и разрешающие, и запрещающие команды, то сначала обрабатываются разрешающие.

  • Описание – необязательный комментарий к правилу.

  • Состояние – переключатель определяет, включено правило или нет.

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

• Вкладка Параметры:

  С помощью параметров можно изменить поведение утилиты для ее тонкой настройки. Ниже приведено несколько наиболее востребованных параметров:

  • authenticate – с помощью этого флага можно обязать пользователей вводить пароль при выполнении команды через sudo. Параметр включен по умолчанию, и для отмены требования по вводу пароля его следует отключить, для чего нужно поставить восклицательный знак перед названием параметра «!authenticate».

  • passwd_tries – задает количество попыток ввода пароля, прежде чем sudo завершит работу и зарегистрирует ошибку. Задается в виде переменной, по умолчанию passwd_tries=3.

  • timestamp_timeout – задает количество минут, которое должно пройти перед тем, как sudo повторно запросит пароль. Если установить таймаут равным 0, то утилита будет запрашивать пароль всегда, если установить отрицательное значение, таймаут будет отключен и введенный ранее пароль будет храниться бессрочно. По умолчанию таймаут составляет 15 минут.

  Информацию по остальным параметрам можно найти в man sudoers. Значения по умолчанию, с которыми утилита sudo была скомпилирована, можно узнать, вызвав команду sudo с ключом -V под суперпользователем, например, sudo sudo -V.

Пользователи, компьютеры и команды назначаются так же, как для правил HBAC. На вкладке «Запуск от имени» вы можете указать пользователей и группы, от имени которых пользователь сможет запускать указанные команды, используя ключи -u и -g. Для того чтобы разрешить действовать от суперпользователя, следует оставить эту вкладку незаполненной.

Внимание

Обратите внимание, что в интерфейсе ALD Pro в версиях 2.2.0 и 2.3.0 в настройках правила не получится задать значение «любая команда». Если вы захотите не ограничивать пользователя списком команд, воспользуйтесь командой ipa sudorule-mod 'Имя_правила' --cmdcat=all или веб-интерфейсом FreeIPA.

Проверка правил SUDO

Результирующий набор правил SUDO, который фактически применяется для конкретного пользователя на конкретном хосту, можно получить вызовом на целевой машине команды sudo с ключами -l (строчная L) и -U:

admin@dc-1:~$ sudo -l -U admin
Matching Defaults entries for admin on dc-1:
    env_reset, mail_badpass,
secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin,

secure_path=/usr/lib/parsec/bin\:/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin

User admin may run the following commands on dc-1:
    (ALL : ALL) ALL
    (root) ALL

В отладке правил вам также поможет журнал утилиты sudo, для включения которого потребуется создать файл /etc/sudo.conf (по умолчанию файла не существует) со следующим содержимым:

Debug sudo /var/log/sudo_debug.log all@debug
Debug sudoers.so /var/log/sudo_debug.log all@debug

В файле sudo_debug.log будет представлена информация о пользователе и среде окружения в момент запуска команды sudo:

sudo[22259] settings: debug_flags=all@debug
sudo[22259] settings: run_shell=true
sudo[22259] settings: progname=sudo
sudo[22259] settings: network_addrs=192.0.2.1/255.255.255.0
fe80::250:56ff:feb9:7d6/ffff:ffff:ffff:ffff::
sudo[22259] user_info: user=user_name
sudo[22259] user_info: pid=22259
sudo[22259] user_info: ppid=22172
sudo[22259] user_info: pgid=22259
sudo[22259] user_info: tcpgid=22259
sudo[22259] user_info: sid=22172
sudo[22259] user_info: uid=10000
sudo[22259] user_info: euid=0
sudo[22259] user_info: gid=554801393
sudo[22259] user_info: egid=554801393
sudo[22259] user_info:
groups=498,6004,6005,7001,106501,554800513,554801107,554801108,554801393,554801503,554802131,554802244,554807670
sudo[22259] user_info: cwd=/
sudo[22259] user_info: tty=/dev/pts/1
sudo[22259] user_info: host=client
sudo[22259] user_info: lines=31
sudo[22259] user_info: cols=237

С помощью этой информации можно получить ответы на ряд вопросов:

• Какой источник информации использовался для извлечения правил SUDO:

sudo[22259] <- sudo_parseln @ ./fileops.c:178 := sudoers: files sss

• Со следующей строки включается в работу плагин SSSD:

sudo[22259] <- sudo_sss_open @ ./sssd.c:305 := 0

• Как много правил было получено от службы SSSD:

sudo[22259] Received 3 rule(s)

• Подошли эти правила или нет:

sudo[22259] sssd/ldap sudoHost 'ALL' ... MATCH!
sudo[22259] <- user_in_group @ ./pwutil.c:1010 := false

Вы можете также включить повышенный уровень логирования в настройках /etc/sssd/sssd.conf и перезапустить службу.

[domain/domain_name]
debug_level = 8
...
[sudo]
debug_level = 8

При использовании утилиты sudo будет создан файл журнала /var/log/sssd/sssd_domain_name.log, с помощью которого можно будет получить информацию по ряду вопросов:

• Как много правил было получено от службы SSSD:

[sdap_sudo_refresh_load_done] (0x0400): Received 4-rules rules

• Какие правила служба SSSD загрузила с сервера:

[sssd[be[LDAP.PB]]] [sysdb_save_sudorule] (0x0400): Adding sudo rule demo-name

• Находились ли подошедшие правила в кэше:

[sdap_sudo_refresh_load_done] (0x0400): Sudoers is successfully stored in cache

• Какой фильтр был использован для загрузки правил с сервера:

[sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with
[(&(objectClass=sudoRole)(|(!(sudoHost=*))(sudoHost=ALL)(sudoHost=client.example.com)(sudoHost=client)(sudoHost=192.0.2.1)(sudoHost=192.0.2.0/24)(sudoHost=2620:52:0:224e:21a:4aff:fe23:1394)(sudoHost=2620:52:0:224e::/64)(sudoHost=fe80::21a:4aff:fe23:1394)(sudoHost=fe80::/64)(sudoHost=+*)(|(sudoHost=*\\*)(sudoHost=*?*)(sudoHost=*\2A*)(sudoHost=*[*]*))))][dc=example,dc=com]

Используйте этот фильтр, чтобы выполнить поиск в базе LDAP-каталога напрямую:

admin@dc-1:~$ ldapsearch -x -D "cn=Directory Manager" -W \
 -H ldap://dc-1.ald.company.lan -b dc=ald,dc=company,dc=lan '(objectClass=sudoRole)'

Собеседник (Responder) службы SSSD регистрирует свои события в файле журнала /var/log/sssd/sssd_sudo.log, с помощью которого можно ответить на следующие вопросы:

• Как много правил было получено от службы SSSD:

[sssd[sudo]] [sudosrv_get_sudorules_from_cache] (0x0400): Returning 4-rules rules for
[user@idm.example.com]

• Какой фильтр был применен при поиске кэша SSSD:

[sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with
[(&(objectClass=sudoRule)(|(sudoUser=ALL)(sudoUser=user)(sudoUser=#10001)(sudoUser=%group
-1)(sudoUser=%user)(sudoUser=+\*)))]

Для поиска извлечения правил из кэша используйте команду ldbsearch из состава пакета ldb-tools:

admin@dc-1:~$ ldbsearch -H /var/lib/sss/db/cache_domain_name.ldb -b cn=sysdb '(&(objectClass=sudoRule)...)'

Групповые политики

Групповые политики Windows

Первые политики появились в Windows еще в 95-й версии, и создать их можно было с помощью редактора Poledit. Данная операционная система по умолчанию не предоставляла безопасного окружения (пользователи могли входить в систему без паролей, менять многие системные настройки и вообще ни в чем себе не отказывать), поэтому для устранения указанной проблемы и был создан этот дополнительный инструмент.

В дальнейшем технологию политик переняли в NT4, и окончательно она была переосмыслена в Windows 2000 для Active Directory. С тех пор технология поддерживается всеми операционными системами и за прошедшую четверть века нисколько не потеряла своей актуальности.

Локальные политики

Политики бывают локальными и доменными. Локальные политики появились еще в NT 4.0 и представляют собой просто папки с файлами, внутри которых описаны значения параметров:

• Windows\System32\GroupPolicy\Machine — настройки компьютера;

• Windows\System32\GroupPolicy\User — настройки пользователя;

• Windows\System32\GroupPolicyUsers — настройки для конкретных пользователей и групп пользователей, если используются множественные локальные групповые политики (англ. Multiple Local Group Policy Objects, MLGPO). Данный механизм появился с Windows Vista.

Параметры хранятся в файлах Registry.pol (от англ. policy), максимальный размер этого файла c Windows 2012 увеличен до 100МБ, но это с большим запасом, т.к. до этого хватало и 64 Кб. Файлы Registry.pol содержат бинарные данные, но так как в них много строк unicode, в них можно «заглянуть» даже простым блокнотом.

Первые 4 байта (PReg) определяют сигнатуру, а следующие за ними 4 байта определяют версию. Версия увеличивается на единицу при каждом изменении GPO, и это значение необходимо для сверки данных, находящихся в LDAP-каталоге, локальном кэше и общей сетевой папке. После заголовка идет тело документа со значениями параметров, которые представляют собой просто разделы реестра Windows, которые необходимо доставить и установить на клиенте, поэтому файл называется реестром (англ. Registry). Например, это может быть параметр со ссылкой на файл для установки обоев рабочего стола.

Для построения пользовательского интерфейса редактор групповых политик использует так называемые административные шаблоны, которые представляют собой специальные XML-файлы *.admx. Если на компьютере установлены инструменты администрирования групповых политик, то эти файлы будут находиться в папке C:\Windows\PolicyDefinitions\, но для удобства централизованного доступа к административным шаблонам метафайлы можно скопировать в каталог SYSVOL по адресу: \win.company.lan\SYSVOL\win.company.lan\Policies\PolicyDefinitions. В этом случае интерфейс будет открываться чуть дольше, но зато одинаково на всех компьютерах.

Разработчики стороннего программного обеспечения могут создавать свои собственные административные шаблоны групповых политик для использования штатного механизма централизованного конфигурирования через изменение параметров реестра Windows. Например, так поступают разработчики MS Office, Adobe Reader, Google Chrome и др.

За применение групповых политик на серверах и рабочих станциях, начиная с Windows Vista, отвечает отдельная служба «Клиент групповых политик» (от англ.Group Policy Service Client, GPSVC), ранее эту задачу возлагали на WinLogon. Если клиентская служба групповой политики будет остановлена, то настройки применяться не будут, поэтому в целях безопасности права доступа по умолчанию настроены таким образом, что даже администратору запрещено ее останавливать, см. рис. 257. Текущие права доступа вы можете посмотреть командой sc.exe sdshow gpsvc.

рис. 257 Действия по управлению службой Group Policy Client, доступные администратору

Таким образом, локальная политика включает следующие компоненты: шаблон локальной групповой политики со значением параметров и административные шаблоны для их редактирования. Взаимосвязь компонентов показана на рис. рис. 258.

рис. 258 Компоненты локальной политики Windows

Доменные групповые политики

Групповые политики появились в Windows 2000 с выходом Active Directory и представляют собой множество правил для настройки рабочего окружения, которые группируются в так называемые объекты групповой политики (от англ. Group Policy Object, GPO), см. рис. 259.

рис. 259 Объект групповой политики Default Domain Policy

Как можно заметить, параметры представлены в двух секциях: настройки компьютера (англ. Computer Configuration) и настройки пользователя (англ. User Configuration), см. рис. 260.

рис. 260 Параметры пользователя и компьютера

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

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

Каждый объект групповой политики включает в себя два компонента:

• Контейнер групповой политики (Group Policy Container, GPC) — это запись в LDAP-каталоге, которая определяет имя объекта, версию (порядковый номер изменений), ссылку на шаблон групповой политики gPCFileSysPath на диске и т.д.

  Например, контейнер GPO «Default Domain Policy» в домене win.company.lan можно найти в записи, см. рис. 261: CN={31B2F340-...FB984F9},CN=Policies,CN=System,DC=win,DC=company,DC=local

• Шаблон групповой политики (Group Policy Templates, GPT) — это папка на сетевом диске, в которой хранятся значения параметров по аналогии с папкой GroupPolicy локальных политик. Например, шаблон GPO «Default Domain Policy» в домене win.company.lan можно найти в \win.company.local\SYSVOL\win.company.local\Policies{31B2F340-...FB984F9}, см. рис. 261.

рис. 261 Контейнер групповой политики Default Domain Policy

Примечание

• Default Domain Policy: {31B2F340-016D-11D2-945F-00C04FB984F9}

• Default Domain Controller Policy: {6AC1786C-016F-11D2-945F-00C04FB984F9}

рис. 262 Шаблон групповой политики Default Domain Policy

При назначении объекта групповой политики на структурное подразделение в записи LDAP-каталога, соответствующей этому подразделению, создается атрибут gPLink, который является ссылкой на контейнер GPO, см. рис. 263.

Например, в свойствах домена win.company.lan есть gPLink со значением: [LDAP://CN={31B2F340-..B984F9},CN=Policies,CN=System,DC=win,DC=company,DC=lan;0]

рис. 263 Ссылка на контейнер объекта групповой политики Default Domain Policy

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

рис. 264 Компоненты доменной групповой политики Active Directory

Область действия групповых политик, назначенных на домен, сайт или структурное подразделение можно сузить с помощью WMI-фильтров (Windows Management Instrumentation), которые позволяют задать дополнительные условия отбора целевых объектов на SQL-подобном языке WQL (WMI Query Language). Обычно эта технология используется в ситуациях, когда пользователи и компьютеры находятся в общем списке, а не в выделенном подразделении. Этот механизм крайне удобен, если нужно применить политику в зависимости от версии ОС, ее сетевых настроек, наличия определенного установленного ПО и других условий.

Кроме WMI-фильтров область действия политик можно сужать еще и через права доступа. Загрузка параметров, назначенных на компьютер, осуществляется из-под учетной записи компьютера, а загрузка параметров, назначенных на пользователя, соответственно, из-под учетной записи пользователя. Поэтому, если у компьютера/пользователя не будет соответствующих прав на чтение GPO, то служба GPSVC не сможет получить параметры объекта, и они не будут применены в системе. Права доступа назначаются через делегирование с помощью списков доступа (англ. ACL, Access Control List).

Когда мы изменяем права доступа на вкладке делегирования или через фильтры безопасности (англ. security filter), консоль управления выставляет соответствующие ACL в LDAP-каталоге и на сетевом диске. Набор привилегий в каталоге и на диске разный, но это не мешает достигнуть необходимого результата. Администратор может делегировать не только права на чтение, но и права на редактирование GPO, что дает гибкость в вопросах администрирования.

В классической клиент-серверной архитектуре доставка изменений до клиента может быть организована тремя способами:

• Метод опроса (англ. pull) — это когда клиент периодически опрашивает сервер о наличии каких-либо изменений. Эта модель основана на классическом подходе запрос/ответ (англ. request/response).

• Метод проталкивания (англ. push) — это когда клиент и сервер меняются местами, и уже сервер связывается с клиентом, чтобы передать ему какие-либо изменения.

  В этом случае сервер должен знать IP-адрес клиента и иметь к нему доступ по сети, что невозможно при размещении клиентов за NAT-шлюзом.

• Метод длинных опросов (англ. long poll) — это когда клиент подключается к серверу, после чего они продолжают удерживать соединение, чтобы у сервера была возможность оперативно передавать клиенту новые сообщения.

  Эта модель основана на веб-сокетах (англ. WebSocket), и ее используют, например, мессенджеры, такие как Telegram.

Учитывая, что в домене могут быть сотни серверов, а рабочие станции могут длительное время находиться в выключенном состоянии или вообще эксплуатироваться вне офиса, метод опроса видится наиболее экономичным способом доставки изменений до клиента. Поэтому в MS AD ответственность за извлечение информации о групповых политиках из домена возлагается на клиента, а точнее на его службу GPSVC, которая выполняет процедуру опроса с периодичностью один раз в 90 минут.

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

Информацию об участии пользователя/компьютера в организационной структуре, релевантные объекты групповой политики и их версии компьютер извлекает по LDAP-протоколу. Шаблоны групповой политики, в которых содержатся значения параметров, компьютер извлекает по SMB. Для отладки групповых политик администратор может отправить команду на принудительное обновление параметров групповой политики конкретному компьютеру через консоль GPMC или командлет Invoke-GPUpdate.

рис. 265 Протоколы, используемые технологией групповых политик для доставки информации до клиента

Механизм репликации

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

• Репликация LDAP-каталога – используется для согласования изменений в контейнерах групповых политик. В этом случае применяются протоколы RPC (135/TCP) и SMTP (25/TCP).

• Репликация папки SYSVOL – используется для согласования изменений в шаблонах групповых политик. В этом случае применяется протокол DFS-R (5722/TCP).

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

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

Механизмы наследования и суммирования параметров

Порядок суммирования параметров групповых политик иногда обозначают аббревиатурой LSDOU, так как сначала применяются локальные политики (L), затем политики сайта (S), домена (D) и в завершение политики организационных подразделений (OU). Таким образом, параметры, назначенные на организационные подразделения, всегда превалируют над параметрами локальных политик.

При назначении GPO на структурное подразделение в область его действия попадают пользователи и компьютеры всех нижестоящих подразделений. На схеме рис. 267 приведен пример, в соответствии с которым целевой компьютер попадает в область действия всех GPO, начиная с ГПО-1 и заканчивая ГПО-8.

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

При этом, чем ближе GPO по иерархии к пользователю/компьютеру, тем позже будут применяться параметры этого объекта, поэтому они смогут переопределить ранее установленные значения. На приведенном ранее примере параметр ГПО-8 сможет переопределить значения, установленные параметром из ГПО-1.

Однако стандартный порядок наследования можно изменить, если поставить в настройках структурного подразделения флаг «Блокировать наследование» (англ. Block Inheritance). Это позволит отменить наследование GPO, назначенных на вышестоящие родительские подразделения. Например, на рисунке рис. 268 показан пример, в соответствии с которым целевой компьютер не попадает в область действия ГПО-1 и ГПО-2, т. к. на OU1 установлен запрет наследования.

рис. 268 Иллюстрация работы блокировки наследования GPO для структурного подразделения

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

Обойти блокировку наследования можно с помощью флажка «Наследовать принудительно» (англ. enforced), который можно установить при назначении GPO на структурное подразделение. Более того, параметры объектов, отмеченных флажком Enforced, суммируются в отдельном цикле после суммирования параметров обычных GPO, поэтому они могут переопределить ранее установленные значения. Например, на рисунке :aldpro_mod6_image33 показан пример, в соответствии с которым целевой компьютер попадает в область действия ГПО-1, несмотря на то, что для OU1 установлен запрет наследования.

рис. 269 Иллюстрация работы флага принудительного наследования

Отладка групповых политик

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

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

Для настройки и отладки групповых политик в домене администратор располагает следующими инструментами:

• Мастер моделирования групповой политики в GPMC — использует алгоритм службы GPSVC, чтобы спрогнозировать, какие параметры будут применены для конкретного пользователя на конкретном компьютере в заданных условиях (Resultant Set of Policy, RSOP). Отчет выводится в формате HTML-документа.

• Утилита gpresult.exe — показывает фактический результат применения параметров групповой политики на конкретном компьютере. Результаты можно вывести в формате HTML-отчета.

• Утилита gpupdate — позволяет форсировать применение параметров групповой политики, чтобы не дожидаться следующей итерации. Довольно часто используется с ключом /force, который позволяет повторно применить все параметры, даже если они не изменились с последнего применения.

Обычно сценарий настройки нового объекта выглядит следующим образом:

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

• Для проверки настроек администратор многократно выполняет в целевой системе команду gpupdate /force и сверяет полученный результат со своими ожиданиями.

• После настройки объекта групповой политики администратор назначает его на целевое структурное подразделение.

Такие инструменты, как RSOP и GPResult, используются обычно для отладки, когда нужно понять, почему та или иная настройка фактически не применилась к конкретной категории пользователей или компьютеров.

Групповые политики ALD Pro

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

Реализованы политики FreeIPA очень хорошо, но их ни разу недостаточно. Поэтому команда ALD Pro выполнила интеграцию продукта с системой конфигурирования SaltStack, что позволило обеспечить централизованное управление настройками любых операционных систем и приложений в стиле групповых политик Microsoft.

Локальные политики

В операционной системе ALSE есть очень удобный инструмент для управления локальной политикой безопасности fly-admin-smc, с помощью которого можно управлять локальными пользователями и группами, настроить основные параметры безопасности, мандатного доступа, аудита, отчуждаемых носителей, см. рис. 270.

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

рис. 270 Управление локальной политикой безопасности ALSE

Система ALD Pro не предлагает какой-либо реализации локальных политик и не резервирует изменяемые конфигурационные файлы, поэтому для возможности вернуться к исходным значениям вы можете включить версионирование всей папки /etc/ с помощью обычного Git или более специализированного приложения etckeeper.

Доменные групповые политики

Групповые политики ALD Pro во многом похожи на групповые политики AD. Перечислим основные особенности:

• Параметры группируются в объекты групповой политики (GPO). В рамках каждого GPO есть две секции параметров — одна для формирования окружения компьютеров и вторая для окружения пользователей, см. рис. 271.

• Значения параметров (шаблоны GPO) хранятся в LDAP-каталоге и извлекаются по LDAP-протоколу, то есть обычные файлы и SMB-протокол не используются.

• За извлечение параметров из LDAP-каталога, их суммирование и применение отвечает служба salt-minion-standalone. Для взаимодействия с каталогом служба использует учетную запись компьютера из файла /etc/krb5.keytab.

• Для применения параметров на рабочих станциях автономная служба salt-minion-standalone использует Salt-скрипты, тексты которых хранятся также в LDAP-каталоге.

• Объекты групповой политики назначаются на организационные подразделения, которые являются собственной доработкой продукта ALD Pro, т.к. в службе каталога FreeIPA этой возможности изначально нет.

• Назначить GPO на сайт в настоящий момент невозможно. Для назначения GPO на домен используется корневое подразделение организационной структуры.

рис. 271 Параметры компьютеров объекта групповой политики ALD Pro

В основе механизма групповых политик ALD Pro лежит Salt — система управления конфигурациями и удаленного выполнения операций с открытым исходным кодом, написанная на языке Python. Система работает по модели «издатель — подписчик», см. рис. 272, поэтому базовыми компонентами архитектуры являются:

• Мастер (издатель) — это сервер, выполняющий централизованное управление рабочими станциями.

• Миньоны (подписчики) — это рабочие станции или серверы, выступающие в качестве клиентов по отношению к Мастеру и принимающие от Мастера команды на удаленное конфигурирование.

• Шина данных — это система для передачи сообщений на базе ZeroMQ.

  Шина работает на Мастере и реализует модель длинных опросов (англ. long poll). Миньоны устанавливают с Шиной постоянное соединение по порту TCP/4505 (порт издателя, publisher) для получения заданий на конфигурирование от Мастера.

  Кроме постоянного соединения Миньоны периодически подключаются к Шине по порту TCP/4506 (порт сервера запросов, request server) для загрузки необходимых файлов и отправки отчетов о выполнении заданий.

рис. 272 Классическая архитектура Salt

В продукте ALD Pro до версии 2.2.0 групповые политики использовали классическую архитектуру Salt: служба Salt-Minion рабочей станции подключалась к Salt-Master на контроллере домена, забирала справочник Pillar с результирующим набором параметров, загружала все необходимые salt-скрипты и применяла указанные параметры.

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

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

• Аутентификация по ключу, которую использует Salt для установления соединения, требует ощутимо больше ресурсов. Это очень заметно в первые минуты после перезапуска службы Salt-Master.

• Удержание нескольких тысяч сетевых соединений по модели long poll требует слишком много ресурсов.

Для того чтобы достичь показателя в 10к рабочих станций на один контроллер домена, в части групповых политик мы уже отказались от использования Мастера и перешли к модели Standalone Minion. Весь программный код, отвечающий за наследование и суммирование параметров групповых политик, сейчас выполняется на стороне клиента, а к контроллеру он ходит только за обновлением данных, см. рис. 273.

В части установки и настройки подсистем мы еще продолжаем использовать классическую схему Мастер-Миньон, но окончательный отказ от Мастера планируется уже в 2.4.0. До выхода этой версии вы можете значительно снизить нагрузку с контроллера, если на обычных рабочих станциях через групповую политику «Связь Salt master-minion» выключите обычный Salt-Minion.

рис. 273 Компоненты доменной групповой политики ALD Pro

Скрипты групповых политик находятся в каталоге /srv/salt/standalone/roots/states/policies/. В случае коробочных параметров они доставляются через установку и обновление deb-пакетов программного продукта, а в случае дополнительных параметров загружаются через LDAP.

admin@dc-1:~$ sudo tree -L 2 /srv/salt/standalone/roots/states/policies/
/srv/salt/standalone/roots/states/policies/
├── audit-policies
│   ├── files
│   └── init.sls
├── host-policies
│   ├── init.sls
│   ├── rbta_ldap_auth_fast
│   ├── rbta_ldap_crontab
│   ├── rbta_ldap_date_time_h
│   ...
│   ├── rbta_ldap_printers
│   ├── rbta_ldap_quotas
│   ├── rbta_ldap_security_policy
│   └── rbta_ldap_system_alternatives
├── sw-policies
│   ├── init.sls
│   └── README.md
├── update-policy.sls
└── user-policies
   ├── init.sls
   ├── rbta_ldap_autostart
   ├── rbta_ldap_date_time_u
   ...
   ├── rbta_ldap_power_management
   ├── rbta_ldap_quick_launch
   ├── rbta_ldap_start_menu
   └── rbta_ldap_windows_settings

Механизм групповых политик ALD Pro заимствует из MS AD также несколько очевидных способов повышения производительности:

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

• Параметры групповых политик извлекаются из LDAP-каталога только в том случае, если версия в локальном кэше не совпадает с версией GPO из каталога.

Механизм репликации

Информация по групповым политикам ALD Pro находится в LDAP-каталоге, поэтому реплицируется между контроллерами домена в штатном порядке в рамках установленной топологии.

Мы отказались от использования файлов, т.к. производительность современных серверов позволяет передавать всю необходимую информацию по LDAP-протоколу. Довольно долгое время файлы Registry.pol были не больше 64Кб, а записи размером до 100Кб хранить в каталоге считалось допустимым даже 20 лет назад.

Механизмы наследования и суммирования параметров

В части наследования и суммирования параметров система ALD Pro заимствует подходы, которые применяются в MS AD:

• Простые параметры суммируются так же, как обычные параметры групповых политик AD, поэтому, чем ближе будет GPO по иерархии к пользователю/компьютеру, тем позже будут применяться параметры этого объекта, поэтому они смогут переопределить ранее установленные значения.

• Составные параметры суммируются так же, как Предпочтения групповых политик (Group Policy Preferences), поэтому salt-скрипт через pillar получает таблицу атрибутов, где каждая строка соответствует набору атрибутов данного параметра из отдельно взятого объекта групповой политики. Скрипт должен будет самостоятельно удалить дубликаты строк, руководствуясь бизнес-логикой параметра групповой политики.

Однако есть некоторые отличия:

• В соответствии с порядком наследования LSDOU в системе ALD Pro в настоящий момент можно назначать GPO только на домен и организационные подразделения, причем под доменом подразумевается корневое подразделение в иерархии. Локальных политик нет, и назначить GPO на сайт пока не представляется возможным.

• Групповые политики ALD Pro не поддерживают технологии WMI-фильтров и не позволяют назначать права доступа на отдельные GPO, поэтому в настоящий момент сузить область действия GPO не представляется возможным.

• В настоящий момент пока еще нет возможности влиять на порядок наследования через установку таких флажков, как «Блокировать наследование» (англ. Block Inheritance) и «Наследовать принудительно» (англ. Enforced). Эти функции появятся в версии 2.4.0, выход которой запланирован на ноябрь 2024 года.

Настройка групповой политики

Давайте с помощью групповых политик запретим локальным пользователям вход в систему.

В домене MS AD для управления паролями локальных пользователей используется специальное решение LAPS (Local Administrator Password Solution), а для ALD Pro его планируется разработать только в 2025 году, поэтому, пока оно недоступно, заблокировать локальным пользователям вход будет намного проще, чем следить за их паролями вручную.

1. Перейдем на страницу Групповые политики ‣ Групповые политики и создадим новый объект групповой политики, нажав соответствующую кнопку.

2. До первого сохранения объекта нам доступна только вкладка Основное, где требуется задать имя объекта и описание. Введем следующие значения:

• Имя: Блокировка локальных учетных записей

• Описание: Политика запрещает локальным пользователям вход в систему

• И нажмем кнопку Сохранить

  

Теперь нам доступны для редактирования остальные вкладки:

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

• Параметры компьютеров – содержит параметры для настройки окружения компьютера.

• Параметры пользователей – параметры для настройки окружения пользователя.

• Подразделения – содержит список подразделений, на которые назначен объект групповой политики. На этой вкладке вы можете удалить назначение или назначить объект на дополнительные подразделения.

3. На вкладке Параметры компьютеров включим параметр из списка Безопасность ‣ Политика безопасности ‣ Политика локального входа, установим значение «no» и нажмем кнопку Применить

Примечание

Подробную справку о параметре групповой политики можно получить, если кликнуть по значку с символом вопроса, который расположен в правом верхнем углу карточки. Как вы можете заметить, значение «no» означает, что вход будет запрещен для всех категорий локальных пользователей, в том числе и по ssh.

Примечание

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

4. Перейдем на вкладку Подразделения и создадим новое назначение кнопкой + Добавить подразделение.

   

   Так как мы хотим применить объект групповой политики на весь домен, то выберем корневое подразделение «ald.company.lan» и нажмем кнопку Сохранить

   Обратите внимание на поле «Приоритет групповой политики». Это значение позволяет определить порядок применения параметров, если на одно и тоже организационное подразделение назначено несколько объектов групповой политики.

   

5. Файлы, которые используются для применения этого параметра, находятся в каталоге /srv/salt/standalone/roots/states/policies/host-policies/rbta_ldap_security_policy/.

   Скрипт init.sls заменяет содержимое файла /etc/parsec/parsec.conf шаблоном из файла local_login_policy/parsec.conf.j2, подставляя значение переменной login_policy.

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

admin@dc-1:~$ sudo salt-call state.apply gpupdate.build -c /srv/salt/standalone/config/ pillar='{"force": True}'
admin@dc-1:~$ sudo salt-call state.apply gpupdate.gp -c /srv/salt/standalone/config/
admin@dc-1:~$ cat /etc/parsec/parsec.conf

6. Если мы теперь попытаемся выполнить вход в систему локальным администратором, то получим ошибку от системы Parsec.

   

   Если вы захотите вернуть как было, то нужно установить параметр all, обновить параметры политики и перезагрузить хост.

Отладка групповых политик

Служба Salt-Minion-Standalone применяет параметры групповых политик по расписанию. Сразу после загрузки компьютера служба запускает отложенное задание, таймаут которого складывается из двух значений:

• Постоянная часть в 30 минут — определяет минимальный интервал между последующими обновлениями параметров групповых политик.

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

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

admin@pc-1:~$ sudo salt-call schedule.show_next_fire_time build_and_run_gp –c /srv/salt/standalone/config
local:
   ----------
   next_fire_time:
       2024-02-27T20:56:31
   result:
       True

Где:

• salt-call — утилита, которая используется для локального запуска функций Salt на Миньоне без участия Мастера.

• schedule.show_next_fire_time — имя модуля и его функции, которую нужно вызвать.

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

  Кроме обычных групповых политик в ALD Pro есть также политики установки программного обеспечения, правила аудита и политики обновления ALD Pro. Эти политики обновляются в рамках отдельных заданий, время выполнения которых можно получить с помощью параметров buld_and_run_swp, buld_and_run_audit и update_policy соответственно.

• -c /srv/salt/standalone/config – задает путь к каталогу с конфигурационными файлами службы Salt. Для обычного Миньона это /etc/salt, а нам требуется указать явно путь к файлам Standalone Миньона.

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

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

1. Сначала проверьте состояние службы salt-minion-standalone:

admin@pc-1:~$ systemctl status salt-minion-standalone.service
● salt-minion-standalone.service - The Salt Minion Standalone
Loaded: loaded (/lib/systemd/system/salt-minion-standalone.service; enabled; vendor
   preset: enabled)
   Active: active (running) since Tue 2024-07-02 06:47:01 MSK; 5h 6min ago
 Main PID: 17451 (python)
   Tasks: 3 (limit: 4915)
   Memory: 90.0M
   CPU: 52.690s
   CGroup: /system.slice/salt-minion-standalone.service
     ├─17451 /opt/rbta/venvs/aldpro-common/bin/python /usr/bin/salt-minion  -c /srv/salt/standalone/config
     └─17455 /opt/rbta/venvs/aldpro-common/bin/python /usr/bin/salt-minion -c
   /srv/salt/standalone/config

2. Затем обновите кэш с помощью функции gpupdate.build:

admin@pc-1:~$ sudo salt-call state.apply gpupdate.build -c /srv/salt/standalone/config \
pillar='{"verbose": True, "force": True}'

Где:

• state.apply — имя модуля и его функции, которую нужно вызвать. Модуль state и его функция apply позволяет выполнить указанный стейт.

• gpupdate.build — имя salt-скрипта, который нужно выполнить.

• pillar=“{…}“ - дополнительный параметр в формате json, с помощью которого в скрипт можно передать дополнительные переменные:

  • «verbose»: True — включает вывод на экран дополнительной информации;

  • «force»: True — требует удалить сохраненный ранее кэш и повторно запросить данные с контроллера домена.

После выполнения команды можно проверить содержимое файла с кэшем:

admin@pc-1:~$ sudo cat /opt/rbta/aldpro/standalone/gp-host_pillar.json
{"aldpro-users": {}, "aldpro-hosts": {"dc-1.ald.company.lan":
{"rbta_ldap_security_policy": {"rbta_ldap_security_policy\__local_login_policy":
{"rbta_ldap_security_policy\__local_login_policy\__policy": "no"}}}}}

3. В завершение с помощью функций gp, swp или audit вы можете обновить параметры для групповых политик, политик установки ПО или правил аудита соответственно.

admin@pc-1:~$ sudo salt-call state.apply gpupdate.gp -c /srv/salt/standalone/config
admin@pc-1:~$ sudo salt-call state.apply gpupdate.swp -c /srv/salt/standalone/config
admin@pc-1:~$ sudo salt-call state.apply gpupdate.audit -c /srv/salt/standalone/config

Вызов функции gpupdate.gp дает тот же результат, что и gpupdate /force в Windows.

Для отладки конкретного параметра компьютера используйте функцию state.apply, которой нужно передать имя скрипта из каталога /srv/salt/standalone/roots/states/policies/host-policies:

$ sudo salt-call state.apply <имя_скрипта> -c /srv/salt/standalone/config

Например, чтобы принудительно обновить параметр «Настройки сервиса сетевого времени Chrony», за который отвечает salt-скрипт из каталога rbta_ldap_date_time_h, требуется выполнить следующую команду:

admin@pc-1:~$ sudo salt-call state.apply rbta_ldap_date_time_h -c /srv/salt/standalone/config
...
[INFO    ] Completed state [/etc/chrony/chrony.conf] at time 07:59:15.835203
(duration_in_ms=1.932)
...

Для отладки конкретной групповой политики пользователя в функцию через справочник pillar в формате json нужно дополнительно передать имя пользователя, от имени которого мы хотим выполнить проверку:

$ sudo salt-call state.apply <имя_скрипта> -c /srv/salt/standalone/config \
pillar='{"user": "<имя_пользователя>"}'

Например, чтобы для пользователя admin принудительно обновить параметр «Переменная окружения», за который отвечает salt-скрипт из каталога rbta_ldap_env_vars_u, требуется выполнить следующую команду:

admin@pc-1:~$ sudo salt-call state.apply rbta_ldap_env_vars_u -c /srv/salt/standalone/config \
pillar='{"user": "admin", "force": True}'

Разработка дополнительных параметров

Создание дополнительного параметра

Для того чтобы в домене можно было организовать централизованное управление корпоративными приложениями, в системе ALD Pro реализована возможность создания дополнительных параметров групповых политик, которые решают ту же задачу, что и административные шаблоны Windows.

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

Чтобы создать дополнительный параметр, нужно перейти на страницу Управление доменом ‣ Доп. параметры групповых политик. Вы можете выбрать вкладку Параметры компьютеров или Параметры пользователей в зависимости от того, хотите ли вы создать параметр для настройки окружения пользователя или компьютера. Будьте внимательны, т.к. перенести параметр из одного раздела в другой после его создания не получится.

На вкладке Параметры компьютеров кликнем по узлу Дополнительные параметры и нажмем кнопку + Новый параметр

До первого сохранения параметра нам будет доступна только вкладка Основное. Заполним ее параметры:

• Название параметра: Источники программного обеспечения

  Это имя параметра, под которым вы его хотите видеть при редактировании объектов групповых политик на портале управления.

• Уникальный идентификатор: repo_source_list

  а полный его идентификатор rbta_ldap_custom_gp_host_repo_source_list, которые будет использоваться в качестве имени папки на диске и в salt-скриптах.

• Тип каталога: Параметр компьютерной групповой политики

  Определяет, относится ли данный параметр к настройкам компьютера или пользователя. Параметр недоступен для редактирования, его значение определяется автоматически в зависимости от того, с какой страницы вы перешли к созданию дополнительного параметра.

• Тип параметра: Составной параметр

  Он позволяет указать способ хранения атрибутов:

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

  • Составной параметр — задает таблицу атрибутов, где в каждой строке представлен типовой набор данных. Если продолжать пример с межсетевым экраном, то для настройки фильтрации может потребоваться разрешить входящие ssh-соединения, запретить исходящие smtp и т.п., поэтому такие настройки нужно реализовывать атрибутами «составного» параметра.

• Папка параметра: Дополнительные параметры

  Указывает раздел каталога, в котором будет представлен этот параметр.

• Назначение параметра (нужно вставить весь текст целиком):

Позволяет централизованно настраивать источники программного
обеспечения пакетного менеджера apt путем изменения
содержания файла /etc/apt/sources.list.d/repo_source.list

Атрибут "Источник" определяет строку в формате source.list:

deb <адрес_репозитория> <код_дистрибутива> <компонент1> <компонентN>

Где:

- deb - указывает на то, что репозиторий соответствует репозиторию бинарных файлов с предварительно скомпилированными пакетами. Для репозиториев с исходными кодами используют «deb-src».

- адрес репозитория - задает источник пакетов, у интернет-репозиториев адрес начинается с «http(s)://», адреса локальных репозиториев начинаются с «file:/». При добавлении репозитория с диска командой apt-cdrom add в файле появится строка «cdrom:[]/».

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

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

Условия использования компонентов следующие:

 - non-free - группа содержит пакеты, которые не соответствуют принципам свободного ПО, имеют патенты или другие юридические ограничения;

 - contrib - группа содержит пакеты, которые сами по себе соответствуют принципам свободного ПО, но зависят от пакетов из группы «non-free», т.е. не могут без них работать;

 - main - группа содержит пакеты свободного ПО, которые не зависят от пакетов из групп «contrib» и «non-free».

• Обязательно нажмите кнопку Сохранить.

На вкладке атрибутов нам нужно добавить один элемент:

• Название атрибута: «Источник» Название, под которым вы хотите видеть этот атрибут на карточке параметра.

• Уникальный идентификатор: «repo_source_item» Идентификатор атрибута, под которым значение атрибута будет доступно в пилларе для его использования из salt-скрипта.

• Описание: «Строка источника для apt» Краткие комментарии, которые помогут упростить поддержку этого атрибута в будущем, когда потребуется внести какие-либо изменения. Данная информация недоступна при настройке групповой политики, поэтому, если вы хотите дать подсказку администратору о возможных значениях этого атрибута, внесите эту информацию в описание параметра.

Осталось только написать скрипт параметра, с помощью которого его значения будут применяться на рабочих станциях.

Скрипты Salt похожи на PHP, в них текст перемежается императивными инструкциями языка программирования, по результату выполнения которых получается итоговый документ. За императивную часть отвечают инструкции шаблонизатора Jinja2, а декларативная часть задается по правилам Salt в YAML-подобном синтаксисе.

Далее мы подробно ознакомимся с синтаксисом Jinja, а пока просто перенесем текст скрипта:

{% set id = 'rbta_ldap_custom_gp_host_repo_source_list' %}
{% set node = salt['grains.get']('nodename') %}
{% set gpo = salt['pillar.get']('aldpro-hosts:' + node + ':' + id) %}
{% set filename = '/etc/apt/sources.list.d/repo_source.list' %}
{% set lines = [] %}

{% if gpo %}
    {%- for item in gpo %}
        {%- if item.repo_source_item.lower() != 'none' %}
            {%- do lines.append(item.repo_source_item) %}
        {%- endif %}
    {%- endfor %}
{% endif %}

{{ id }}:
    {%- if lines|length == 0 %}
        file.absent:
            - name: {{ filename }}
    {%- else %}
        file.managed:
            - name: {{ filename }}
            - user: root
            - group: root
            - mode: 644
            - contents:
            {%- for line in lines %}
                - {{ line }}
            {%- endfor %}
    {%- endif %}

Данный скрипт создает файл /etc/apt/sources.list.d/repo_source.list, настраивает права доступа и вносит в него указанные источники программного обеспечения.

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

Синтаксис скриптов

Императивные инструкции шаблонизатора Jinja

Скрипт «Hello world»

Создайте файл test.sls с простейшим Jinja-скриптом, чтобы проверить, как это работает:

$ mkdir ~/test_salt && cd ~/test_salt

Где:

• {% … %} — синтаксис для вставки инструкции языка шаблонизатора Jinja;

• do — оператор, который вызывает указанную функцию;

• salt.log.info — имя вызываемой функции;

• ("Hello world!") — параметр, передаваемый в функцию.

Выполните его с помощью утилиты salt-call:

$ sudo salt-call --local --file-root=. state.sls hello

Где:

• salt-call — утилита, которая используется для локального запуска функций Salt на Миньоне без участия Мастера;

• ключ --local — исключает обращение к мастеру для получения настроек;

• ключ --file-root — устанавливает текущую директорию «.» в качестве рабочего каталога;

• параметр state.sls — указывает, что нужно вызывать функцию sls из модуля state;

• параметр hello — задает имя скрипта (без расширения).

Результат вывода должен быть таким:

admin@dc-1:~$ mkdir ~/test_salt && cd ~/test_salt
admin@dc-1:~/test_salt$ echo '{% do salt.log.info("Hello world!") %}' → hello.sls
admin@dc-1:~/test_salt$ sudo salt-call --local --file-root=. state.sls hello
[INFO    ] Loading fresh modules for state activity
[INFO    ] Fetching file from saltenv 'base', \*\* done \*\* 'hello.sls'
[INFO    ]  Hello world!
local:

Summary for local
-----------
Succeeded: 0
Failed: 0
-----------
Total states run:      0
Total run time:    0.000 ms

Разметка Jinja

Инструкции языка Jinja внедряются с помощью фигурных скобок, см. табл. 23:

табл. 23 Выбор политики в зависимости от приоритета

Jinja	Аналог PHP	Комментарий
{% … %}	<? … ?>	Синтаксис для вставки инструкции языка шаблонизатора Jinja
{% print(…) %}	<? echo (…) ?>	Пример инструкции для вывода в документ по месту вызова значения выражения
{{ … }}	<?= … ?>	Краткий синтаксис для вывода в документ по месту вызова значения выражения
{# … #}	<?/* … */?>	Синтаксис для вставки комментариев средствами языка Jinja2

Для повышения читабельности кода управляющие структуры обычно оформляют отступами, но yaml-документы крайне чувствительны к пробелам, поэтому данный инструмент форматирования оказывается недоступен без применения специальных операторов подавления отступов, см. табл. 24. Чтобы убрать лишние пробелы и пустые строки вам нужно всего лишь поставить знак дефиса слева, справа или с обоих концов управляющего блока:

табл. 24 Специальные операторы подавления отступов

Jinja	Комментарий
{%-	Удаляет пробелы и пустые строки слева
-%}	Удаляет перенос текущей строки и переносит ее на предыдущую
{%- и -%}	Удаляет пробелы и пустые строки слева, в том числе перенос текущей строки, поэтому текст окажется в конце предыдущей строки

Работа с переменными

Переменные на языке Jinja задаются оператором set. Вам доступен широкий перечень типов данных: булевы, числовые, текстовые, списки, кортежи, словари:

{% set boolean_val = True %}
{% set int_val = 777 %}
{% set string_val = 'hello' %}
{% set list_val = ['h', 'e', 'l', 'l', 'o'] %}
{% set tuple_val = ('h', 'e', 'l', 'l', 'o') %}
{% set dict_val = { b: True, i: 777, s: 'hello') %}

При работе с числовыми переменными доступны обычные математические операторы:

{% set a = 5 %}
{% set b = 10 %}
{% set a = a + b %}
{% set b = a - b %}
{% set a = a - b %}

Конкатенация строк возможна как специальным оператором «~», который предварительно конвертирует все значения в строки, так и обычным оператором сложения «+»:

{% set a = 5 %}
{% set b = 10 %}
{% set c = a ~ b %}
{% set d = 'World' %}
{% set e = 'Hello, ' + d %}

Для выполнения более сложных преобразований над переменными вам доступно множество функций, которые можно применять как методы через точку или в стиле конвейеров bash через символ вертикальной черты, за что их также называют фильтрами:

{% set a = 'Hello'.upper() %}
{% set b = 'world' \| upper %}

Ветвления и циклы

Если выполнение набора команд должно зависеть от некоторого условия, то ветвление можно задать с помощью операторов if/elif/else/endif:

{% if ram >= 2048 %}
...
{% elif ram <= 4096 %}
...
{% else %}
...
{% endif %}

Циклы for являются аналогом конструкций типа foreach других языков программирования и предназначены для выполнения заданного набора инструкций применительно к каждому элементу из списка:

{% set users = ['ivanov', 'petrov', 'kuznetsov'] %}
{% for user in users %}
{% do salt.log.info(user.upper()) %}
{% endfor %}

Если вам нужно будет обработать данные словаря, воспользуйтесь методом items(), чтобы получить список его элементов:

{% set users = {'u1':'ivanov', 'u2':'petrov', 'u3':'kuznetsov'} %}
{% for id, user in users.items() %}
{% do salt.log.info(user.upper()) %}
{% endfor %}

Так как циклы Jinja работают только со списками, то для эмуляции обычных циклов со счетчиком вам нужно воспользоваться функцией range([min], max). Если передать этой функции один параметр, то будет сгенерирован список с указанным количеством элементов, нумерация которых будет начинаться с нуля. Если передать два числа, то нумерация элементов будет в указанном диапазоне.

{% do salt.log.info('Обратный отсчет') %}
{% for i in range(0, 10) %}
{% do salt.log.info(10 - i) %}
{% endfor %}

Информация о целевой системе (grains)

При написании скриптов Jinja вы можете опираться на информацию о целевом хосте, на котором этот скрипт будет применен. Данная информация доступна в словаре grains (зерна), тут вы найдете информацию об операционной системе, памяти, дисках, настройках сетевых интерфейсов и многом другом. Например, используя ключ nodename, можно получить имя хоста:

{% set node = salt['grains.get']('nodename') %}

Актуальное содержание словаря grains для конкретного хоста можно посмотреть утилитой salt-call с помощью команды sudo salt-call grains.items:

admin@dc-1:~$ sudo salt-call grains.items
local:
    ----------
    aldpro_dc_list:
        - dc-1.ald.company.lan
    aldpro_machine_type:
        dc
    astra_version:
        ----------
        distr:
            smolensk
        version:
            1.7.4
    basedn:
        dc=ald,dc=company,dc=lan
    biosreleasedate:
        12/01/2006
    biosversion:
        VirtualBox
    chasis_type:
        ----------
        chasis:
            Other
        is_notebook:
            False
 ...

Выполним запрос grains.items на pc-1:

admin@dc-1:~$ sudo salt-call grains.items
local:
   ----------
   . . .
   dns
       ----------
       domain
       ip4_nameservers
           - 10.0.1.11
       ip6_nameservers
       nameservers
           - 10.0.1.11
       options
       search
            - ald.company.lan
       sortlist
   domain
       ald.company.lan
   efi
       **False**
   efi-secure-boot:
       **False**
   fqdn
       pc-1.ald.company.lan
   fqdn_ip4
        - 10.0.1.51
 . . .
   mem_total
       **1978**
   nodename:
       pc-1.ald.company.lan
   num_cpus:
       **2**
   num_gpus
       **1**
   os:
       AstraLinux
   os_family
       Debian
 . . .

Параметры групповых политик в pillar

Скрипт получает значения параметров групповых политик через справочник pillar. Служба Salt-Minion-Standalone извлекает данные из LDAP-каталога с учетом наследования, выполняет суммирование и предоставляет результирующий словарь.

Содержание словаря pillar из кэша можно посмотреть утилитой salt-call с помощью команды

$ sudo salt-call pillar.items -c /srv/salt/standalone/config

Для обновления кэша используйте функцию gpupdate.build, примеры приведены выше.

Декларативные описания Salt

Декларативная часть скрипта описывает в YAML-формате желаемую конфигурацию компьютера. В структуре документа указано, какие методы нужно вызывать для конфигурирования системы и с какими параметрами. В качестве примера создадим файл software.sls со скриптом, который описывает состояние, после применения которого в системе должен стать доступен диспетчер задач htop.

Создадим файл vim software.sls со следующим содержимым:

software_htop: # Имя состояния
  pkg.installed: # Вызов метода installed модуля salt.states.pkg
    - pkgs: # Аргументы метода installed
      - htop # Значение аргумента pkgs

Скрипт можно выполнить с помощью команды salt-call:

admin@dc-1:~$ sudo salt-call --local --file-root=. state.sls software

По результатам выполнения команды видно, что установка прошла успешно и htop готов к работе:

...
[INFO    ] Loading fresh modules for state activity
[INFO ] Completed state [software_htop] at time 11:39:24.930751 (duration_in_ms=3955.279)
local:
----------
           ID: software_htop
     Function: pkg.installed
       Result: True
      Comment: The following packages were installed/updated: htop
      Started: 11:39:20.975472
     Duration: 3955.279 ms
      Changes:
               ----------
               htop:
                   ----------
                   new:
                        2.2.0-1
                   old:

 Summary for local
 ------------
 Succeeded: 1 (changed=1)
 Failed:    0
 ------------
 Total states run:     1
 Total run time: 3.955 s

Язык YAML, также как и JSON, является языком разметки текста для сериализации данных. Каждая строка задает пару ключ-значение, между которыми стоит знак двоеточия. Ключи могут состоять из одного и более слов, причем заключать их в кавычки необязательно. В качестве значений поддерживаются как скалярные типы данных (int, float, boolean, string), так и вложенные словари, что позволяет создавать древовидные структуры данных.

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

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

На второй строке указано, что требуется вызвать метод installed модуля salt.states.pkg. Данный модуль является модулем состояния, т. е. его методы приводят систему к требуемому состоянию, описывая желаемый конечный результат, а не последовательность действий, с помощью которой можно прийти к этому состоянию.

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

На третьей и четвертой строке скрипта мы передаем методу аргумент pkgs со значением htop. Обратите внимание, что аргумент и его значение являются элементами списков, поэтому в начале этих строк стоит символ дефиса.

Требования к скриптам

Ранее служба Salt-Minion выполняла скрипты дополнительных параметров всегда, т.е. вне зависимости от того, назначен этот параметр или нет. Именно поэтому в скрипте дополнительного параметра repo_source_list у нас есть проверка:

{% set id = 'rbta_ldap_custom_gp_host_repo_source_list' %}
{% set node = salt['grains.get']('nodename') %}
{% set gpo = salt['pillar.get']('aldpro-hosts:' + node + ':' + id) %}
...
{% if gpo %}
...
{% endif %}

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

Импорт дополнительных параметров

В разделе дополнительных источников информации приведена ссылка на архив с набором дополнительных параметров групповых политик из личного кабинета клиента.

В архиве находится в том числе скрипт policy.py, с помощью которого дополнительные параметры можно автоматически импортировать в домен. Скрипт написан на языке Python 3 и взаимодействует с контроллером домена через REST API.

Перед выполнением импорта следует определить параметры подключения к серверу через переменные окружения. Пароль можно передавать открытым текстом, но скрипт поддерживает в том числе и Kerberos-аутентификацию.

export ALDPRO_API_SERVER_URL='dc-1.ald.company.lan'
export ALDPRO_API_CA_PATH='/etc/ipa/ca.crt'
export ALDPRO_API_LOGIN='admin'
export ALDPRO_API_PASSWORD='AstraLinux_174'

Для импорта всех параметров сразу можно использовать скрипт import.sh, который по цепочке вызовет остальные sh-скрипты, создающие объекты в каталоге.

admin@dc-1:~$ sh import.sh

Пример создания папки из скрипта import_folder_common.sh:

python3 policy.py folder add \
--host \
--parent-folder 'Дополнительные параметры' \
--folder-name 'Общие параметры'

Пример создания параметра import_parameter_common_firefox_policy.sh:

python3 policy.py parameter add \
--host \
--id 'rbta_ldap_custom_gp_host_firefox_policy' \
--name 'Политика браузера Firefox' \
--parent-folder 'Общие параметры' \
--description 'Позволяет централизованно настраивать параметры браузера Firefox путем изменения содержания файла /usr/lib/firefox/distribution/policies.json

Атрибут "Блокировать доступ к странице addons" устанавливает значение параметра BlockAboutAddons
- true - доступ заблокирован
- false - доступ предоставлен

Если значение не задано, то параметр будет отсутствовать в файле политики, по умолчанию доступ предоставляется.

Атрибут "Блокировать доступ к странице config" устанавливает значение параметра BlockAboutConfig
- true - доступ заблокирован
- false - доступ предоставлен

Атрибут "Список доменов для Kerberos-аутентификации" устанавливает значение параметра Authentication.SPNEGO, элементы списка разделяются запятыми, например:
- ald.company.lan, win.company.lan

Атрибут "Список доверенных сертификатов" устанавливает значение параметра Certificates.Install. Требуется указывать полный путь к файлу на локальном диске целевой машины, элементы списка разделяются запятыми, например:
- /etc/ipa/ca.crt, /etc/ssl/certs/ca-certificates.crt

Атрибут "Адрес домашней страницы" устанавливает значение параметра Homepage.URL, требуется указать полный URL адрес страницы, например
- https://dc-1.ald.company.lan

Если адрес домашней страницы задан, то дополнительно будут установлены параметры Homepage.Locked=true и Homepage.StartPage=homepage-locked' \
--attr 'Блокировать доступ к странице addons':block_about_addons:'' \
--attr 'Блокировать доступ к странице config':block_about_config:'' \
--attr 'Список доменов для Kerberos-аутентификации':authentication_spnego:'' \
--attr 'Список доверенных сертификатов':trusted_certificates:'' \
--attr 'Адрес домашней страницы':homepage_url:'' \
--script 'import_parameter_common_firefox_policy.sls' \
--script-comment 'Версия 1.0'

Практика и тестирование

• Практическая работа: Модуль 6. Управление политиками ALD Pro
• Тест: Модуль 6. Управление политиками ALD Pro

Заключение

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

Дополнительные источники информации

• Основы Salt, Крейг Себеник и Томас Хэтч

• Дополнительные параметры групповых политик из личного кабинета

• Формат даты GeneralizedTime