Настройка парольной политики windows

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

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

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

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 — имя правила, по которому мы хотим получить информацию;

Картинка с сайта: www.aldpro.ru

Если ограничить область действия правила 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 Службы, необходимые для типовых сценариев работы

Чтобы понять, к какой службе требуется предоставить доступ, проще всего выполнить необходимое действие на целевой системе и посмотреть, какие сообщения об ошибках появятся в журнале /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)
...

После развертывания домена в системе уже есть список наиболее распространенных служб, но какие-то службы нам все равно потребуется добавить вручную. Давайте создадим «xrdp-sesman». Сделать это можно через веб-интерфейс на странице , см. рис. 283, или из командной строки:

admin@dc-1:~$ kinit admin
admin@dc-1:~$ ipa hbacsvc-add 'xrdp-sesman' --desc='Доступ по RDP'

Картинка с сайта: www.aldpro.ru

Допустим, нам нужно предоставить возможность разработчикам из группы dev-users удаленно подключаться к своим компьютерам из группы dev-computers через SSH/RDP и выполнять отдельные команды из-под sudo. Для этого откройте страницу и нажмите кнопку . Введите имя правила «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

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

Учитывая, что пользователи и хосты уже есть в домене, настройку правил следует начать с создания команды. Сделать это можно, например, через портал управления ALD Pro на странице , см. рис. 286, или из командной строки:

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

Где:

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

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

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

Картинка с сайта: www.aldpro.ru

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

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.

Картинка с сайта: www.aldpro.ru

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

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

  • Порядок 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. Для того чтобы разрешить действовать от суперпользователя, следует оставить эту вкладку незаполненной.

Проверка правил 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_ald.company.lan.ldb -b cn=sysdb '(&(objectClass=sudoRule))'

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

Политики бывают локальными и доменными. Локальные политики появились еще в 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. Если клиентская служба групповой политики будет остановлена, то настройки применяться не будут, поэтому в целях безопасности права доступа по умолчанию настроены таким образом, что даже администратору запрещено ее останавливать, см. рис. 288. Текущие права доступа вы можете посмотреть командой sc.exe sdshow gpsvc.

Картинка с сайта: www.aldpro.ru

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

Картинка с сайта: www.aldpro.ru

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

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

Картинка с сайта: www.aldpro.ru

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

Картинка с сайта: www.aldpro.ru

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

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

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

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

  Например, контейнер GPO «Default Domain Policy» в домене win.company.lan можно найти в записи, см. рис. 292:
  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}, см. рис. 292.

Картинка с сайта: www.aldpro.ru

Картинка с сайта: www.aldpro.ru

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

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

Картинка с сайта: www.aldpro.ru

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

Картинка с сайта: www.aldpro.ru

Область действия групповых политик, назначенных на домен, сайт или структурное подразделение можно сузить с помощью 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.

Картинка с сайта: www.aldpro.ru

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

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

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

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

Картинка с сайта: www.aldpro.ru

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

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

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

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

Картинка с сайта: www.aldpro.ru

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

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

Картинка с сайта: www.aldpro.ru

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

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

Картинка с сайта: www.aldpro.ru

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Картинка с сайта: www.aldpro.ru

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

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

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

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

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

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

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

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

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

Картинка с сайта: www.aldpro.ru

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

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

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

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

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

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

Картинка с сайта: www.aldpro.ru

Работа групповых политик в ALD Pro до версии 2.2.0

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

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

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

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

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

Работа групповых политик в ALD Pro с версии 2.2.0

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

Работа групповых политик в ALD Pro с версии 2.4.0

Кардинальных изменений работы ГП в версии 2.4.0 не произошло. Перечислим некоторые значимые моменты:

• Появилась возможности влиять на порядок наследования через установку таких флажков, как «Блокировать наследование» (англ. Block Inheritance) и «Наследовать принудительно» (англ. Enforced).

• Упрошен синтаксис команд cli для форсирования применения политик и получения настроек результирующей политики (pillar).

• Переработаны скрипты коробочных параметров, повышена стабильность их работы.

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

Картинка с сайта: www.aldpro.ru

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

admin@dc-1:~$ sudo tree -L 2 /srv/aldpro-salt/roots/states/policies/
/srv/aldpro-salt/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 также несколько очевидных способов повышения производительности:

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

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

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

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

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

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

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

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

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

• С версии 2.4 появилась возможность влиять на порядок наследования через установку таких флажков, как «Блокировать наследование» (англ. Block Inheritance) и «Наследовать принудительно» (англ. Enforced).

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

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

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

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

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

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

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

Картинка с сайта: www.aldpro.ru

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

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

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

• И нажмем кнопку

  

  Картинка с сайта: www.aldpro.ru

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

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

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

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

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

1. На вкладке включим параметр из списка , установим значение «no», установим во «Включено» и нажмем кнопку

Картинка с сайта: www.aldpro.ru

Картинка с сайта: www.aldpro.ru

1. Перейдем на вкладку и создадим новое назначение кнопкой .

   

   Картинка с сайта: www.aldpro.ru

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

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

   

   Картинка с сайта: www.aldpro.ru

2. Файлы, которые используются для применения этого параметра, находятся в каталоге /srv/aldpro-salt/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 aldpro-gpupdate --gp
admin@dc-1:~$ cat /etc/parsec/parsec.conf

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

   

   Картинка с сайта: www.aldpro.ru

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

Механизм определения пользовательских сессий

Предлагаем немного подробнее рассмотреть реализацию механизма определения активных пользовательских сессий в ALD Pro при применении политики параметров пользователя. Обратите внимание, что параметры пользователя применяются в цикле индивидуально по отношению к каждой учетной записи, с помощью которой был выполнен интерактивный вход в операционную систему. Для операционных систем 1.8_x86-64 список сессий извлекается через интерфейс dbus (org.freedesktop.login1), а для всех остальных ОС с помощью классической утилиты users (см. модули aldpro_user.py и dbus.py).

Система не учитывает вход из-под sudo su, но не ограничивается только графическими сессиями, поэтому, если вам потребуется обогатить данные pillar параметрами другого пользователя, вы можете выполнить вход с помощью простой утилиты login:

admin@pc-1:~$ sudo login testuser

Давайте рассмотрим механизм определения сессий по шагам:

1. Пользователь подключается к рабочей станции: графическое подключения Fly или консольное подключение Login.

2. Запускаются модули PAM в зависимости от выбранного метода подключения: fly-dm (/etc/pam.d/fly-dm) или login (/etc/pam.d/login).

3. Выше упомянутые PAM модули вызывают PAM модуль Session (/etc/pam.d/common-session). В нем содержится опция запуска внешнего скрипта salt-masterless-login:

   session optional pam_exec.so /usr/sbin/salt-masterless-login
   

PAM модуль передает переменную PAM_USER данному Python скрипту, который отделяет доменного пользователя от локального, сравнивая его с /etc/passwd. В случае, если пользователь доменный, то будет запущена следующая команда:

aldpro-salt-call \
--local \
-m \
/srv/aldpro-salt/roots/_modules/ \
state.single \
module.run \
aldpro_user.store_domain_user \
-c \
/srv/aldpro-salt/config \
queue=True

Примечание

В ванильной версии Salt для выполнения salt-функций на миньоне предназначена утилита salt-call. В продукте ALD Pro мы упаковываем salt-клиент в отдельное python окружение, поэтому для взаимодействия с нашей автономной службой aldpro-salt-minion вам следует использовать утилиту aldpro-salt-call.

1. Команда, запущенная в предыдущем шаге вызывает функцию store_domain_user из модуля /srv/aldpro-salt/roots/_modules/aldpro_user.py, по окончанию работы которой, у нас формируется файл со списком пользовательских сессий /opt/rbta/aldpro-salt/minion/gp-user_sessions.json

   cat /opt/rbta/aldpro-salt/minion/gp-user_sessions.json
   {"admin": {"last_active": "2025-03-19 14:33:15.275652"}}
   

Файл gp-user_sessions.json регулярно очищается с помощью функции purge_inactive_sessions. Она удаляет все сессии, которые были неактивны последние 20 дней. Запускается раз в день. Посмотреть следующий запуск можно:

aldpro-salt-call schedule.show_next_fire_time purge_inactive_sessions

1. На последнем этапе запускается модуль gp_sum.py (/srv/aldpro-salt/roots/_modules/gp_sum.py). Функция build_gp_pillars из модуля gp_sum.py с помощью dbus определяет все текущие сессии, далее сравнивает их со списком gp-user_sessions.json и в случае совпадения строит pillar для этого пользователя.

На рис. 312 представлены описанные шаги в виде схемы для удобства восприятия.

Картинка с сайта: www.aldpro.ru

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

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

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

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

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

admin@pc-1:~$ sudo aldpro-gpupdate --gp_timer
Таймер заданий ГП
local:
   ----------
   next_fire_time:
       2025-03-24T14:43:09
   result:
       True

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

admin@pc-1:~$ sudo aldpro-salt-call schedule.job_status build_and_run_gp
local:
 ----------
 _last_run:
     2025-03-24T14:13:09
 _next_fire_time:
     2025-03-24T14:43:09
 _next_scheduled_fire_time:
     2025-03-24T11:06:27
 _seconds:
     1800
 _splay:
     2025-03-24T14:53:30
 args:
 enabled:
     True
 function:
     gp_sum.build_and_run_gp
 jid_include:
     True
 kwargs:
     ----------
 maxrunning:
     1
 minutes:
     30
 name:
     build_and_run_gp
 return_job:
     False
 run:
     True
 run_on_start:
     False
 splay:
     ----------
     end:
         3000
     start:
         300

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

admin@pc-1:~$ sudo aldpro-gpupdate --gp --verbose

Где:

• –gp – форсированное применение групповых политик с очисткой кэша и формированием нового набора параметров результирующей политики (pillar).

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

Фактически «под капотом» при этом происходит вызов команды:

admin@pc-1:~$ aldpro-salt-call gp_sum.build_and_run_gp force=True verbose=True

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

После форсированного применения всех параметров на рабочей станции будет сформирован pillar и загружены все необходимые sls-скрипты, поэтому у вас появится возможность форсировать применение отдельного параметра без полной очистки кэша.
Форсированное применение отдельных параметров существенно ускоряет написание скриптов дополнительных параметров, т.к. позволяет вносить изменения не через LDAP каталог, а напрямую в локальные копии init.sls из соответствующих папок в директории /srv/aldpro-salt/roots/states/policies/host-policies/

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

$ sudo aldpro-salt-call state.apply <имя_скрипта> force=True verbose=True

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

$ sudo aldpro-salt-call state.apply rbta_ldap_date_time_h force=True verbose=True
...
[INFO    ] Completed state [/etc/chrony/chrony.conf] at time 07:59:15.835203
(duration_in_ms=1.932)
...

И не забывайте про ключ --log-level, с помощью которого можно выбрать желаемый уровень детализации: all, garbage, trace, debug, profile, info, warning, error, critical, quiet (по умолчанию warning).

$ sudo aldpro-salt-call --log-level=debug state.apply rbta_ldap_date_time_h

Чтобы форсировать применение параметра пользователя, вам потребуется добавить в pillar дополнительный ключ user с идентификатором того пользователя, для которого вы хотите применить этот параметр. Напомним, что каталог с политиками пользователей находится здесь /srv/aldpro-salt/roots/states/policies/user-policies. Например, если параметр с идентификатором rbta_ldap_env_vars_u нужно применить для пользователя admin, то команда будет выглядеть следующим образом:

sudo aldpro-salt-call state.apply rbta_ldap_env_vars_u pillar="{'user':'admin'}"

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

admin@pc-1:~$ sudo aldpro-gpupdate --gp_host_pillar
Просмотр pillar ГПO компьютера
local:
   ----------

Так как эту команду мы запустили на компьютере pc-1.ald.company.lan, то под капотом была
вызвана функция pillar.get следующим образом:

aldpro-salt-call pillar.get aldpro-hosts:pc-1.ald.company.lan

Точно такая же команда есть для просмотра данных pillar для конкретного пользователя:

aldpro-gpupdate --gp_user_pillar admin

Под капотом эта команда вызывает функцию pillar.get следующим образом:

aldpro-salt-call pillar.get aldpro-users:admin

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

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

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

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

На вкладке кликнем по узлу и нажмем кнопку

Картинка с сайта: www.aldpro.ru

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

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

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

• Уникальный идентификатор: 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, настраивает права доступа и вносит в него указанные источники программного обеспечения.

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

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

$ mkdir ~/test_salt && cd ~/test_salt
$ echo '{% do salt.log.info("Hello world!") %}' > hello.sls

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

admin@dc-1:~/test_salt$ sudo aldpro-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

sudo aldpro-salt-call --log-level=debug --local --file-root=. state.sls hello

admin@dc-1:~$ sudo aldpro-salt-call state.template_str '{% do salt.log.info("Привет, мир!") %}'
...
[INFO    ] Привет, мир!
...

{% 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 %}

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

admin@dc-1:~$ sudo aldpro-salt-call state.template_str '{% do salt.log.info("Привет, большой мир!"[0] ) %}'
...
[INFO    ] П
...

# Переменной "s" присвоена ссылка на строку текста
{% set s = "Привет, большой мир!" %}
# Переменной "f" присвоено значение "П"
{% set f = s[0] %}
# Переменной "f" присвоено значение "большой" с 8-го по 16-й символы
{% set f = s[8:16] %}
# Переменной "f" присвоено значение ", большой ", что соответствует фрагменту между указанными словами
{% set f = s[s.find("Привет")+6:s.find("мир")] %}
# Переменной "f" присвоено значение "Привет" с 0-го по 6-й символы
{% set f = s[:6] %}
# Переменной "f" присвоено значение "!", которое соответствует первому символу с конца
{% set f = s[-1] %}
# Переменной "f" присвоено значение исходной строки с обратнымпорядком символов
{% set f = s[::-1] %}

# Присваиваем переменной "a" ссылку на список из трех элементов
{% set a = ["раз", "два", "три"] %}
# Присваиваем переменной "s" значение первого элемента с индексом 0, т.е. "раз"
{% set s = a[0] %}
# Присваиваем переменной "a2" ссылку на список из первых двух элементов исходного списка, т.е. ["раз", "два"]
{% set a2 = a[0:2] %}
# Присваиваем переменной "a2" ссылку на список из трех элементов исходного списка в обратном порядке
{% set a2 = a[::-1] %}

# Присваиваем переменной "a" ссылку на список из трех элементов
{% set a = ["раз", "два", "три"] %}
# Присваиваем переменной "c" значение, равное количеству элементов в списке "a"
{% set c = a | count }
# Добавляем в список "a" еще один элемент
{% do a.append("четыре") %}
# Добавляем в список "a" еще два элемента
{% do a.extend(["пять", "я иду искать"]) %}
# Присваиваем переменной "b" ссылку на список из двух элементов
{% set b = ["кто не спрятался", "я не виноват"] %}
# Присваиваем переменной "c" ссылку на новый список, состоящий из элементов массивов "a" и "b"
{% set c = a + b %}
# Удаляем из списка "c" элемент c индексом 1, под которым сейчас находится значение "два"
{% do c.pop(1) %}
# Вставляем в список "c" новый элемент "two" под индексом 1
{% do c.insert(1, "two") %}
# Удаляем из списка "c" элемент с значением "я иду искать"
{% do c.remove("я иду искать") %}

{% set a = ["раз", "два", "три"] %}
{% set a = a | map("replace", "три", "иду искать") | list %}

# Переменной "user" присвоена ссылка на словарь
{% set user = {"login": "localadmin", "uid": 1000, "gid": 1000} %}
# Переменной "login" присвоено значение ключа "login" из словаря "user", т.е. "localadmin"
{% set login = user["login"] %}
# Переменной "uid" присвоено значение ключа "uid" из словаря "user", т.е. 1000
{% set uid = user.uid %}
# Безопаснее всего использовать метод get, который позволяет определить так же значение по умолчанию
{% set gid = user.get("uid", -1) %}

# Переменной "user" присвоена ссылка на словарь
{% set user = {"login": "admin", "uid": 1000, "gid": 1000} %}
# Присваиваем переменной "c"  значение, равное количеству элементов в словаре "user"
{% set c = user | count %}
# Присваиваем переменной "k" ссылку на объект dict_keys, который содержит список всех ключей словаря
{% set k = user.keys() %}
# Присваиваем переменной "v" ссылку на объект dict_values, который содержит список всех значений словаря
{% set v = user.values() %}
# Присваиваем переменной "i" ссылку на объект dict_items, который содержит список кортежей из ключей словаря
{% set i = user.items() %}
# Обновляем в словаре "a" значение ключа "uid", присваиваем ему значение 500
{% do a.update({"uid":500}) %}

{% if ram >= 2048 %}
  {% set ram_requirement_success = True %}
{% else %}
  {% set ram_requirement_success = False %}
{% endif %}

{% set ram_requirement_success = True if ram >= 2048 else False %}

{% set ram_requirement_success = (ram >= 2048) %}

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

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

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

{% set boolean_val = False %}

{% for item in ['a', 'b', 'c'] %}
  {% if item == 'b' %}
    {% set boolean_val = True %}
  {% endif %}
{% endfor %}

{% do salt.log.info(boolean_val) %}

{% set ns = namespace(boolean_val=False) %}

{% for item in ['a', 'b', 'c'] %}
  {% if item == 'b' %}
    {% set ns.boolean_val = True %}
  {% endif %}
{% endfor %}

{% do salt.log.info(ns.boolean_val) %}

{% set net = "10.0.1.0/24" %}
{% set net_parts = net.split("/") %}

# Покажет список ['10.0.1.0', '24']
{% do salt.log.info(net_parts) %}
{% set ip = net_parts[0] %}

# Покажет значение '10.0.1.0'
{% do salt.log.info(ip) %}
{% set mask = net_parts[1] %}

# Покажет значение '24'
{% do salt.log.info(mask) %}

admin@dc-1:~$ sudo aldpro-salt-call random.get_str length=20 lowercase=True
local:
    Z8Wta..yO|1Hq<>zf4$;

admin@dc-1:~$ sudo aldpro-salt-call state.template_str '{% set myList = ["one","two","three"] %}{% set temp = myList.pop(1) %}{% set temp = myList.append("two") %}{% do salt.log.info(myList) %}'
[INFO    ] Loading fresh modules for state activity
[INFO    ] ['one', 'three', 'two']
local:
Summary for local----------
Succeeded: 0
Failed:
0----------
Total states run:
0
Total run time:  0.000 ms

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

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

admin@dc-1:~$ sudo aldpro-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
 . . .

sudo aldpro-salt-call pillar.items

base:
  '*':
    - fonts
    - policy_pillar_path
    - aldpro_audit
    - aldpro_gpo
    - aldpro_po
    - aldpro_user

  # aldpro-salt-call state.apply rbta_ldap_env_vars_h test=True
...
        ID: /etc/bash.bashrc
   Function: file.blockreplace
     Result: True
    Comment: No changes needed to be made
...

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

sudo aldpro-salt-call --local --file-root=. state.sls software

...
[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

Идентификаторы состояний должны включать идентификатор параметра групповой политики

В предыдущих версиях продукта скрипты групповых политик объединялись в одно общее дерево состояний, поэтому разработчикам нужно было вручную обеспечивать уникальность всех используемых идентификаторов состояний, иначе могла возникать ошибка «found conflicting ID „имя_идентификатора“». Указанную ошибку было довольно трудно отловить, т.к. содержимое yaml-документов может определяться динамически с
помощью управляющих конструкций jinja в зависимости от параметров pillar, которые определяет пользователь при настройке параметров групповых политик. Данная проблема решалась путем добавления к идентификаторам состояний дополнительного префикса. В роли такого префикса выступал идентификатор самого параметра, уникальность которого гарантировалось уже самой системой по умолчанию. Начиная с версии 2.4.0, каждый параметр групповой политики выполняется по отдельности, поэтому скрипты могут содержать повторяющиеся идентификаторы, но этого рекомендуется все равно избегать. Например, если идентификатор параметра называется «rbta_ldap_custom_gp_host_sec_ssh», то у состояния, которое обеспечивает перезапуск службы, идентификатор может иметь значение «rbta_ldap_custom_gp_host_sec_ssh_restart_ssh», а чтобы уменьшить вероятность опечаток, значение идентификатора рекомендовалось формировать через подстановку значения переменной.

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

   {%- macro getvalid(value, available) -%}
       {{- value if value!='' and value.lower() in available|lower else available[0] -}}
   {%- endmacro %}

   {%- set permit_root_login = getvalid(gpo['permit_root_login'], ['no','yes','without-password','forced-commands-only']) %}
   {%- set client_alive_interval = gpo['client_alive_interval']|int(15) %}
   {%- set client_alive_count_max = gpo['client_alive_count_max']|int(1) %}
   {%- set protocol = gpo['protocol']|int(2) %}

{{ id }}:
       ini.options_present:
           - name: '/etc/ssh/sshd_config'
           - separator: ' '
           - strict: False
           - sections:
               PermitRootLogin: '{{ permit_root_login }}'
               ClientAliveInterval: '{{ client_alive_interval }}'
               ClientAliveCountMax: '{{ client_alive_count_max }}'
               Protocol: '{{ protocol }}'

{{ id }}_restart_ssh:
           service.running:
               - name: ssh
               - restart: True
               - watch:
                  - file: /etc/ssh/sshd_config

{% endif %}

После шаблонизации в формуле должно оставаться как минимум одно состояние

Управляющие конструкции Jinja позволяют динамически управлять содержанием salt формул, но эти конструкции следует использовать таким образом, чтобы после работы шаблонизатора в salt-формуле оставалось как минимум одно состояние, иначе это сильно затруднит отладку групповых политик. Даже если jinja-код определит, что никаких изменений вносить не требуется, он должен оставить в формуле хотя бы одно состояние, которое будет информировать системного администратора о результатах применения
данного параметра групповой политики. Для того чтобы описать такое состояние вы можете использовать одну из функций модуля test, например, show_notification, nop, succeed_without_changes, fail_without_changes, succeed_with_changes или fail_with_changes.

{% 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, default=[]) %}

{% for item in gpo %}
{% do item.update({'os_type': item.get('os_type', '').lower() }) %}
{% endfor %}

{% set os_type = salt['grains.get']('os') | lower %}

{% set lines = gpo | selectattr('os_type', '==', os_type)
                   | selectattr('repo_source_item', 'string')
                   | map(attribute='repo_source_item')
                   | map('trim')
                   | select('!=', '')
                   | unique
                   | list
%}

{{ id }}:
   {%- if os_type in ['astra', 'debian', 'alt'] %}
       file.managed:
           - name: /etc/apt/sources.list.d/repo_source.list
           - contents: |
                   {%- for line in lines %}
                   {{ line }}
                   {%- endfor %}
   {%- elif os_type in ['red os', 'redhat'] %}
       file.managed:
           - name: /etc/apt/sources.list.d/repo_source.list
           - contents: |
                   {%- for line in lines %}
                       {%- set sublines = line.split('|') %}
                       [customs_{{ loop.index }}]
                       {%- for subline in sublines %}
                       {{ subline }}
                       {%- endfor %}
                   {% endfor %}
   {% else %}
       test.fail_without_changes:
           - name: "ОС не поддерживается!"
           - failhard: False
   {% endif %}

Скрипт нужно выполнять только если параметр групповой политики назначен на пользователя/компьютер

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

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

{% macro getvalid(value, available) -%}
{{- value if value!='' and value.lower() in available|lower else available[0] -}}
{%- endmacro %}

{% set domain = salt['grains.get']('domain') %}
{% set dyndns_update = getvalid(gpo['dyndns_update'], ['true', 'false'])|lower %}
{% set dyndns_update_ptr = getvalid(gpo['dyndns_update_ptr'], ['true','false'])|lower %}
{% set dyndns_refresh_interval = gpo['dyndns_refresh_interval'] if gpo['dyndns_refresh_interval'] != '' and gpo['dyndns_refresh_interval'] | int != 0 else '43200' %}
{% set dyndns_ttl = gpo['dyndns_ttl'] if gpo['dyndns_ttl'] != '' and gpo['dyndns_ttl']|int != 0 else '3600' %}

{{id}}_dyndns_update:
  ini.options_present:
    - name: /etc/sssd/sssd.conf
    - separator: '='
    - sections:
        domain/{{domain}}:
          dyndns_update: {{dyndns_update}}

{{id}}_dyndns_update_ptr:
  ini.options_present:
    - name: /etc/sssd/sssd.conf
    - separator: '='
     - sections:
        domain/{{domain}}:
          dyndns_update_ptr: {{dyndns_update_ptr}}

{{id}}_dyndns_refresh_interval:
  ini.options_present:
    - name: /etc/sssd/sssd.conf
    - separator: '='
    - sections:
        domain/{{domain}}:
          dyndns_refresh_interval: {{dyndns_refresh_interval}}

{{id}}_dyndns_ttl:
  ini.options_present:
    - name: /etc/sssd/sssd.conf
    - separator: '='
    - sections:
        domain/{{domain}}:
          dyndns_ttl: {{dyndns_ttl}}

{% endif %}

Скрипт должен гарантировать идемпотентность

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

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

   {%- macro getvalid(value, available) -%}
       {{- value if value!='' and value.lower() in available|lower else available[0] -}}
   {%- endmacro %}

   {%- set deny_print = getvalid(gpo['deny_print'], ['true', 'false'])| lower %}

   {%- set filename = '/etc/cups/cupsd.conf' %}

   {%- if deny_print=='true' %}

{{ id }}_AllowAll:
           file.blockreplace:
               - name: {{ filename }}
               - marker_start: '<Location />'
               - marker_end: '</Location>'
               - append_if_not_found: True
               - content: |
                   Order allow,deny
                   Allow from 127.0.0.1

{{ id }}_DefaultShared:
           file.append:
               - name: {{ filename }}
               - text: 'DefaultShared No'

   {%- else %}

{{ id }}_AllowAll:
           file.blockreplace:
               - name: {{ filename }}
               - marker_start: '<Location />'
               - marker_end: '</Location>'
               - append_if_not_found: True
               - content: |
                   Order allow,deny
                   Allow all

{{ id }}_DefaultShared:
           file.line:
               - name: {{ filename }}
               - mode: delete
               - match: 'DefaultShared'

   {%- endif %}


{% endif %}

Ресурсоемкие действия не следует выполнять повторно, если в них нет необходимости

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

{% set id = 'rbta_ldap_custom_gp_host_update_nsosversion' %}
{% set node = salt['grains.get']('nodename') %}
{% set gpo = salt['pillar.get']('aldpro-hosts:' + node + ':' + id) %}
{% if gpo %}
{%- set host = salt['grains.get']('fqdn') %}
{%- set grains_key = gpo['grains_key'] if grains.get(gpo['grains_key']) else 'lsb_distrib_description' %}
{%- set nsosversion = salt['grains.get'](grains_key) %}
{{ id }}:
   cmd.run:
       - name: ipa host-mod '{{ host }}' --setattr=nsosversion='{{ nsosversion }}'
       - unless: ipa host-show '{{ host }}' --raw --all | grep 'nsosversion' | grep '{{ nsosversion }}'
{% endif %}

Связанные состояния нужно объединять в цепочки

В тех случаях, когда какие-то состояния нужно применять в строго определенной последовательности, их нужно объединять в цепочки с помощью директивы require, т.к. очередность состояний в sls-файле не дает полной гарантии, что их функции будут выполнены в том же порядке. После парсинга yaml-документов формируется низкоуровневая структура данных (low data), которая описывает вызов функций, и к этой структуре применяются различные оптимизации, которые повлиять на порядок выполнения функций.

Дополнительные возможности по формированию цепочек состояний могут предоставить такие директивы, как onchanges, watch, listen, prereq, onfail и use, которые позволяют выполнять функцию не просто после указанной зависимости, но еще и только в том случае, если эта зависимая функция возвращает определенное состояние. Кроме уже обозначенных возможностей есть еще директива order, с помощью которой можно также повлиять на последовательность выполнения состояний, но она существенно уступает по функциональным возможностям, т.к. позволяет поставить выполнение функции только в начало (order: 1) или конец (order:last) очереди, а назначать конкретные значения очередности выполнения крайне не рекомендуется.

В следующем примере в строках 26-31 продемонстрировано использование директивы watch, которая гарантирует, что служба ssh будет перезапущена только после выполнения тех состояний, которые затрагивают изменение файла /etc/ssh/sshd_config, и только в том случае, если файл будет действительно изменен.

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

   {%- macro getvalid(value, available) -%}
       {{- value if value!='' and value.lower() in available|lower else available[0] -}}
   {%- endmacro %}

   {%- set permit_root_login = getvalid(gpo['permit_root_login'], ['no', 'yes','without-password','forced-commands-only']) %}
   {%- set client_alive_interval = gpo['client_alive_interval']|int(15) %}
   {%- set client_alive_count_max = gpo['client_alive_count_max']|int(1) %}
   {%- set protocol = gpo['protocol']|int(2) %}

{{ id }}:
       ini.options_present:
           - name: '/etc/ssh/sshd_config'
           - separator: ' '
           - strict: False
           - sections:
               PermitRootLogin: '{{ permit_root_login }}'
               ClientAliveInterval: '{{ client_alive_interval }}'
               ClientAliveCountMax: '{{ client_alive_count_max }}'
               Protocol: '{{ protocol }}'

{{ id }}_restart_ssh:
           service.running:
               - name: ssh
               - restart: True
               - watch:
                  - file: /etc/ssh/sshd_config

{% endif %}

Используйте возможности Salt на максимум

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

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

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

   {%- macro getvalid(value, available) -%}
       {{- value if value!='' and value.lower() in available|lower else available[0] -}}
   {%- endmacro %}

   {%- set permit_root_login = getvalid(gpo['permit_root_login'], ['no', 'yes','without-password','forced-commands-only']) %}
   {%- set client_alive_interval = gpo['client_alive_interval']|int(15) %}
   {%- set client_alive_count_max = gpo['client_alive_count_max']|int(1) %}
   {%- set protocol = gpo['protocol']|int(2) %}

{{ id }}:
       ini.options_present:
           - name: '/etc/ssh/sshd_config'
           - separator: ' '
           - strict: False
           - sections:
               PermitRootLogin: '{{ permit_root_login }}'
               ClientAliveInterval: '{{ client_alive_interval }}'
               ClientAliveCountMax: '{{ client_alive_count_max }}'
               Protocol: '{{ protocol }}'

{{ id }}_restart_ssh:
           service.running:
               - name: ssh
               - restart: True
               - watch:
                  - file: /etc/ssh/sshd_config

{% endif %}

Избегайте повторов

В скриптах групповых политик следует избегать следующих антипаттернов:

• дублирования управляющих конструкций jinja;

• впечатывания одних и тех же констант вручную;

• повторного описания состояний с минимальными отличиями.

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

Проверяйте данные pillar

Данные pillar, поступающие от пользователей, должны быть проверены тщательным образом, чтобы исключать ошибки ввода или даже злонамеренные инъекции. Например:

• Используйте метод get для безопасного извлечения параметров, чтобы исключить появление ошибок в тех случаях, когда параметр не определен. Используйте возможности метода по определению значения по умолчанию {%- set param = gpo.get(„param“, „default value“) -%}

• Если метод get использовать невозможно, задействуйте фильтр default для установки значений по умолчанию. Например, {%- set param = gpo[„param“] | default(„installed“) -%}

• Целочисленные значения:

  • Приводите целочисленные атрибуты к целым числам с помощью фильтра int. Например, {%- set param = gpo[„param“] | int(45) -%}

  • Ограничивайте целочисленные атрибуты допустимым диапазоном значений «сверху» с помощью фильтра min. Например, {%- set param = [100, param] | min -%}

  • Ограничивайте целочисленные атрибуты допустимым диапазоном значений «снизу» с помощью фильтра max. Например, {%- set param = [0, param] | max -%}

• Строковые значения

  • Удаляйте лишние пробелы в начале и конце строки с помощью фильтра trim. Например, {%- set param = gpo[„param“] | trim -%}

  • Приводите строку к требуемому регистру символов с помощью фильтров lower и upper. Например, {%- set param = gpo[„param“] | lower -%}

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

{%- macro getvalid(value, available) -%}
   {{- value if value!='' and value.lower() in available|lower else available[0] -}}
{%- endmacro %}
...
{%- set pkg_state = getvalid(item.pkg_state, ['installed', 'removed']) %}

Проверяйте неявные преобразования

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

{% if items %}
{# ветка, которая будет выполнена, когда в списке items есть элементы #}
{% else %}
{# когда список пуст #}
{% endif %}

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

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

В архиве находится в том числе скрипт 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='Pa$$w0rd'

Для импорта всех параметров сразу можно использовать скрипт 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'

Создание доп. параметров групповой политики для управления и настройки ПО

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

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

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

1. Так как установка агента RuBackup это настройка общая для всего хоста, на вкладке кликнем по узлу и нажмем кнопку .

Картинка с сайта: www.aldpro.ru

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

• Название параметра: .

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

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

  Полное значение идентификатора будет «rbta_ldap_custom_gp_host_manage_rubackup_client». Оно будет использоваться в качестве имени папки на диске и в salt-скриптах.

• Тип каталога: .

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

• Тип параметра: .

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

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

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

• Папка параметра: .

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

• Назначение параметра:

Позволяет централизованно управлять клиентом RuBackup: устанавливать, настраивать и удалять.
Атрибут "Требуемое действие" определяет тип требуемого действия над клиентом RuBackup и
может принимать значения:
install – для установки
remove – для удаления
Атрибут "Основной сервер RuBackup" определяет имя или ip адрес мастер-сервера RuBackup.
Используется в случае установки или перенастройки клиента.

• оставьте по умолчанию.

  Тут задается информация о том, с какими версиями ОС совместим данный параметр.

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

Картинка с сайта: www.aldpro.ru

1. На вкладке «Атрибуты параметра» нам нужно добавить два элемента:

1. «Требуемое действие»

• : Требуемое действие.

  Название, под которым вы хотите видеть этот атрибут на карточке параметра.

• : action.

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

• : Требуемое действие: install или remove.

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

• : отметьте галочкой.

  Атрибуты, отмеченные как , должны быть заполнены при применении параметра.

Картинка с сайта: www.aldpro.ru

1. «Основной сервер RuBackup».

• : «Основной сервер RuBackup».

• : «rubackup_master».

• : «Имя или ip адрес мастер-сервера RuBackup».

• : оставьте пустым.

Картинка с сайта: www.aldpro.ru

1. На вкладке необходимо внести текст Salt-скрипта и заполнить обязательное поле комментарий, по которому можно будет идентифицировать его версии.

Нажмите кнопку и перенесите текст скрипта, приведённый ниже:

# Определение переменных из параметров задания автоматизации
{% set id = 'rbta_ldap_custom_gp_host_manage_rubackup_client' %}
{% set node = salt['grains.get']('nodename') %}
{% set gpo = salt['pillar.get']('aldpro-hosts:' + node + ':' + id) %}

{% if gpo %}
  {% set action = gpo['action'] %}
  {% set rubackup_master = gpo['rubackup_master'] %}

  # Установка
  {% if action.lower() == 'install' %}
    {% do salt.log.info("Установка клиента RuBackup") %}

    {{ id }}_install_rubackup_client:
      pkg.installed:
        - name: rubackup-common
        - name: rubackup-client

    {{ id }}_root_profile_configure:
      file.append:
        - name: /root/.bashrc
        - text:
          - "PATH=$PATH:/opt/rubackup/bin"
          - "LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/rubackup/lib"
          - "export PATH"
          - "export LD_LIBRARY_PATH"

    {{ id }}_configure_rubackup_client:
      {% if not salt[ 'file.file_exists' ]('/opt/rubackup/keys/master-key') %}
        cmd.run:
          - name: '/opt/rubackup/bin/rb_init --agree-with-eula --primary-fqdn "{{ rubackup_master }}" --client-iface eth0 --remote-replica --centr-recovery --local-backup-dir /rubackup-tmp --used-ip-version ipv4 --node client --monitoring'
          - require:
            - pkg: rubackup-client
     {% else %}
       file.keyvalue:
         - name: /opt/rubackup/etc/config.file
         - key: who-is-primary-server
         - value: {{ rubackup_master }}
         - separator: ' '
         - ignore_if_missing: True
     {% endif %}

   {{ id }}_start_rubackup_client_service:
     service.running:
       - name: rubackup_client
       - enable: true
       - require:
         - pkg: rubackup-client

   # Удаление
  {% elif action.lower() == 'remove' %}
    {% do salt.log.info("Удаление клиента RuBackup") %}

    {{ id }}_stop_rubackup_client:
      service.dead:
        - name: rubackup_client
        - enable: false

    {{ id }}_remove_rubackup_client:
      pkg.purged:
        - name: rubackup-client
        - name: rubackup-common

    {{ id }}_housekeeping_config_files1:
      file.line:
        - name: /root/.bashrc
        - mode: delete
        - match: 'PATH=\$PATH:/opt/rubackup/bin'
        - quiet: True

    {{ id }}_housekeeping_config_files2:
      file.line:
        - name: /root/.bashrc
        - mode: delete
        - match: 'LD_LIBRARY_PATH=\$LD_LIBRARY_PATH:/opt/rubackup/lib'
        - quiet: True

    {{ id }}_housekeeping_config_files3:
      file.line:
        - name: /root/.bashrc
        - mode: delete
        - match: 'export PATH'
        - quiet: True

    {{ id }}_housekeeping_config_files4:
      file.line:
        - name: /root/.bashrc
        - mode: delete
        - match: 'export LD_LIBRARY_PATH'
        - quiet: True

    {{ id }}_housekeeping_config_files5:
      file.absent:
        - name: /opt/rubackup/
  {% else %}
    {% do salt.log.info("Ошибка! Выбрано некорректное действие {{ action }}") %}
  {% endif %}
{% endif %}

Данный скрипт, в зависимости от типа выбранного действия, установит и настроит или удалит клиент RuBackup.

Картинка с сайта: www.aldpro.ru

Создание, настройка и применение групповой политики.

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

1. Для создания групповой политики перейдите в раздел «Групповые политики» и нажмите соответствующую кнопку .

Картинка с сайта: www.aldpro.ru

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

• : Управление клиентом RuBackup

• : Устанавливает, перенастраивает или удаляет клиент RuBackup

И нажмем кнопку .

Картинка с сайта: www.aldpro.ru

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

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

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

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

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

1. Включим параметр () и установим значение поля:

• : install

• : имя или ip адрес вашего сервера RuBackup

и нажмем кнопку .

Картинка с сайта: www.aldpro.ru

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

Картинка с сайта: www.aldpro.ru

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

1. Перейдем на вкладку и добавим новое назначение кнопкой .

Картинка с сайта: www.aldpro.ru

4.1. Так как мы хотим применить объект групповой политики на клиентские компьютеры, то выберем подразделение, например, и нажмем кнопку .

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

Картинка с сайта: www.aldpro.ru

1. В карточке компьютера из подразделения можно убедиться, что параметр ГП на него назначен и посмотреть значения его атрибутов.

Картинка с сайта: www.aldpro.ru

1. Полный путь до файла скрипта, который используются для применения этого параметра:

/srv/aldpro-salt/roots/states/policies/host-policies/rbta_ldap_custom_gp_host_manage_rubackup_client/init.sls

Чтобы не ждать обновления параметров выполним на компьютере pc-1.ald.company.lan команду:

sudo aldpro-gpupdate --gp

systemctl status rubackup_client

admin@pc-1:~$ sudo aldpro-gpupdate --gp
Форсированное применение групповых политик
[INFO    ] Loading fresh modules for state activity
. . .
[INFO    ] Running state [run_rbta_ldap_custom_gp_host_manage_rubackup_client] at time 12:38:17.600170
[INFO    ] Executing state salt.state for [run_rbta_ldap_custom_gp_host_manage_rubackup_client]
[INFO    ] Loading fresh modules for state activity
[INFO    ] Установка клиента RuBackup
[INFO    ] Running state [rubackup-client] at time 12:38:22.952570
[INFO    ] Executing state pkg.installed for [rubackup-client]
[INFO    ] Executing command dpkg-query in directory '/root'
[INFO    ] Executing command apt-cache in directory '/root'
[INFO    ] Executing command apt-get in directory '/root'
[INFO    ] Executing command dpkg in directory '/root'
[INFO    ] Executing command systemd-run in directory '/root'
[INFO    ] Executing command dpkg-query in directory '/root'
[INFO    ] Made the following changes:
'rubackup-client' changed from 'absent' to '2.3.0.12-1'
'rubackup-common' changed from 'absent' to '2.3.0.12-1'
. . .
id__': 'rbta_ldap_custom_gp_host_manage_rubackup_client_configure_rubackup_client'}}}}
[INFO    ] Completed state [run_rbta_ldap_custom_gp_host_manage_rubackup_client] at time 12:40:12.964257 (duration_in_ms=115364.087)
. . .
admin@pc-1:~$ systemctl status rubackup_client
● rubackup_client.service - RuBackup client
  Loaded: loaded (/etc/systemd/system/rubackup_client.service; enabled; vendor preset: enabled)
  Active: active (running) since Sat 2024-12-28 12:40:10 MSK; 2min 7s ago
Main PID: 1897226 (rubackup_client)
   Tasks: 5 (limit: 2250)
  Memory: 46.4M
   CPU: 23.512s
  CGroup: /system.slice/rubackup_client.service
          └─1897226 /opt/rubackup/bin/rubackup_client start

Для удаления клиента RuBackup достаточно изменить значение атрибута на

Импорт переменных окружения

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

export SUFFIX='dc=ald,dc=company,dc=lan'
export ALDPRO_API_SERVER='dc-1.ald.company.lan'
export ALDPRO_API_CA_PATH='/etc/ipa/ca.crt'
export ALDPRO_API_LOGIN='admin'
export ALDPRO_API_PASSWORD='Pa$$w0rd'

Расширение схемы каталога

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

cat /opt/rbta/aldpro/aldpro-laps/schema/update.ldif | envsubst | ldapmodify -c -H ldaps://ALDPRO_API_SERVER -D 'cn=Directory Manager' -w $ALDPRO_API_PASSWORD

• утилита cat считывает содержимое файла update.ldif и передает его в стандартный поток вывода;

• утилита envsubst подставляет значения переменных из среды окружения (в файле используется переменная SUFFIX);

• утилита ldapmodify вносит изменения в LDAP-каталог.

Проверить наличие изменений в схеме каталога можно командой:

ldapsearch -o ldif-wrap=no -H ldaps://$ALDPRO_API_SERVER -D 'cn=Directory Manager' -w $ALDPRO_API_PASSWORD -b 'cn=schema' + | grep LAPS

objectClasses: ( 1.3.6.1.4.1.52616.100.2.4.3000 NAME 'aldpro-laps' DESC 'Local administrator password object class' SUP top AUXILIARY MAY ( aldproLAPSPassword $ aldproLAPSPasswordExpirationTime $ aldproLAPSCurrentPasswordVersion ) X-ORIGIN ( 'ALD Pro' 'user defined' ) )
attributeTypes: ( 1.3.6.1.4.1.52616.100.2.3.3000 NAME 'aldproLAPSPassword' DESC 'Local administrator name, password and time in json format' SYNTAX    1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN ( 'ALD Pro' 'user defined' ) )
attributeTypes: ( 1.3.6.1.4.1.52616.100.2.3.3002 NAME 'aldproLAPSCurrentPasswordVersion' DESC 'Local administrator password version' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN ( 'ALD Pro' 'user defined' ) )
attributeTypes: ( 1.3.6.1.4.1.52616.100.2.3.3001 NAME 'aldproLAPSPasswordExpirationTime' DESC 'Local administrator password expiration time' SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE X-ORIGIN ( 'ALD Pro' 'user defined' ) )

Изменения в схему вносятся через указанный в параметре ALDPRO_API_SERVER контроллер домена и реплицируются на все остальные серверы автоматически. Команду можно запускать на любом компьютере в домене неограниченное количество раз. При повторном выполнении команды вы будете просто получать предупреждение «Type or value exists» о том, что указанные в файле инструкции доступа aci уже находятся в каталоге.

Импорт дополнительного параметра групповой политики

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

cd /opt/rbta/aldpro/aldpro-laps/policy/
sh import.sh

Скрипт создаст в дополнительных параметрах папку LAPS и загрузит в нее параметр «Пароли локальных администраторов».