Выкручиваем сложность пароля на 150-200% в РЕД АДМ Промышленная редакция (с помощью ePSO)

Привет, Хабр! На связи Дмитрий, инженер по инфраструктурным решениям в компании РЕД СОФТ. Сегодня будем расширять парольные политики в РЕД АДМ — минимум теории, больше практики. Покажу, как подготовить инфраструктуру, создать и применить расширенную политику, а также расскажу, какие нюансы стоит учитывать при работе со схемой. Даже самый требовательный офицер безопасности будет вами гордиться.

Немного базы перед погружением в практику

Я вас обманул, немного теории будет. Но это важно для понимания смысла существования ePSO. Представим, что это предыстория главного героя сегодняшней статьи.

ePSO (Extended Password Settings Object) — это расширенные парольные политики, которые появились в РЕД АДМ Промышленная редакция 2.1 как дополнение к классическим PSO. Если стандартные политики позволяют задать базовые рамки — длину, срок действия и простой флаг «сложности» пароля, то ePSO уходят глубже: они дают гранулярный контроль над составом пароля — минимальное количество спецсимволов, цифр, символов Unicode, а также раздельные требования к русским и английским буквам в верхнем и нижнем регистре.

Зачем мы реализовали ePSO в РЕД АДМ? Во-первых, чтобы разорвать порочную практику «одной политики на всех». Учётной записи администратора домена, сотруднику ИБ и маркетологу нужны разные уровни защиты. Во-вторых — и это особенно важно для госсектора и критической информационной инфраструктуры, — помогаем соблюдать требования ФСТЭК России по ИАФ.4. Они обязывают оператора задавать характеристики пароля с точностью до регистра, количества символов, сочетания букв, цифр и специальных символов, а также контролировать сроки действия и историю смены. Для тех, кто хочет ознакомиться с полным списком: он вот здесь.

Стандартных механизмов для такой детализации недостаточно, а ePSO позволяют закрыть эти пункты «из коробки» и выкрутить требования к сложности паролей на 150-200%.

Этим мы сегодня и займёмся.

Что понадобится

Для повторения шагов из статьи потребуется развёрнутый домен на базе РЕД АДМ Промышленная редакция 2.1 и клиентский ПК, введённый в домен. В нашем случае стенд выглядит так:

● Контроллер домена: РЕД ОС 7.3.6 Server Minimal + РЕД АДМ Служба каталогов   2.1

● Клиент: РЕД ОС 8.0.2 Рабочая станция

Все операции по управлению расширенными политиками выполняются через samba-tool на контроллере домена.

О том, как развернуть домен РЕД АДМ, можно почитать в «Руководстве администратора службы каталога».

Шаг 1. Расширение схемы

Функционал ePSO (Extended Password Settings Object) работает поверх стандартных парольных политик, но требует предварительного расширения схемы каталога. Без этого шага создать объект PSO не получится.

Проверяем роли FSMO

Расширять схему имеет право только владелец роли Schema Master. Убедитесь, что операцию выполняете на сервере с этой ролью. Проверить можно командой:

samba-tool fsmo show

Разрешение обновления схемы

Внесите изменения в файл /etc/samba/smb.conf в секции [global] на всех контроллерах домена RED DC в домене:

dsdb:schema update allowed = true

Без этого параметра команда расширения схемы отклонит изменения.

Наконец, само расширение схемы

Выполняем от имени администратора домена:

samba-tool schema extend rsSecPassCompl -U administrator

Если вы не на сервере-владельце роли Schema Master, укажите целевой сервер явно:

samba-tool schema extend rsSecPassCompl -H ldap://dc-server -U administrator

Где:

● ldap:// — протокол (LDAP или LDAPS);

● dc-server — короткое или полное имя сервера с ролью Schema Master.

После успешного выполнения схема будет содержать атрибуты, необходимые для работы ePSO, а в терминале вы увидите надпись: «Preset rsSecPassCompl has been extended».

Шаг 2. Создание и применение объекта PSO

Создание объекта расширенной политики

Создадим объект расширенной парольной политики. Синтаксис команды:

samba-tool domain passwordsettings pso create test-pso 1 -h

Где:

● test-pso — произвольное имя вашей PSO.

● 1 — приоритет применения PSO.

● + Любые другие опции, которые хотите задать

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

samba-tool domain passwordsettings pso create IT-Admins-PSO 1 \

  --min-pwd-length=14 \

  --pwd-complexity=on \

  --max-pwd-age=60 \

  --min-pwd-age=1

В примере мы создаём политику под названием IT-Admins-PSO с приоритетом 1, минимальной длиной пароля — 14, с включенным контролем сложности пароля и проверками на минимальный и максимальный срок действия пароля.

Вот небольшая шпаргалка по всем возможным параметрам:

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

samba-tool domain passwordsettings pso create -h

Назначение политики пользователю

Список созданных парольных политик можно посмотреть командой:

samba-tool domain passwordsettings pso list

Созданная политика пока никому не назначена. Мы можем применить парольную политику как на пользователя, так и на группу. Выбираем, кого порадуем новыми требованиями (например, коллегу по фамилии Иванов), и привязываем её к нужной учётной записи:

samba-tool domain passwordsettings pso apply IT-Admins-PSO ivanov

Где:

● IT-Admins-PSO — имя созданной политики;

● ivanov — имя пользователя в домене.

С этого момента для пользователя ivanov действуют требования из IT-Admins-PSO, а не доменные настройки по умолчанию.

Обратите внимание! Если у пользователя на текущий момент стоит какой-то простой пароль (без фантазии, изюминки и лоска), который к тому же не подходит под требования PSO, то он сможет пользоваться этим паролем до тех пор, пока не истечёт срок действия пароля. Принимайте это во внимание: после того, как применили парольную политику, не забудьте сменить пароли пользователям.

Шаг 3. Расширение существующей PSO

Но не останавливаемся на полумерах — ivanov страдал защищён недостаточно. Пришло время включить нашу новую технологию ePSO (Extended Password Settings Object) с доработанной логикой проверки паролей.

Используем команду:

samba-tool domain passwordsettings pso extend IT-Admins-PSO

После расширения объекта можно задавать специфичные для ePSO настройки:

samba-tool domain passwordsettings pso set IT-Admins-PSO -h

Список доступных ePSO-атрибутов выводится в справке после расширения схемы. Но я проспойлерю, вот он:

● rsSecPassComplMinSpecial — минимальное количество спец. символов

● rsSecPassComplMinNumeric — минимальное количество цифр

● rsSecPassComplMinUnicode — минимальное количество символов UniCode

● rsSecPassComplMinUpperEng — минимальное количество английских символов верхнего регистра

● rsSecPassComplMinUpperRus — минимальное количество русских символов верхнего регистра

● rsSecPassComplMinLowerEng — минимальное количество английских символов нижнего регистра

● rsSecPassComplMinLowerRus — минимальное количество русских символов нижнего регистра

Шаг 3.5. Пример! Задаём «адскую» политику для ИБ-отдела

Теория — хорошо, но давайте соберём реальный профиль, от которого у отдела информационной безопасности случится мимиметрика. Создадим политику для сотрудников ИБ с максимальными требованиями к составу пароля.

Предположим, мы уже создали базовую PSO IT-Security-PSO с приоритетом 1 и стандартными параметрами (длина 14, сложность включена). Теперь расширим её до ePSO и зададим расширенные требования:

Расширяем существующую PSO до ePSO

samba-tool domain passwordsettings pso extend IT-Security-PSO

Задаём расширенные параметры

samba-tool domain passwordsettings pso set IT-Security-PSO \

  --rs-min-special=2 \

  --rs-min-numeric=2 \

  --rs-min-upper-eng=1 \

  --rs-min-lower-eng=1 \

  --rs-min-upper-rus=1 \

  --rs-min-lower-rus=1 \

  --rs-min-unicode=0

Что получилось:

● Минимум 2 спецсимвола (!@#$% и т.д.)

● Минимум 2 цифры

● Минимум 1 заглавная английская буква

● Минимум 1 строчная английская буква

● Минимум 1 заглавная русская буква

● Минимум 1 строчная русская буква

● Unicode не требуем

Итоговый пароль должен быть не менее 14 символов и содержать минимум 8 «обязательных» символов из разных категорий. Остальные 6 — на усмотрение пользователя.

Применяем политику на группу (не забываем, что PSO можно вешать и на группы, а не только на отдельных пользователей):

samba-tool domain passwordsettings pso apply IT-Security-PSO "IT-Security-Group"

Важный нюанс: если вы задаёте rsSecPassComplMinUnicode больше 0, убедитесь, что ваши клиенты и консоли поддерживают ввод Unicode-символов. Иначе пользователи физически не смогут набрать пароль на стандартной английской раскладке.

Шаг 4. Доверяем, но проверяем

Самая обидная ошибка — настроить политику, применить её, а потом выяснить, что пользователь спокойно ставит пароль 12345678. Проверяем в три этапа.

Этап 1. Смотрим, что применилось

samba-tool domain passwordsettings pso show IT-Security-PSO

В выводе должны быть все наши параметры, включая блок rsSecPassCompl*. Если их нет — значит, вы забыли выполнить pso extend перед pso set.

Пробуем сменить пароль от имени пользователя, на которого навешена политика, через стандартный механизм (Ctrl+Alt+Del на клиенте RED OS или passwd в терминале):

Этап 2. Пробуем сменить пароль на заведомо неподходящий

passwd ivanov

Вводим: Password1!

Система отвергнет пароль, потому что:

● нет 2 спецсимволов (только 1 — !)

● нет русских букв

● нет 2 цифр

В логе контроллера домена (/opt/reddc/var/log.samba) появится:

Constraint violation - check_password_restrictions: Password does not meet complexity requirements rsSecPassCompl!

Этап 3. Теперь пробуем корректный пароль

Пример валидного пароля: МойПароль!4221#Red

Если пароль принят — поздравляем, ePSO работает. Если отвергнут — проверяем, точно ли применена ePSO, а не стандартная PSO, и не забыл ли пользователь про русские буквы.

Если пользователь не будет соблюдать парольную политику, в логе RED DC появятся строчки:

Constraint violation - check_password_restrictions: Password does not meet complexity requirements rsSecPassCompl!

Важно: расширение схемы — точка невозврата

Прежде чем запускать samba-tool schema extend rsSecPassCompl на боевом домене, прочитайте это три раза.

Расширение схемы Active Directory — необратимая операция. Новые атрибуты rsSecPassCompl* пропишутся в каталоге навсегда. Да, они не сломают репликацию с Windows AD (он их просто проигнорирует), но откатить схему назад штатными средствами Samba невозможно.

Что делать до боевого применения:

Тестовый стенд. Разверните отдельный домен RED ADM (можно на виртуалках), повторите все шаги расширения, создания PSO и ePSO.

Убедитесь, что:

● расширение проходит без ошибок

● репликация между контроллерами не нарушается

● клиенты RED OS корректно обрабатывают новые требования при смене пароля

● Windows-клиенты в смешанном домене не ломаются (если у вас гетерогенная среда)

Бэкап каталога. Перед расширением схемы на боевом сервере сделайте офлайн-бэкап:

samba-tool domain backup offline

Или снимите снапшот ВМ, если контроллер виртуальный.

Практические рекомендации

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

Не забудьте про стандартные политики! ePSO не отменяет базовые парольные настройки домена — они работают совместно. Если какой-то параметр не задан в PSO, применяется доменное значение.

Тестируйте на выделенной УЗ. Прежде чем раскатывать строгие требования на всех администраторов, проверьте работу политики на тестовой учётной записи. Неправильно настроенный min-pwd-age или max-pwd-age может заблокировать смену пароля в критический момент.

Учитывайте логику. Проверка парольных политик происходит в момент смены пароля пользователем. Если вы выполните команду samba-tool user setpassword <user>, система установит заданный пароль в обход ограничений ePSO, так как административные действия обладают наивысшими привилегиями в домене.

Учитывайте гетерогенную среду. Если у вас доменная инфраструктура содержит как Windows контроллеры домена, так и Linux, то система ePSO будет работать только на контроллерах RED DC, так как данный функционал проверки не будет проверяться в   MS AD. Так как это просто расширение схемы, то на репликации это никак не скажется. MS AD будет просто игнорировать данные параметры.

Заключение

Теперь вы научились создавать усложнённые парольные политики с помощью РЕД АДМ. Можно гибко регулировать требования в зависимости от роли пользователя и требований со стороны ИБ-специалистов. В качестве дополнительных мер по обеспечению безопасности можете обратить внимание на механизм LoginFrom — ограничивает доступ к инфраструктуре по источнику подключения и тоже появился в релизе 2.1.