Linux групповые политики windows

Уровень сложностиСредний

Время на прочтение5 мин

Количество просмотров15K

Многие организации в России переходят на Linux-решения, и планируют каким-то способом управлять своим парком машин. В общих словах им необходима массовая настройка операционных систем по некоторым шаблонам. На этот случай есть различные решения — от Ansible до Samba, но в этом материале я подробно расскажу про групповые политики от Alt. Постараюсь написать об интересных технических реализациях, собственных графических инструментах, приведу схемы, и, в двух словах, расскажу о сходстве и различии с другими популярными решениями.

Картинка с сайта: habr.com

Групповые политики от Alt позиционируются в качестве совместимых с решением MS Active Directory. Тема групповых политик в MS AD очень подробно задокументирована, поэтому кратко напомню только самые необходимые сведения.

Механизм групповых политик в домене требует наличие контроллера домена и его клиентов. На контроллере должна работать служба каталогов (AD), и быть настроен каталог Sysvol, в котором хранятся файлы с параметрами политик. Для каждого объекта групповой политики (GPO) в каталоге Sysvol автоматически создаются свои шаблоны групповых политик (GPT), где и расположены файлы с настройками для компьютеров и пользователей. Следовательно, задача контроллера — поддерживать актуальный Sysvol со всем его содержимым и управлять службой каталогов (Active Directory), в которой объекты групповых политик привязаны к организационным единицам (Organization Unit). Задача клиента — корректно считать файлы со своими настройками, и применить их по расписанию или принудительно. Требование для рабочего места администратора — получить необходимые инструменты управления подразделениями службы каталогов, создания объектов групповых политик (GPO) и их наполнению параметрами через admx-шаблоны или иным способом.

Картинка с сайта: habr.com

Решение от Alt поддерживает работу во всех трех направлениях — контроллер домена, клиент и рабочее место администратора. Начну с графических приложений для управления службой каталогов и редактирования групповых политик. В MS Windows подобный набор инструментов администратора называется RSAT — Remote Server Administration Tools, иначе говоря Средства удаленного администрирования сервера. RSAT — это набор приложений. Программисты Alt создали ряд аналогичных графических приложений для Linux.

Первое из них называется ADMC, его функции схожи с «Пользователями и компьютерами» от MS — такое же управление подразделениями службы каталогов контроллера домена.
Приложение Alt ADMC управляет объектами службы каталогов и объектами групповых политик. Т.е. выполняет операции с компьютерами, пользователями, группами, подключается к контроллерам домена и т.п. Создает объекты групповых политик, связывает их с подразделениями.

Картинка с сайта: habr.com

Вторая графическая утилита называется GPUI — это редактор групповых политик. Alt GPUI поддерживает загрузку admx-шаблонов с локального компьютера и политики настройки системы («предпочтения», preferences). Этих двух инструментов уже достаточно для того, чтобы через Linux-клиент управлять групповыми политиками в Windows-домене. Предварительно установив из репозитория admx-шаблоны для Windows-машин. Либо управлять доменом на базе Samba DC с Linux-клиентами Alt. Также установив родные admx-шаблоны.

Усложним схему и добавим в домен MS AD Linux-клиенты Alt. Модуль применения групповых политик здесь называется по аналогии с MS — gpupdate. Забегая вперед отмечу, что это собственная разработка, отличная от того же самого samba-gpupdate. Alt gpupdate версии 0.9.12.6-alt1 обрабатывает более 200 собственных системных политик, и — в сумме на три браузера — около 900 политик из шаблонов браузеров Yandex, Chromium и Firefox. В случае браузерных политик речь идет о формировании корректных json-файлов браузерам для политик компьютера. Замечу, что небольшая часть из этих браузерных политик требует windows-систему и не применится самим браузером. Но в целом выходит — более 1100 управляемых параметров. В довесок системные администраторы могут дополнять набор выполняемых политик, пользуясь механизмами применения, заложенными в Alt gpupdate: polkit, control, gsettings, systemd. Это не говоря о поддержке startup\shutdown\logon\logoff скриптов из настроек системы («предпочтений», preferences).

Картинка с сайта: habr.com

Механизм polkit-политик формирует правила (rules) на основе действий (actions) и позволяет настраивать ограничения в системе для приложений, поддерживающих polkit. Полный перечень доступных action можно узнать командой $pkaction. Приложения в вашей системе, работающие с шиной D-Bus, скорее всего такую поддержку используют. Механизм control управляет состоянием одноименных системных регистров, фактически это скрипты, которые могут настраивать систему. Полный список доступных настроек можно узнать командой #control. Механизм gsettings управляет ключами dconf через утилиту gsettings. Ряд окружений рабочего стола (Desktop Environment — DE) хранит настройки в базе dconf, в частности Gnome и ее производные. Список ключей dconf можно посмотреть командой $gsettings list-recursively. Конкретно в Alt сформирован admx-шаблон для dconf-ключей оболочки Mate. Механизм systemd управляет запуском служб.

Для сравнения в admx-шаблонах проекта Samba содержится около 350 машинных политик, подавляющая часть которых управляет настройками сервера Samba, в том числе в роли контроллера домена. Здесь стоит упомянуть также прочие решения на ansible, которые применяются например в домене FreeIPA. В этом случае у вас нет возможности напрямую встраиваться к Sysvol и службе каталогов, как это делают Alt или Samba.

Картинка с сайта: habr.com

Подведу короткий итог по решению групповых политик в Linux-системе от Alt. Разработан набор инструментов с открытым кодом для работы с ГП формата MS AD на Linux системах. Это графические системы управления службой каталогов и редактор групповых политик. Для Linux-систем здесь аналогов пока нет. Можно управлять настройкой ГП в windows-домене или samba-домене через AD и Sysvol.

Это механизм применения политик на Linux-клиентах, под названием gpupdate. Аналогичный по названию, но не функционалу, механизм есть у Samba. Частичный функционал можно реализовать через ansible и схожие решения. Alt gpupdate своей разработки, с ним клиент может применять политики и в домене MS AD, и в домене Samba DC. Считывает Sysvol контроллера домена и обрабатывает.

Gpupdate поддерживает некоторую часть Windows-политик в виде отображения (mapping), и работает с довольно внушительным набор собственных политик системы Alt. Механизмы Gpupdate поддерживают управление скриптами, control, правилами policykit, настройками gsettings для окружения рабочего стола, службами systemd, системными настройками, монтирование дисков, подключение общих каталогов, и много чего еще. Поддерживают полный набор машинных групповых политик браузеров — Yandex, Firefox и Chromium.

И последнее. Код инструментов и приложений, о которых я говорил, открыт. Это свободное программное обеспечение. Ссылки на git публикую ниже.

1. https://github.com/altlinux/gpupdate

2. https://github.com/altlinux/admc

3. https://github.com/altlinux/admx-basealt

4. https://github.com/august-alt/gpui

Благодарю Марию Фоканову за оформление иллюстраций и коллег за полезные замечания к материалу.

In this Post I will show you the new Active Directory Group Policy integration in Ubuntu 22.04.

Environment

• AD Server:
  • Domain Server: Windows Server 20119
  • Domain Name: devopstales.intra
  • Hostname: dc01.devopstales.intra
  • NetBIOS Name: DC01
  • Realm: DEVOPSTALES.INTRA

Join the Ubuntu 22.04 to Active Directory

First install some required packages.

sudo apt install sssd-ad sssd-tools realmd adcli adsys -y

Change the DNS and NTP server to the Active Directory Domain Controller

sudo vi /etc/netplan/01-netcfg.yaml 
---
...
    nameservers:
        addresses: [192.168.100.100]

sudo netplan apply

sudo vi /etc/ntp.conf
...
server 192.168.100.100 iburst

sudo systemctl restart ntp

ntpq -p

Test Active Directory Domain Connection

realm discover dc01.devopstales.intra

devopstales.intra
  type: kerberos
  realm-name: DEVOPSTALES.INTRA
  domain-name: devopstales.intra
  configured: no
  server-software: active-directory
  client-software: sssd
  required-package: sssd-tools
  required-package: sssd
  required-package: libnss-sss
  required-package: libpam-sss
  required-package: adcli
  required-package: samba-common-bin

Join to the Active Directory Domain

sudo realm join dc01.devopstales.intra
Password for Administrator:

id developer-user@devopstales.intra
uid=1259201103(developer-user@devopstales.intra) gid=1259200513(domain users@devopstales.intra) groups=1259200513(domain users@devopstales.intra),1259200512(domain admins@devopstales.intra),1259200572(denied rodc password replication group@devopstales.intra)

If you want to cut down the domain name from the username:

sudo vi /etc/sssd/sssd.conf
 use_fully_qualified_names = False

systemctl restart sssd

id Administrator
uid=1259200500(administrator) gid=1259200513(domain users) groups=1259200513(domain users),1259200572(denied rodc password replication group),1259200512(domain admins),1259200518(schema admins),1259200520(group policy creator owners),1259200519(enterprise admins)

Enable home folder creation for domain users:

sudo pam-auth-update --enable mkdir

Now you can login wit and AD user to the Ubuntu:

exit

Ubuntu 22.04 LTS dlp.srv.world ttyS0

ubuntu-client login: developer-user@devopstales.intra
Password:
Welcome to Ubuntu 22.04 LTS (GNU/Linux 5.15.0-25-generic x86_64)

Manage Linux GPO from Windows AD

To manage Linux clients from AD Group Policy we need to install the custom Group Policies to the AD Domain Controller sysvol folder.

Firs we generate the custom Group Policy files:

sudo adsysctl policy admx all

On AD Domain Controller copy these files to:

.admx C:\Windows\SYSVOL\domain\Policies\PolicyDefinitions\
.adml C:\Windows\SYSVOL\domain\Policies\PolicyDefinitions\en-US\

Create GPO for sudo

On the Windows Active Directory Domain Controller open Group Policy Management Console

Create a new GPO and right click Edit

Go to Computer Configuration > Policies > Administrative Templates > Ubuntu > Client Management > Privilege Authorization. Then Select Client Administrators Select Enable and add the usernames.

Now force sync the GPOs on the Ubuntu client:

adsysctl policy update -av

adsysctl policy applied --details

Now you can sudo with the selected user.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В gpupdate, начиная с версии 0.13.0, предоставляется поддержка LAPS — механизма централизованного управления паролями локальных администраторов на компьютерах домена. Текущий пароль локального администратора хранятся в защищённых атрибутах объектов Computer в Active Directory, автоматически изменяется через заданные интервалы и может быть получен только пользователем или пользователями, состоящими в группах, которым администратор явно предоставил соответствующие права (параметр в политике «Настройка авторизованных дешифраторов паролей (Расшифрование паролей)» или пользователями, которые входят в группу «Администраторы домена», если параметр отключен или не настроен).

Настраивать политики можно как ключами реестра из Windows-ADMX, так и ключами реестра, прописанными в пакете admx-basealt. При этом, если заданы оба типа ключей, приоритет отдается ключам из admx-basealt.

В этой статье будет описано, как настроить групповые политики для управления паролями локальных администраторов на клиентской машине ALT Linux.

Предполагается, что инфраструктура уже развернута: в домене Active Directory (Windows Server 2016 или более новая версия) настроен LAPS (см. статью Microsoft), клиентская машина на ALT Linux введена в домен AD (см. Ввод машины в домен).

Поддержка LAPS в инфраструктуре с ALT Linux и Windows:

После выполнения всех необходимых настроек на контроллере домена в Active Directory в схемы будут добавлены следующие атрибуты:

• msLAPS-PasswordExpirationTime
• msLAPS-Password
• msLAPS-EncryptedPassword
• msLAPS-EncryptedPasswordHistory
• msLAPS-EncryptedDSRMPassword
• msLAPS-EncryptedDSRMPasswordHistory

Проверить это можно в свойствах компьютера во вкладке Атрибуты.

Описание политик

В скобках указаны названия аналогичных политик в ALT Linux.

1. Имя учетной записи администратора для управления (Имя учетной записи администратора)

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

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

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

   НЕ включайте этот параметр политики для управления встроенной учетной записью администратора. Встроенная учетная запись администратора определяется автоматически по известному SID и не зависит от имени учетной записи.

2. Включить шифрование паролей (Шифрование паролей)

   Когда вы включаете этот параметр, управляемый пароль шифруется перед отправкой в Active Directory.

   Включение этого параметра не действует, если:

   • пароль не настроен для резервного копирования в Active Directory
   • функциональный уровень домена Active Directory не ниже Windows Server 2016 или выше.

   Если этот параметр включен, а функциональный уровень домена не ниже Windows Server 2016, пароль управляемой учетной записи шифруется.

   Если этот параметр включен, а функциональный уровень домена меньше, чем Windows Server 2016, пароль управляемой учетной записи не копируется в каталог.

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

   Этот параметр будет включен по умолчанию, если он не настроен.

3. Действия после проверки подлинности (Действия после проверки подлинности)

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

   Льготный период: указывает количество времени (в часах) ожидания после аутентификации перед выполнением указанных действий после аутентификации.

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

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

   • Сброс пароля: по истечении льготного периода пароль управляемой учетной записи будет сброшен;
   • Сбросьте пароль и выйдите из управляемой учетной записи: по истечении льготного периода пароль управляемой учетной записи будет сброшен, а все интерактивные сеансы входа с использованием управляемой учетной записи будут прекращены;

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

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

   Примечания: Если этот параметр отключен или не настроен, действия после проверки подлинности по умолчанию будут «Сбросить пароль и выйти из управляемой учетной записи».

4. Не разрешайте сроку действия пароля превышать время, требуемое политикой (Истечение срока действия пароля)

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

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

5. Настройка каталога резервного копирования паролей (Каталог резервного копирования паролей)

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

   • Отключено = отключено (пароль не будет резервироваться)
   • Azure Active Directory = Резервное копирование пароля в Azure Active Directory
   • Active Directory = Резервное копирование пароля в Active Directory

   Если не указано иное, значение этого параметра по умолчанию равно 0 (отключено).

   Если для этого параметра установлено значение Azure Active Directory, а управляемое устройство не присоединено к Azure Active Directory, пароль локального администратора не будет управляться.

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

   Если этот параметр отключен или не настроен, пароль локального администратора не управляется.

6. Параметры паролей (Параметры паролей)

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

   • Параметр «Сложность пароля» — допустимые к использованию символы при создании нового пароля. По умолчанию: «Заглавные буквы, строчные буквы, цифры, специальные символы».
   • Длина пароля — количество символов в пароле. Минимум: 8 символов; Максимум: 64 символа; По умолчанию: 14 символов.
   • Срок действия пароля в днях. Минимум: 1 день (7 дней, если каталог резервного копирования настроен как Azure AD); Максимум: 365 дней; По умолчанию: 30 дней.

7. Настройка авторизованных дешифраторов паролей (Расшифрование паролей)

   Настройте этот параметр для управления конкретным пользователем или группой, пользователям которой разрешено расшифровывать зашифрованные пароли.

   Настройка этого параметра не действует, если не включено шифрование пароля.

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

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

   Для этого параметра необходимо указать либо SID в строковом формате («S-1-5-21-2127521184-1604012920-1887927527-35197»), либо имя группы или пользователя в домене\( группа или пользователь). Указанный пользователь или группа должны разрешаться управляемым устройством, в противном случае резервное копирование паролей выполняться не будет.

8. Настройка размера журнала зашифрованных паролей (Размер журнала зашифрованных паролей)

   Используйте этот параметр, чтобы указать, сколько предыдущих зашифрованных паролей будет храниться в Active Directory. Настройка этого параметра не действует, если:

   • пароль не настроен для резервного копирования в Active Directory;
   • не включено шифрование пароля.

   Допустимый диапазон значений количества хранимых паролей — 0 — 12;

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

   Если политика отключена или не настроена, в Active Directory не будет храниться ни одного старого пароля.

Применение

1. Установка gpupdate на клиентах

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

   # apt-get install gpupdate
   # gpupdate-setup enable
   

2. Создать подразделение (OU,Organizational Units) и добавить в нее компьютеры, к которым необходимо применить политику:

   

   Картинка с сайта: www.altlinux.org

   или

   

   Картинка с сайта: www.altlinux.org

   Как создать подразделение см. ADMC.

3. Создать групповую политику и связать с подразделением:

   

   Картинка с сайта: www.altlinux.org

   или

   

   Картинка с сайта: www.altlinux.org

   Как создать групповую политику и связать с подразделением см. ADMC.

4. Настроить групповые политики ключами реестра из Windows-ADMX или ключами реестра из admx-basealt:

   

   Картинка с сайта: www.altlinux.org

   или

   

   Картинка с сайта: www.altlinux.org

   Как редактировать групповые политики см. GPUI.

   Необходимо обязательно установить параметр «Active Directory» в политике «Настройка каталога резервного копирования паролей (Каталог резервного копирования паролей)» и установить состояние «Включено» в политике Включить шифрование паролей (Шифрование паролей).

   В GPUI обязательно нужно включить механизм GPUpdate «Настройка LAPS»

   

   Картинка с сайта: www.altlinux.org

5. Применить групповые политики с помощью gpupdate :

   $ gpupdate 
   Apply group policies for computer.
   Apply group policies for user.
   

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

Проверим, что LAPS будет управлять паролем для локальной учетной записи root.

Для этого в политике «Имя учетной записи администратора для управления (Имя учетной записи администратора)» необходимо указать в параметре root.

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

Данный пароль можно скопировать и использовать для аутентификации на клиентской машине с учетной записью root. После истечения срока действия, заданного групповой политикой, будет автоматически сгенерирован новый пароль и выполнено действие в зависимости от политики «Действия после проверки подлинности (Действия после проверки подлинности)».