Модуль 6. Управление политиками ALD Pro. Часть первая. Password, HBAC, SUDO.
Введение
В этом модуле мы обсудим, политику паролей, политики доступа к узлу и политики повышения привилегий из состава службы каталога FreeIPA. Разработчики FreeIPA решили сосредоточиться в большей степени на задачах аутентификации и авторизации, поэтому в части политик предлагают ограниченный набор параметров, имеющих прямое отношение к вопросам безопасности. Мы сравним техническую реализацию политик MS AD с политиками FreeIPA и ALD Pro, выполним настройку и отладку политик с использованием параметров, доступных из коробки.
Кроме того, мы узнаем об интересной возможности FreeIPA - группах с автоматическим участием.
Политики паролей
Пароль представляет собой набор символов, который должен быть известен только самому пользователю и проверяющей стороне, поэтому, если пользователь может предъявить доказательство того, что пароль ему известен, это является подтверждением аутентичности пользователя, что он именно тот, за кого себя выдает.
Пароли являются самым простым, но при этом не самым безопасным способом аутентификации, так как их можно подобрать или перехватить, а если не устанавливать дополнительных ограничений по длине и сложности, то каждый двадцатый сотрудник в организации окажется счастливчиком, который угадает комбинацию из Топ-100, типа, 123456, password или qwerty.
Совокупность требований к паролям называют также политиками паролей, и чем строже эти требования, тем сложнее злоумышленнику подобрать пароль и воспользоваться результатами успешной атаки, но вместе с тем сложнее и пользователям работать в таком домене. Поэтому для разных категорий пользователей следует устанавливать разные требования, обеспечивающие баланс между удобством и безопасностью. И в этом вопросе главное — достичь компромисса с ИБ, поскольку, как известно, если жена хочет на море, а муж — в горы, то все едут загорать, но главе семейства разрешают взять с собой лыжи.
Изменить пароль можно по протоколу KPASSWD (464/TCP), через расширенную операцию LDAP+StartTLS (389/TCP) и просто записью нового значения в атрибут userPassword, опять же, по протоколу LDAP. Однако вне зависимости от того, какой способ будет выбран, на сервер передается именно сам пароль, а не его хеш. Это позволяет проверить длину пароля, сложность и другие параметры, после чего сгенерировать и сохранить совместимые хеши.
Политики паролей Windows
Раньше в домене Active Directory можно было задать только одну политику паролей через объект групповой политики Default Domain Policy. Да, вы можете создать несколько объектов и в каждом из них определить параметры из секции Password Policy, но ко всем пользователям в домене все равно будут применяться только те требования, которые определены в Default Domain Policy («Костыль?» — спросите вы. Не, ну в продуктах Microsoft такого не может быть!).
рис. 296 Политика паролей по умолчанию (Default Domain Policy)
Начиная с Windows Server 2008, в MS AD появились так называемые детальные политики паролей (Fine-Grained Password Policy, FGPPs), которые настраиваются в Центре администрирования Active Directory (Active Directory Administrative Center) путем создания контейнера настроек пароля (Password Settings Container). Каждый контейнер может быть назначен конкретным пользователям и группам, переопределяя их требования к паролям.
Следует обратить внимание также на атрибут Precedence, который определяет приоритет данной политики паролей. Если на пользователя AD действуют несколько политик, то к нему будет применена политика с меньшим значением приоритета.
рис. 297 Детальная политика паролей (Fine-Grained Password Policy, FGPPs)
Политики паролей FreeIPA
В службе каталога FreeIPA политики паролей устроены очень похожим образом: есть глобальная политика по умолчанию и можно создавать дополнительные политики для отдельных групп пользователей. Учитывая то, что пользователь может входить сразу в несколько групп, алгоритм проверки выглядит следующим образом:
Из контейнера «cn=cosTemplates,cn=accounts» отбираются шаблоны, под действие которых попадает текущий пользователь в соответствии с его участием в группах.
В этих записях содержится минимальное количество информации, а расширенные наборы параметров представлены в контейнере «cn=kerberos» и связаны с шаблонами ссылками через значение атрибута krbPwdPolicyReference.
Если на пользователя не распространяется действие ни одной политики, ему будет назначена глобальная политика (global_policy) по умолчанию, см. рис. 298
Если пользователь попадает под действие сразу нескольких политик, то параметры политик не суммируются, а выбирается одна из них, приоритет которой будет иметь наименьшее значение, см. табл. 26, что аналогично действию параметра Precedence в политиках паролей Windows.
рис. 298 Запись глобальной политики паролей в LDAP-каталоге
Параметр |
Политика для группы А(приоритет 0) |
Политика для группы В(приоритет 1) |
Результат (используются параметры для группы А, приоритет 0) |
|---|---|---|---|
Максимальный срок действия пароля |
60 дней |
90 дней |
60 дней |
Минимальная длина пароля |
10 символов |
0 символов (без ограничений) |
10 символов |
Проверка паролей неограничены возможностями MIT Kerberos, поэтому они поддерживают как стандартный набор параметров (см. табл. 27), так и дополнительный (см. табл. 28)
Параметр глобальной политики |
Значение по умолчанию |
|---|---|
Максимальный срок действия задает период в количестве секунд, в течение которого система не будет требовать смены пароля |
Пароль активен 90 дней, после чего пользователю будет предложено сменить его. |
Минимальный срок действия задает период в секундах, в течение которого система будет запрещать повторную смену пароля |
После смены пароля пользователь должен подождать 1 час перед повторной сменой. |
Размер журнала определяет количество предыдущих паролей, которые нельзя использовать повторно |
Запрет на повторное использование паролей не налагается. |
Количество классов символов – это параметр, который определяет требование по сложности пароля, указывая сколько разных классов символов должно быть использовано в пароле: цифры; буквы нижнего регистра; буквы верхнего регистра; символы UTF-8; все остальные символы, не вошедшие ни в одну из предыдущих групп, например, ! « # $ % и т.д. При использовании одного и того же символа более двух раз подряд сложность пароля будет занижена на один балл. Например, если сложность пароля «Secret1pwd» будет оценена в три балла (большие буквы + маленькие буквы + цифры), то для пароля «Secret111pwd» сложность снизится до двух баллов (минус один балл за повторы символа «1»). |
Требований по сложности пароля по умолчанию нет. Интересный факт, что при подсчете повторов последний символ в пароле не учитывается, поэтому если повторяющиеся символы будут идти в конце строки, то нужно, чтобы их было не меньше четырех «Secretpwd1111», иначе штраф налагаться не будет. |
Минимальная длина задает минимально допустимое количество символов в пароле. |
Пользователь не может использовать пароль короче 8 символов. |
Максимальное количество ошибок определяет, сколько раз пользователь может неправильно ввести пароль, прежде чем его учетная запись будет временно заблокирована. Блокировка выполняется только на текущем контроллере, на другие сервера эта информация не передается. |
Пользователь будет временно заблокирован после 7 неверно введенных паролей подряд. Срок блокировки указан в параметре |
Интервал сброса ошибок задает период в секундах, по истечении которого счетчик неудачных попыток входа будет сброшен. |
Если пользователь выждет 1 минуту после 6 неудачных попыток введения пароля, то счетчик неудачных попыток обнулится. |
Длительность блокировки задает период в секундах, в течение которого пользователь не сможет выполнить аутентификацию в домене. Блокировка накладывается после превышения количества разрешенных неудачных попыток входа. Блокировка выполняется только на текущем контроллере, на другие сервера эта информация не передается. |
Временно заблокированный пользователь не сможет осуществить вход в систему в течение последующих 10 минут. |
Следствием интеграции с MIT Kerberos является возможность использования таких атрибутов, как krbPrincipalExpiration и krbLastSuccessfulAuth. Например, с помощью команды ipa user-mod вы можете установить срок действия учетной записи, после которого пользователю станет недоступна Kerberos-аутентификация:
admin@dc-1:~$ ipa user-mod alexander.kuznetsov \
--principal-expiration='20330725115110Z'
Где срок действия учетной записи задается в формате временной метки GeneralizedTime:
2033 – год;
07 – месяц;
25 – день месяца;
115110 – часы, минуты, секунды;
Z – часовой пояс по нулевому (Zero) меридиану.
Примечание
Стоит заметить, что по соображениям повышения производительности работы домена фиксация даты последнего входа по умолчанию отключена и этот атрибут исключен из репликации.
Однако, если у вас достаточно вычислительных ресурсов и хорошие каналы связи, то вы можете включить эти функции изменением конфигурации сервера. Для этого потребуется посмотреть текущие настройки и установить новое значение параметра ipaconfigstring, исключив из него значение «KDC:Disable Last Success»:
admin@dc-1:~$ ipa config-show | grep паролей
Возможности подключаемого модуля паролей: AllowNThash, KDC:Disable Last Success
admin@dc-1:~$ ipa config-mod --ipaconfigstring='AllowNThash'
Максимальная длина имени пользователя: 32
Максимальная длина имени хоста: 64
Основа домашних каталогов: /home
Оболочка по умолчанию: /bin/bash
Группа пользователей по умолчанию: ipausers
Почтовый домен по умолчанию: ald.company.lan
Ограничение времени поиска: 5
Ограничение размера поиска: 500
Поля поиска пользователей: uid,givenname,sn,telephonenumber,ou,title
Поля поиска групп: cn,description
Включить режим миграции: FALSE
Основа субъекта сертификата: O=ALD.COMPANY.LAN
Уведомление об окончании действия пароля (в днях): 4
Возможности подключаемого модуля паролей: AllowNThash
Порядок применения списка пользователей SELinux: guest_u:s0$xguest_u:s0$user_u:s0$staff_u:s0-s0:c0.c1023$sysadm_u:s0-s0:c0.c1023$unconfined_u:s0-s0:c0.c1023
Пользователь SELinux по умолчанию: unconfined_u:s0-s0:c0.c1023
Типы PAC по умолчанию: MS-PAC, nfs:NONE
Главные IPA-серверы: dc-1.ald.company.lan
Главный IPA-сервер с поддержкой PKINIT: dc-1.ald.company.lan
DNS-серверы IPA: dc-1.ald.company.lan
admin@dc-1:~$ sudo ipactl restart
[sudo] пароль для admin:
Restarting Directory Service
Restarting krb5kdc Service
Restarting kadmin Service
Restarting named Service
Restarting httpd Service
Restarting ipa-custodia Service
Restarting smb Service
Restarting winbind Service
Restarting ipa-otpd Service
Restarting ipa-dnskeysyncd Service
ipa: INFO: The ipactl command was successful
admin@dc-1:~$ kinit admin
Password for admin@ALD.COMPANY.LAN:
admin@dc-1:~$ ipa user-show admin --all --raw | grep krbLastSuccessful
krbLastSuccessfulAuth: 20241009095204Z
Начиная с версии ALD Pro 3.0.0 в политике паролей появилась возможность использовать дополнительные проверки:
Параметры дополнительной проверки |
Значение по умолчанию |
|---|---|
Использовать список запрещенных слов определяет необходимость проверки пароля по списку запрещённых слов |
Проверка по умолчанию отключена. Создание или изменение пароля будет завершаться ошибкой, если в составе любой подстроки нового пароля будет использовано любое слово из списка запрещённых. |
Проверять совпадение с логином не позволит использовать логин в пароле. |
Проверка по умолчанию выключена. Создание или изменение пароля будет завершаться ошибкой, если в составе любой подстроке нового пароля будет использован логин пользователя. Проверка не чувствительна к регистру. |
Минимум заглавных определяет минимальное количество заглавных символов в пароле. |
Отсутствуют требования к наличию заглавных символов в пароле при условии, что стоит соотвествующий параметр |
Минимум строчных определяет минимальное количество строчных символов. |
Отсутствуют требования к наличию строчных символов в пароле при условии, что стоит соотвествующий параметр |
Минимум цифр определяет минимальное количество цифр. |
Пароль может не содержать цифры при условии, что стоит соотвествующий параметр |
Максимум повторений подряд определяет максимальное количество повторений одного и того же символа. |
Пароль может содержать любое количество повторений. Например, |
Максимум монотонной последовательности определяет максимальное количество символов убывающих или возрастающих строго по порядку. |
Требований по монотонности пароля по умолчанию нет. Монотонной считается последовательность букв или цифр, которые убывают, либо возрастают п опорядку, например, «ABCDEF» или «98765432». При определении максимума монотонной последовательности учитываются все символы кроме первого, т.е в последовательности «АБВ» максимум равняется 2. |
Максимум одного класса подряд определяет максимальное количество символов одного класса подряд. |
Требований по количеству символов одного класса подряд по умолчанию нет. При подсчёте повторений подряд учитываются все символы кроме первого, т.е. в последовательности «aaa» всего 2 повторения. |
Примечание
До версии ALDPro 3.0.0 первый пароль, назначаемый администратором при создании учётной записи пользователя, считался временным, поэтому мог быть установлен в обход политики паролей, распространяющей своё действие на пользователя. По такойже логике происходил сброс пароля пользователя администратором. Начиная с версии 3.0.0 пароли, устанавливаемые администраторами, проходят обязательную проверку на соответствие политике паролей.
Исключения составляют:
Смена пароля пользователя от имени суперпользователя LDAP-каталога cn=Directory Manager
Смена пароля пользователя от имени root-пользователя командой
ipa-getkeytabс ключом-pСоздание/сброс пароля пользователя от имени пользователя, который является членом группы
passSyncManagersDNs(соответствующий атрибут имеет конфигурационный файл плагина 389ds -ipa_pwd_extop)Настройка
Минимальный срок действияполитики не учитывается при сбросе пароля пользователем, имеющим необходимые привилегии.
Настройка политики паролей
Требования глобальной политики довольно лояльны, поэтому для группы администраторов их целесообразно сделать строже. Рассмотрим два способа создания политики: через портал управления и через командную строку.
Откройте страницу и нажмите кнопку . В поле «Наименование группы пользователей» выберите admins, установите наименьший «Приоритет», равный 0, и нажмите кнопку Сохранить. Далее вам станет доступна страница управления политикой, где вы можете задать необходимые настройки, как на нижеприведенных иллюстрациях.
рис. 299 Создание новой политики паролей, проверки Kerberos
рис. 300 Создание новой политики паролей, дополнительные проверки
Примечание
При переходе с ранних версий ALD Pro на версию 3.0.0 схема данных расширена двумя новыми классами aldpro-pwd-policy и ipaPwdPolicy, позволяющими настраивать дополнительные параметры политик. Если политика уже существовала, необходимые атрибуты будут добавлены автоматически. Однако при создании новой политики с помощью командной строки необходимо сперва добавить новые классы --addattr="objectClass=aldpro-pwd-policy" и --addattr="objectClass=ipaPwdPolicy", в противном случае политика не будет отображаться в веб-интерфейсе ALD Pro. Данная особенность будет устранена в следующем релизе ALD Pro.
Политику паролей можно создать из командной строки, для этого воспользуемся ключом --addattr команды ipa pwpolicy-add,который также используется при добавлении атрибутов, соответствующих дополнительным проверкам. При использовании ключа --addattr его аргумент передаётся в формате атрибут=значение:
admin@dc-1:~$ ipa pwpolicy-add admins --priority=0 \
--addattr="objectClass=aldpro-pwd-policy" --addattr="objectClass=ipaPwdPolicy" \
--addattr="ipaPwdMaxRepeat=3" --addattr="ipaPwdMaxSequence=3" --addattr="aldproBadWordsCheck=TRUE" \
--addattr="ipaPwdUserCheck=TRUE" --addattr="aldproDigCredit=2" --addattr="aldproUpCredit=2" \
--addattr="aldproLowCredit=2" --addattr="aldproMaxClassRepeat=5" --maxlife=45 \
--minlife=0 --history=12 --minclasses=5 --minlength=12 \
--maxfail=3 --failinterval=120 --lockouttime=1200
Группа: admins
Максимальный срок действия (в днях): 45
Минимальный срок действия (в часах): 0
Размер журнала : 12
Классы символов: 5
Минимальная длина: 12
Приоритет: 0
Максимальное количество ошибок: 3
Интервал сброса ошибок: 120
Длительность блокировки: 1200
Где:
Ключ
--maxlife=<число>— максимальный срок действия в днях;Ключ
--minlife=<число>— минимальный срок действия в часах;Ключ
--history=<число>— размер журнала;Ключ
--minclasses=<число>—классы символов;Ключ
--minlength=<число>— минимальная длина;Ключ
--priority=<число>— приоритет политики;Ключ
--maxfail=<число>— максимальное количество ошибок;Ключ
--failinterval=<число>— интервал сброса ошибок в секундах;Ключ
--lockouttime=<число>— длительность блокировки в секундах.
Изменить параметры уже существующей политики можно командой ipa pwpolicy-mod. Увеличим интервал сброса ошибок для политики группы admins с 120 до 3600 секунд, но уменьшим длительность блокировки с 1200 до 300 секунд:
admin@dc-1:~$ ipa pwpolicy-mod admins --failinterval=3600 --lockouttime=300
Группа: admins
Максимальный срок действия (в днях): 45
Минимальный срок действия (в часах): 0
Размер журнала : 12
Классы символов: 5
Минимальная длина: 12
Приоритет: 0
Максимальное количество ошибок: 3
Интервал сброса ошибок: 3600
Длительность блокировки: 300
Обратите внимание, что изменение максимального срока действия пароля сразу же ни на что не повлияет, т.к. проверка выполняется по значению пользовательского атрибута krbPasswordExpiration, которое устанавливается в момент смены пароля. Текущее значение этого атрибута можно уточнить командой ipa user-show:
admin@dc-1:~$ ipa user-show admin --raw --all | grep krbPasswordExpiration
krbPasswordExpiration: 20240414095400Z
Таким образом, чтобы изменения в части срока действия паролей вступили в силу, пользователь должен хотя бы один раз сменить свой пароль, но при необходимости вы можете установить значение krbPasswordExpiration вручную с помощью команды ipa user-mod. Это удобно также в тех случаях, когда вам нужно сбросить пользователю пароль, но вы не хотите, чтобы система сразу же требовала смены пароля.
admin@dc-1:~$ ipa user-mod admin --password-expiration 20270301010101Z
----------------------------
Изменён пользователь "admin"
----------------------------
Имя учётной записи пользователя: admin
Фамилия: Administrator
Домашний каталог: /home/admin
Оболочка входа: /bin/bash
Псевдоним учётной записи: admin@ALD.COMPANY.LAN, root@ALD.COMPANY.LAN
Окончание действия пароля пользователя: 20240701010101Z
UID: 1902000000
ID группы: 1902000000
Учётная запись отключена: False
Link to department: ou=ald.company.lan,cn=orgunits,cn=accounts,dc=ald,dc=company,dc=lan
Link to head department: ald.company.lan
Пароль: True
Участник групп: trust admins, ald trust admin, admins, lpadmin
Роли: ALDPRO - Main Administrator
Доступные ключи Kerberos: True
Одной из функций политик паролей является список запрещенных слов. При создании или изменении пароля пользователя функция выполняет проверку вхождения слов списка в состав любой подстроки текста пароля. «Подстрокой» считается непустая связанная часть строки.
Если вхождение запрещённого слова в состав пароля обнаружено, такой пароль не пройдёт проверку на соответствие политике. Проверка вхождения игнорирует регистр символов и запрещённые слова короче четырёх символов. Список запрещённых слов одинаков для всей системы, при этом включение и отключение функции проверки паролей по списку индивидуально настраивается в карточке политики паролей с помощью переключателя «Использовать список запрещённых слов».
Просмотр и управление списком осуществляются на странице .
рис. 301 Список запрещенных слов
Список хранится в виде строки в реплицируемом атрибуте aldproBadWords, который хранится в контейнере c DN cn=ALD.COMPANY.LAN,cn=kerberos,dc=ald,dc=company,dc=lan и по умолчанию содержит несколько распространённых паролей, но может быть просмотрен и изменён при наличии необходимых привилегий: Password Policies Read и Password Policies Modify.
Также доступен функционал скачивания списка в локальный файл и загрузки списка из текстового файла, подготовленного заранее локально. Файл должен содержать слова, разделённые как минимум одним пробельным символом, а его размер не должен превышать 2 Мб. Рекомендуется использовать файлы в кодировке UTF-8, форматов .odt, .txt, .rtf, .doc, .docx.
Примечание
C помощью утилиты ldapmodify из пакета ldap-utils из командной строки возможна полная замена списка запрещенных слов.
Политики доступа к узлу (HBAC-правила)
Только представьте себе: новому сотруднику с задатками пентестера выдают ноутбук, блокнот, кружку и доменную учетную запись, а он вместо того, чтобы пойти за кофе, начинает сразу же ломиться на серверы по всем доступным протоколам. И если системный администратор не подумает об этом сценарии заранее, то пользователь прорвется на сервер, а далее останется уповать только на правильные настройки доступа к объектам файловой системы.
Чтобы предотвратить подобного рода атаки, можно ограничить доступ к серверам по определенным протоколам из пользовательского сегмента сети, но лучше полностью запретить обычным пользователям интерактивный вход на серверы.
Политика локального входа Windows
В домене Active Directory управлять правами локального входа в систему можно с помощью двух параметров групповых политик, которые находятся в разделе в подразделе ( и ):
Allow log on locally (Локальный вход в систему) — определяет список пользователей и групп, которым разрешен локальный вход в систему.
Deny log on locally (Запретить локальный вход) — определяет список пользователей и групп, которым запрещен локальный вход в систему. Если пользователь попадает под действие двух параметров сразу, то запрещающий параметр имеет больше приоритет, поэтому доступ будет заблокирован.
На контроллеры домена AD интерактивно могут заходить только пользователи шести административных групп, что определено параметрами объекта групповой политики Default Domain Controllers Policy, см. рис. 302.
рис. 302 Настройки параметра Allow log on locally в объекте групповой политики Default Domain Controllers Policy
Политики доступа к узлу FreeIPA
Для ограничения доступа к компьютерам в домене FreeIPA есть мощные правила управления доступом к хостам (от англ. host-based access control, HBAC), которые значительно превосходят по функциональности политики локального входа Windows. Они создают дополнительный слой авторизации, позволяя разрешить определенным пользователям использовать указанные службы на конкретных хостах.
Что такое «пользователи» и «хосты», обычно вопросов не вызывает, но понятие «служб» требует дополнительных пояснений. В контексте правил HBAC службами являются любые приложения, которые используют PAM-стек, и при этом не важно, являются ли эти приложения просто исполняемыми файлами или работают как демоны в фоновом режиме.
Как мы уже знаем, библиотека подключаемых модулей аутентификации (от англ. Pluggable Authentication Modules, PAM) обеспечивает унифицированный программный интерфейс для абстрагирования приложений (таких как login, sshd или sudo) от выполнения стандартных задач аутентификации.
Перечень необходимых модулей аутентификации для каждого приложения задается индивидуально с помощью конфигурационных файлов из директории /etc/pam.d, поэтому настройки могут быть изменены в любой момент, что не потребует повторной компиляции приложения. За обработку правил HBAC, например, отвечает модуль pam_sss.so, который является одной из клиентских библиотек службы sssd, обеспечивающей работу хоста в домене. Механизм работы правил HBAC отражен на рисунке рис. 303.
При подключении пользователя по ssh служба sshd обращается к библиотеке PAM, чтобы создать контекст безопасности для выполнения команд от имени этого пользователя. При вызове функции «pam_start» служба передает библиотеке свой идентификатор (PAM service name), который представляет собой простую строку, например, «sshd». Идентификатор службы обычно совпадает с именем исполняемого файла, но это не является обязательным условием, а некоторые приложения могут использовать даже несколько идентификаторов, например, утилита sudo может применять дополнительный идентификатор sudo-i. Идентификатор службы определяет имя файла из каталога pam.d, откуда библиотека PAM будет брать настройки стека модулей (например, для службы sshd настройки будут из файла /etc/pam.d/sshd).
Для вступления в силу изменений в настройках HBAC-правил вы можете воспользоваться на целевой машине командами sss_cache -E или sssctl cache-remove, входящие в пакет sssd-tools, чтобы очистить локальный кэш службы sssd. Пакет sssd-tools по умолчанию не установлен.
И, наверно, стоит заметить, что в разных дистрибутивах Linux приложения могут использовать разные идентификаторы, например, ssh и sshd, поэтому список служб нужно будет расширять в соответствии с тем, какие операционные системы с каким программным обеспечением используются в инфраструктуре вашего предприятия.
рис. 303 Механизм работы HBAC-правил
Еще один важный момент. В силу особенностей FreeIPA в правилах HBAC не получится использовать следующие группы:
группу пользователей ipausers, т.к. у нее нет POSIX-идентификатора, и поэтому на целевых хостах служба SSSD не отображает участие пользователей в этой группе;
группу хостов ipaservers, т.к. у нее нет класса mepManagedEntry и соответствующих зависимостей.
Самый простой способ обойти указанные проблемы – это создать вспомогательные группы posix-ipausers/posix-ipaservers и сделать группы ipausers/ipaservers их участниками. В этом случае можно использовать вспомогательные группы в политиках без ограничений.
Настройка политик доступа к узлу
Ограничиваем доступ к серверам
Как мы уже отметили, правила HBAC являются «разрешающими», т. е. «по умолчанию» доступ к службам на доменных компьютерах запрещен, и его нужно открывать с помощью правил. Однако при развертывании домена автоматически создается правило allow_all, которое разрешает доступ «всех ко всему», поэтому для управления авторизацией на уровне HBAC нам нужно сначала ограничить область применения этого правила, например, только группой администраторов.
Внести указанные настройки можно через веб-портал управления на странице , см. рис. 304, или через командную строку:
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 — имя правила, по которому мы хотим получить информацию;
рис. 304 Настройка HBAC-правила allow_all.
Примечание
Если из-за неправильной настройки HBAC-правил доступ к хостам будет все же заблокирован, вы сможете подключиться к порталу управления с любого другого компьютера, который не находится в домене, чтобы исправить ошибку. Доступ к порталу управления не регулируется через механизм HBAC-правил.
Если ограничить область действия правила allow_all группой администраторов, то для остальных сотрудников компании нужно будет создать правило allow_computers, которое предоставит им право входа на обычные компьютеры в домене.
Сделаем все из командной строки:
admin@dc-1:~$ ipa hostgroup-add computers # создание группы компьютеров
admin@dc-1:~$ ipa hostgroup-mod computers --desc='Группа, в которой будут все обычные компьютеры домена' # описание
admin@dc-1:~$ ipa hostgroup-add-member computers --hosts pc-1 # включение в группу хоста pc-1
admin@dc-1:~$ ipa hbacrule-del allow_computers # удаление созданного ранее HBAC-правила
admin@dc-1:~$ ipa hbacrule-add allow_computers # создание HBAC-правила
admin@dc-1:~$ ipa hbacrule-mod allow_computers --desc='Разрешает всем пользователям доступ к обычным компьютерам в домене' # описание
admin@dc-1:~$ ipa hbacrule-mod allow_computers --usercat=all # установить область применения на всех пользователей
admin@dc-1:~$ ipa hbacrule-mod allow_computers --servicecat=all # установить область применения на все службы
admin@dc-1:~$ ipa hbacrule-add-host allow_computers --hostgroup computers # назначить правило на группу хостов
Где:
Команда
ipa hbacrule-add— создает HBAC-правила;Команда
ipa hbacrule-mod— модифицирует правила, ключ--descпозволяет задать описание;Команда
ipa hbacrule-add-host— команда позволяет определить область применения правила;Ключ
--hostgroups— позволяет указать группу хостов.
Убедимся, что пользователь iivanov в данный момент имеет право входить на компьютер pc-1.
Войдем пользователем iivanov на компьютер pc-1 в режиме рабочего стола.
После успешного входа сменим сессию на пользователя 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, см. табл. 29:
Сценарий работы пользователя |
К каким идентификаторам служб следует предоставить доступ |
|---|---|
Локальный вход в систему |
fly-dm |
Удаленный доступ к менеджеру окон по протоколу RDP |
fly-wm, xrdp-sesman |
Удаленное администрирование по протоколу SSH |
sshd, sudo |
Чтобы понять, к какой службе требуется предоставить доступ, проще всего выполнить необходимое действие на целевой системе и посмотреть, какие сообщения об ошибках появятся в журнале /var/log/auth.log. На приведенном ниже примере видно, что пользователю не хватает прав на запуск sshd:
root@pc-1:~# tail -f /var/log/auth.log
...
Mar 15 15:25:22 client 4 sshd[30424]: pam_sss(sshd:account): Access denied
for user alexander.kuznetsov: 6 (Permission denied)
...
После развертывания домена в системе уже есть список наиболее распространенных служб, но какие-то службы нам все равно потребуется добавить вручную. Давайте создадим «xrdp-sesman». Сделать это можно через веб-интерфейс на странице , см. рис. 305, или из командной строки:
admin@dc-1:~$ kinit admin
admin@dc-1:~$ ipa hbacsvc-add 'xrdp-sesman' --desc='Доступ по RDP'
рис. 305 Добавление служб HBAC в интерфейсе портала управления ALD Pro
Допустим, нам нужно предоставить возможность разработчикам из группы 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-правила)
Хорошо известно, что безопасники плохого не посоветуют, но и хорошего не разрешат, но для установки программного обеспечения и выполнения других задач администрирования сотрудникам все же необходимы привилегии суперпользователя.
Для этих целей можно, конечно, использовать привилегированную учетную запись, но из соображений безопасности рекомендуют все же работать из-под обычной учетной записи и повышать привилегии только при выполнении отдельных команд. Еще более востребован указанный подход, когда часть административных прав нужно делегировать обычным пользователям, например, чтобы разрешить им перезапуск служб.
Запуск от имени другого пользователя в Windows
В операционной системе Windows запустить приложение от имени другого пользователя проще всего, если кликнуть по файлу правой кнопкой мыши, удерживая Shift, и выбрать в контекстном меню . Того же эффекта можно достичь утилитой runas.exe и командлетом Start-Process с параметром -Verb RunAs. Но во всех этих случаях мы получаем функциональность, аналогичную возможностям утилиты su, поэтому нам потребуется передать пользователю пароль от привилегированной учетной записи.
Совсем недавно в Microsoft объявили о релизе утилиты sudo для Windows, которая в отличие от runas поддерживает запуск программ из-под администратора с применением механизма UAC (User Account Control) для верификации запроса, т. е. без запроса пароля. Превратится ли она в продвинутый способ выполнения команд с повышенными привилегиями — будем посмотреть.
Политики повышения привилегий FreeIPA
Возможности Linux по повышению привилегий значительно шире. Кроме утилиты su и управляющих стики-битов с незапамятных времен существовала утилита sudo, которая имеет очень богатые настройки и позволяет логировать неудачные попытки аутентификации.
Например, вызовом следующей команды обычный пользователь может установить приложение htop, если ему разрешено запускать утилиту apt через sudo:
iivanov@dc-1:~$ sudo apt install htop
Правила SUDO можно определить не только в локальном файле /etc/sudoers, но и централизованно через службу каталога, создавая дополнительный слой авторизации, с помощью которого можно разрешить определенным пользователям на конкретных хостах выполнять отдельные команды с повышенными привилегиями.
В то время, как правила HBAC реализованы на уровне PAM-стека, правила SUDO проверяются непосредственно внутри утилиты sudo. Но обратите внимание, что утилита sudo в начале своей работы запускает PAM-контекст, поэтому, для того чтобы пользователь смог воспользоваться своими SUDO-правилами, ему нужно предоставить доступ в том числе к HBAC-службе sudo.
Мы уже рассматривали подробно утилиту sudo, ее правила и лучшие практики их использования в Модуль 10. Система аутентификации PAM и управление правами SUDO курса Часть 1. Astra Linux . Поэтому не будем подробно останавливаться на этом и сразу перейдем к особенностям работы правил SUDO в домене.
Список источников правил утилита sudo получает через библиотеку службы имен (Name Service Switch, NSS), настройки которой находятся в файле /etc/nsswitch.conf. Как мы знаем, в операционных системах Linux через этот механизм настраиваются источники для получения информации о пользователях, группах, DNS-записях и многом другом. Основные вызовы NSS реализованы в библиотеке libc, а та уже, в свою очередь, выполняет обращение к необходимым бэкендам, как показано на рис. рис. 306.
рис. 306 Архитектура диспетчера службы имен (Name Service Switch, NSS)
После установки freeipa-client в файле /etc/nsswitch.conf можно найти строку с настройкой базы данных /etc/sudoers. По умолчанию правила сначала берутся из локального файла, а затем через модуль sss, который отвечает за взаимодействие с LDAP-каталогом через службу SSSD.
admin@dc-1:~$ cat /etc/nsswitch.conf | grep sudoers
sudoers: files sss
Поддержка каталогов появилась в sudo c выходом модуля ldap для nss в 2004 году. Источником правил для модуля служили записи из DN «ou=sudoers,{basedn}=имя,{basedn}=домена,{basedn}=организации».
Модуль sudo работал с примитивной схемой хранения данных, которая повторяла синтаксис локального файла sudoers, игнорируя доступную в каталоге нормализацию данных, например, в части пользователей, групп и хостов. Поэтому при реализации поддержки правил SUDO разработчики FreeIPA создали новую схему, лишенную указанных недостатков. Информация о правилах SUDO во FreeIPA хранится в DN «cn=sudorules,cn=sudo,{basedn}=имя,{basedn}=домена,{basedn}=организации», и служба SSSD берет данные напрямую из этой ветки каталога.
Однако для обеспечения совместимости со старым модулем ldap служба каталога FreeIPA с помощью плагина Compat автоматически конвертирует настройки правил в старый формат, как показано на рисунке рис. 307. Например, если для правила в cn=sudorules установить ipaEnabledFlag=FALSE, то соответствующая запись в ou=sudoers будет автоматически удалена, но стоит вернуть атрибуту значение TRUE, и запись будет создана повторно.
рис. 307 Два источника правил SUDO для разных клиентов
Служба SSSD кэширует правила SUDO, что дает пользователям возможность повышать свои привилегии, даже если они не подключены к домену прямо сейчас. По умолчанию время кэширования составляет 5400 секунд, и для немедленного применения правил на клиентской машине можно выполнить удаление кэша, например, командой sudo sssctl cache-remove.
Настройка политики повышения привилегий
Создание правил SUDO
Давайте предоставим пользователям право на остановку и перезапуск служб с помощью утилиты systemctl на компьютерах, где они смогут выполнить интерактивный вход в систему.
Учитывая, что пользователи и хосты уже есть в домене, настройку правил следует начать с создания команды. Сделать это можно, например, через портал управления ALD Pro на странице , см. рис. 308, или из командной строки:
admin@dc-1:~$ kinit admin
admin@dc-1:~$ ipa sudocmd-add '/usr/bin/systemctl' --desc='Запуск systemctl'
Где:
Команда
ipa sudocmd-add– создает в системе новую команду SUDO.Параметр /usr/bin/systemctl – полный путь к утилите. Название команды может содержать разрешенные параметры вызова.
Ключ
--desc– позволяет задать описание команды.
рис. 308 Создание новой команды SUDO
Внимание
В названии команды можно использовать символы «a-z, A-Z, 0-9, -_./~» и пробелы (если только не в начале и конце строки).
Таким образом вы можете определить не только путь к утилите, но и параметры, с которыми вы разрешаете ее запускать. Например, можно разрешить только перезапуск службы sssd, если указать название команды как /usr/bin/systemctl restart sssd.service.
В тоже время интерфейс ALD Pro версии 2.4.0 не позволяет использовать символ «=» в названии правил SUDO. Если вам вдруг понадобятся такие команды, вы всегда сможете их создать через командную строку или веб-интерфейс FreeIPA.
После того, как команда готова, нужно создать правило SUDO и назначить с помощью этого правила команду на пользователей и компьютеры из веб-интерфейса, см. рис. 309, или из командной строки:
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.
рис. 309 Создание правила SUDO
Пройдем по основным параметрам правила:
Раздел Основные:
Порядок sudo (необязательный параметр) – целое число, которое определяет очередность выполнения правил. Чем больше значение, тем позже обрабатывается правило, а значит оно может переопределить те правила, которые стоят перед ним.
Если список команд содержит несколько значений, они обрабатываются в указанном порядке.
Если у правила одновременно заданы и разрешающие, и запрещающие команды, то сначала обрабатываются разрешающие.
Описание – необязательный комментарий к правилу.
Состояние – переключатель определяет, включено правило или нет.
Обязательно сохранить изменения до перехода к следующей вкладке, иначе изменения будут утеряны.
Вкладка Параметры:
С помощью параметров можно изменить поведение утилиты для ее тонкой настройки. Ниже приведено несколько наиболее востребованных параметров:
authenticate – с помощью этого флага можно обязать пользователей вводить пароль при выполнении команды через sudo. Параметр включен по умолчанию, и для отмены требования по вводу пароля его следует отключить, для чего нужно поставить восклицательный знак перед названием параметра «!authenticate».
passwd_tries – задает количество попыток ввода пароля, прежде чем sudo завершит работу и зарегистрирует ошибку. Задается в виде переменной, по умолчанию
passwd_tries=3.timestamp_timeout – задает количество минут, которое должно пройти перед тем, как sudo повторно запросит пароль. Если установить таймаут равным 0, то утилита будет запрашивать пароль всегда, если установить отрицательное значение, таймаут будет отключен и введенный ранее пароль будет храниться бессрочно. По умолчанию таймаут составляет 15 минут.
Информацию по остальным параметрам можно найти в
man sudoers. Значения по умолчанию, с которыми утилитаsudoбыла скомпилирована, можно узнать, вызвав команду sudo с ключом-Vпод суперпользователем, например,sudo sudo -V.
Внимание
Обратите внимание, что интерфейсе ALD Pro во вкладке «Параметры» не позволяет использовать символ «=». Если вам понадобится установить параметр, например, passwd_tries=2, вы всегда сможете его создать через веб-интерфейс FreeIPA.
Пользователи, компьютеры и команды назначаются так же, как для правил HBAC. На вкладке «Запуск от имени» вы можете указать пользователей и группы, от имени которых пользователь сможет запускать указанные команды, используя ключи -u и -g. Для того чтобы разрешить действовать от суперпользователя, следует оставить эту вкладку незаполненной.
Внимание
Обратите внимание, что в интерфейсе ALD Pro в версиях 2.2.0 и 2.3.0 в настройках правила не получится задать значение «любая команда». Если вы захотите не ограничивать пользователя списком команд, воспользуйтесь командой
ipa sudorule-mod 'Имя_правила' --cmdcat=all или веб-интерфейсом FreeIPA.
Проверка правил SUDO
Результирующий набор правил SUDO, который фактически применяется для конкретного пользователя на конкретном хосту, можно получить вызовом на целевой машине команды sudo с ключами -l (строчная L) и -U:
admin@dc-1:~$ sudo -l -U admin
Matching Defaults entries for admin on dc-1:
env_reset, mail_badpass,
secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin,
secure_path=/usr/lib/parsec/bin\:/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin
User admin may run the following commands on dc-1:
(ALL : ALL) ALL
(root) ALL
Для расширенного вывода информации можно использовать двойной ключ -ll. В таком случае вы сможете легко определить источник правил: локальный sudoers файл или правила из LDAP каталога:
admin@pc-1:~$ sudo -ll
Matching Defaults entries for admin on pc-1:
env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin, !lecture, 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 pc-1:
Sudoers entry:
RunAsUsers: ALL
RunAsGroups: ALL
Команды:
ALL
Роль LDAP: Allow_gpupdate_gp_moscow_computers
RunAsUsers: root
Команды:
aldpro-salt-call state.apply gpupdate.gp -c /srv/aldpro-salt/config/
В отладке правил вам также поможет журнал утилиты 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))'
Группы с автоматическим участием
Итак, мы познакомились с политиками FreeIPA. Для наглядности сведём политики и области их применения в сравнительную таблицу:
Политика |
Применяется к группам пользователей? |
Применяется к группам компьютеров? |
Краткое описание механизма применения |
|---|---|---|---|
Политика паролей |
Да (основной способ) |
Нет |
Назначается непосредственно на группу пользователей. Определяет требования к паролям для членов группы. |
Политика HBAC |
Да (обязательный компонент правила) |
Да (обязательный компонент правила) |
Создаётся правило, которое связывает:
|
Политика SUDO |
Да (обязательный компонент правила) |
Да (обязательный компонент правила) |
Создаётся правило, которое связывает:
Команды и права задаются внутри правила. |
Таким образом, все три механизма используют группы пользователей для определения целевой аудитории. Группы хостов используются только в HBAC- и SUDO-правилах, так как эти политики определяют допустимые действия в контексте конкретных систем.
Но что, если возникает необходимость применить эти политики к подразделениям? В этом случае нам помогут группы с автоматическим участием.
Привязка объектов к структурным подразделениям в ALD Pro осуществляется с помощью атрибута rbtadp, в котором хранится ссылка на целевое подразделение в формате полного уникального имени записи (от англ. Distinguished name, DN). Например, если у вас в корне домена есть структурное подразделение «Московский офис», то значение атрибута rbtadp всех дочерних объектов будет «ou=Московский офис,ou=ald.company.lan,cn=orgunits,cn=accounts,dc=ald,dc=company,dc=lan».
Если вам потребуется ограничить выборку только прямыми наследниками, вы можете поставить символ подстановки «^» в начало строки, что позволит вам исключить объекты из подразделений, расположенных ниже по иерархии организационной структуры.
Давайте создадим две группы с автоучастием. В одну будут попадать сотрудники московского офиса, в другую — казанского. Московский офис был создан в Модуль 3. Базовые функции и настройка ALD Pro с помощью веб-интерфейса. Казанский создадим сейчас из командной строки:
ipa orgunit-add Kazan --path=ou=ald.company.lan,cn=orgunits,cn=accounts,dc=ald,dc=company,dc=lan --desc="Казанский филиал" --displayname="Казань"
Создадим группу пользователей и правило автоучастия из веб-интерфейса:
Создайте группу пользователей. Для этого на странице нажмите кнопку , введите название группы «moscow-office-employees», выберите подразделение «Московский офис» и нажмите кнопку .
Создайте правило автоучастия. Для этого потребуется воспользоваться интерфейсом FreeIPA https://dc-1.ald.company.lan/ipa/ui. Откройте страницу , нажмите кнопку , см. рис. 311. В диалоговом окне добавления правила выберите группу «moscow-office-employees» из списка и нажмите кнопку .
рис. 310 Переход к списку правил автоучастия для групп пользователей
рис. 311 Создание правила автоучастия для группы moscow-office-employees
На странице редактирования добавьте критерий отбора по атрибуту rbtadp и значению «ou=Московский офис,ou=ald.company.lan,cn=orgunits,cn=accounts,dc=ald,dc=company,dc=lan», см. рис. 312. Не забудьте нажать кнопку «Сохранить».
рис. 312 Редактирование правила автоучастия для группы moscow-office-employees
Пересчет правил автоучастия происходит не мгновенно, но вы можете ускорить применение этих правил с помощью команды ipa automember-rebuild:
admin@dc-1:~$ ipa automember-rebuild --type=group
--------------------------------------------------------------------
Automember rebuild task finished. Processed (5) entries in 0 seconds
--------------------------------------------------------------------
admin@dc-1:~$ ipa group-show moscow-office-employees | grep "Пользователи"
Пользователи-участники: asidorov, ppetrov, iivanov, vsidorova
Если пользователи так и не появятся в списке участников группы, то необходимо проверить корректность фильтра. Обзор записей выполняется по полному вхождению, поэтому никаких лишних пробелов в середине строки быть не должно.
По тому же алгоритму создайте группу «kazan-office-employees» и назначьте для нее правило автоучастия. Значение атрибута rbtadp должно быть «ou=Kazan,ou=ald.company.lan,cn=orgunits,cn=accounts,dc=ald,dc=company,dc=lan».
Тоже самое можно сделать из командной строки:
Создать группу пользователей moscow-office-employees в подразделении «Московский офис» и группу пользователей kazan-office-employees в подразделении «Казань»:
ipa group-add moscow-office-employees
ipa group-mod moscow-office-employees --setattr="rbtadp=ou=Московский офис,ou=ald.company.lan,cn=orgunits,cn=accounts,dc=ald,dc=company,dc=lan"
ipa group-mod moscow-office-employees --desc='Группа, в которой будут все сотрудники московского офиса'
ipa group-add kazan-office-employees
ipa group-mod kazan-office-employees --setattr="rbtadp=ou=Kazan,ou=ald.company.lan,cn=orgunits,cn=accounts,dc=ald,dc=company,dc=lan"
ipa group-mod kazan-office-employees --desc='Группа, в которой будут все сотрудники казанского офиса'
Создать правила автоучастия и определить критерий автоучастия:
ipa automember-add moscow-office-employees --type=group
ipa automember-mod moscow-office-employees --type=group --desc='Правило автоучастия для наполнения группы сотрудников московского офиса'
ipa automember-add-condition moscow-office-employees --type=group --key=rbtadp --inclusive-regex='ou=Московский офис,ou=ald.company.lan,cn=orgunits,cn=accounts,dc=ald,dc=company,dc=lan'
ipa automember-add kazan-office-employees --type=group
ipa automember-mod kazan-office-employees --type=group --desc='Правило автоучастия для наполнения группы сотрудников казанского офиса'
ipa automember-add-condition kazan-office-employees --type=group --key=rbtadp --inclusive-regex='ou=Kazan,ou=ald.company.lan,cn=orgunits,cn=accounts,dc=ald,dc=company,dc=lan'
Принудительно обновить состав автоучастников (запускать команду нужно только 1 раз, в дальнейшем правила будут срабатывать автоматически изменении подразделения объекта):
ipa automember-rebuild --type=group
Теперь возьмём пользователя isemenov (он был создан в Модуль 4. Работа службы каталога ALD Pro и сейчас находится в корневом подразделении ald.company.lan) и поместим его в отдел ИТ Московского офиса. Убедитесь, что пользователь isemenov оказался в группе «moscow-office-employees». Теперь переместите пользователя в подразделение Казань и убедитесь, что пользователь переместился из группы «moscow-office-employees» в группу «kazan-office-employees».
Добавьте ещё одно подразделение:
ipa orgunit-add Novosibirsk --path=ou=ald.company.lan,cn=orgunits,cn=accounts,dc=ald,dc=company,dc=lan --desc="Новосибирский филиал" --displayname="Новосибирск"
Не создавайте для этого подразделения группу с автоматическим участием!
Переместите пользователя в новосибирский филиал, и обратите внимание, что он остался в группе «kazan-office-employees», хотя пользователь isemenov больше не соответствует правилу участия в этой группе. Чтобы понять, почему так произошло, давайте рассмотрим алгоритм правила автоучастия.
Логика добавления учётных записей в группы с автоучастием:
Вызов плагина automember происходит при создании или изменении учётной записи, при импорте записей, при репликации, а также при выполнении команды ipa automember-rebuild.
Плагин automember проверяет атрибуты учётной записи по правилам автоучастия и добавляет ее в те группы, по которым проверка будет пройдена успешно.
У каждой группы может быть несколько включающих или исключающих правил, каждое из которых представляет собой регулярное выражение для проверки конкретного атрибута учётной записи.
Включающие правила определяют, какие учётные записи должны быть автоматически добавлены в группу, а исключающие правила, напротив, определяют, какие учётные записи НЕ должны автоматически добавляться в группу, позволяя тем самым уточнить выборку, сформированную включающими правилами.
Если для группы определено несколько включающих правил, то они объединяются логической операцией ИЛИ, поэтому для добавления учётной записи в группу достаточно, чтобы она успешно прошла проверку хотя бы по одному из включающих правил. Это же утверждение справедливо и для исключающих правил.
Примечание: Правила могут проверять не только строковые атрибуты (например, department, title), но и атрибуты-списки (например, memberOf).
Логика удаления учётных записей из групп с автоучастием:
Учётная запись будет удалена из групп, которым она больше не соответствует по правилам автоучастия, но только если учётная запись останется участником хотя бы одной группы с автоучастием.
Если после пересчёта (при изменении или rebuild) пользователь не подпадает ни под одно включающее правило ни одной группы с автоучастием, он «зависнет» в группах, в которые был добавлен ранее, несмотря на то, что более не соответствует условиям участия в этих группах. Чтобы исключить такую ситуацию, следует в настройках правил автоучастия установить группу по умолчанию (default group).
Чтобы исключить ситуацию, когда учётная запись остаётся в группах, несмотря на то, что по правилам автоучастия больше не соответствует ни одной из этих групп, в настройках правил автоучастия рекомендуется установить группу по умолчанию.
Примечание
Механизм автоматического удаления (при изменении атрибутов пользователя) работает, только если у группы задано хотя бы одно включающее (inclusive) правило. Если у группы есть только исключающие (exclusive) правила, то автоматическое удаление из нее при изменении атрибутов пользователя не произойдёт. Удалить из такой группы можно только вручную или через rebuild. Это логично, так как исключающие правила по своей сути — это фильтр «кто не должен попасть», а не условие членства.
Подведём итог:
Существуют два ключевых сценария работы Automember:
Реактивный (при изменении): Работает только для групп с включающими правилами.
Принудительный пересчёт (ipa automember-rebuild): Применяет все правила ко всем пользователям/хостам, полностью синхронизируя членство в группах с текущими атрибутами. Используется после изменения правил или для исправления расхождений.
Условие для автоматического удаления: Для его работы у группы должно быть задано хотя бы одно включающее правило.
Назначение группы по умолчанию: Критически важная настройка для поддержания чистоты членства. Без нее пользователи, чьи атрибуты изменились, так и останутся в старых группах с автоучастием.
Теперь настроим группу по умолчанию:
На странице «Правила группы пользователей» сделайте ipausers группой по умолчанию.
Вручную удалите пользователя isemenov из группы «kazan-office-employees».
Переместите пользователя в подразделение «Московский офис», убедитесь, что пользователь оказался в группе «moscow-office-employees».
Переместите пользователя в новосибирский филиал. Убедитесь, что пользователь больше не состоит в группе «moscow-office-employees».
Примечание
Описанный алгоритм работает в конфигурации ALSE 1.7.7 + ALD Pro >= 3.0. В ранних версиях группы с автоучастием позволяют только автоматически добавлять пользователей, но не удалять их.
Практика и тестирование
Заключение
В этом модуле мы прошли тему политик FreeIPA, поэтому можно сказать, что обязательный минимум уже выполнен. Далее мы перейдем к собственным разработкам ALD Pro - групповым политикам.
Дополнительные источники информации
Рекомендуем ознакомиться также с видеороликами нашего хорошего товарища на канале «ИТ-Проповедник». Учитывайте, что ролики записаны для версии 2.2.1, поэтому часть информации потеряла актуальность, но в целом они могут быть крайне полезны.
Политики паролей в ALD Pro 2.2.1
Обратная связь
Если остались вопросы, то их всегда можно задать в специальной теме.