Arch manual pages

SSSD-SUDO(5) Формати файлів та правила SSSD-SUDO(5)

sssd-sudo - Налаштовування sudo за допомогою модуля SSSD

На цій сторінці підручника описано способи налаштовування sudo(8) на роботу у комплексі з sssd(8) та способи кешування правил sudo у SSSD.

Щоб увімкнути SSSD як джерело правил sudo, додайте sss до запису sudoers у файлі nsswitch.conf(5).

Наприклад, щоб налаштувати sudo на першочерговий пошук правил у стандартному файлі sudoers(5) (цей файл має містити правила, що стосуються локальних користувачів), а потім у SSSD, у файлі nsswitch.conf слід вказати такий рядок:

sudoers: files sss

Докладніші дані щодо налаштовування порядку пошуку у sudoers за допомогою файла nsswitch.conf, а також дані щодо бази даних LDAP, у якій зберігаються правила sudo каталогу, можна знайти на сторінці підручника sudoers.ldap(5).

Зауваження: щоб у правилах sudo можна було використовувати мережеві групи або групи вузлів IPA, вам слід належним чином налаштувати nisdomainname(1) на назву домену NIS (назва цього домену збігається з назвою домену IPA, якщо використовуються групи вузлів IPA).

На боці SSSD достатньо розширити список служб дописуванням «sudo» до розділу [sssd] sssd.conf(5). Щоб пришвидшити пошуку у LDAP, ви також можете налаштувати базу пошуку для правил sudo за допомогою параметра ldap_sudo_search_base.

У наведеному нижче прикладі показано, як налаштувати SSSD на отримання правил sudo з сервера LDAP.

[sssd]
config_file_version = 2
services = nss, pam, sudo
domains = EXAMPLE
[domain/EXAMPLE]
id_provider = ldap
sudo_provider = ldap
ldap_uri = ldap://example.com
ldap_sudo_search_base = ou=sudoers,dc=example,dc=com

Важливо зауважити, що на платформах, де передбачено підтримку systemd, немає потреби додавати засіб надання даних «sudo» до списку служб, оскільки він стає необов'язковим. Втім, замість нього слід увімкнути sssd-sudo.socket.

Якщо SSSD налаштовано на використання IPA як засобу надання даних ID, засіб надання даних sudo буде увімкнено автоматично. Базу пошуку sudo буде налаштовано на використання природного для IPA дерева LDAP (cn=sudo,$SUFFIX). Якщо у sssd.conf буде визначено будь-яку іншу базу пошуку, використовуватиметься це значення. Для використання функціональних можливостей sudo у IPA потреби у дереві compat (ou=sudoers,$SUFFIX) більше немає.

Найбільшою складністю під час розробки підтримки sudo у SSSD було забезпечення роботи sudo з SSSD так, щоб для користувача джерело даних надавало дані у один спосіб та з тією самою швидкістю, що і sudo, надаючи при цьому якомога свіжіший набір правил. Щоб виконати ці умови, SSSD використовує оновлення трьох типів. Будемо називати ці тип повним оновленням, інтелектуальним оновленням та оновленням правил.

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

У разі використання повного оновлення всі правила sudo, що зберігаються у кеші, буде вилучено і замінено на всі правила, які зберігаються на сервері. Таким чином, кеш буде узгоджено шляхом вилучення всіх правил, які було вилучено на сервері. Втім, повне оновлення може значно навантажувати канал з’єднання, а отже його варто використовувати лише іноді. Проміжок між сеансами повного оновлення має залежати від розміру і стабільності правил sudo.

У разі використання типу оновлення правил забезпечується ненадання користувачам ширших дозволів, ніж це було визначено на сервері. Оновлення цього типу виконується під час кожного запуску користувачем sudo. Під час оновлення буде виявлено всі правила, які стосуються користувача, перевірено, чи не завершено строк дії цих правил, і повторно отримано правила, якщо строк дії правил завершено. Якщо якихось з правил не буде виявлено на сервері, SSSD виконає позачергове повне оновлення, оскільки може виявитися, що було вилучено набагато більше правил (які стосуються інших користувачів).

Якщо увімкнено, SSSD зберігатиме лише правила, які можна застосувати до цього комп’ютера. Це означає, що зберігатимуться правила, що містять у атрибуті sudoHost одне з таких значень:

•ключове слово ALL

•шаблон заміни

•мережеву групу (у форматі «+мережева група»)

•назву вузла або повну назву у домені цього комп’ютера

•одну з IP-адрес цього комп’ютера

•одну з IP-адрес мережі (у форматі «адреса/маска»)

Для точного налаштовування поведінки передбачено доволі багато параметрів Будь ласка, зверніться до розділу «ldap_sudo_*» у sssd-ldap(5) та «sudo_*» у sssd.conf(5), щоб ознайомитися з докладним описом.

sssd(8), sssd.conf(5), sssd-ldap(5), sssd-krb5(5), sssd-simple(5), sssd-ipa(5), sssd-ad(5), sssd-files(5), sssd-sudo(5), sssd-session-recording(5), sss_cache(8), sss_debuglevel(8), sss_obfuscate(8), sss_seed(8), sssd_krb5_locator_plugin(8), sss_ssh_authorizedkeys(8), sss_ssh_knownhostsproxy(8), sssd-ifp(5), pam_sss(8). sss_rpcidmapd(5)

Основна гілка розробки SSSD — https://pagure.io/SSSD/sssd/
11/04/2019 SSSD