SSSD-KCM(8)

NAME
sssd-kcm - Керування кешем Kerberos SSSD

ОПИС

На цій сторінці підручника описано налаштування засобу керування кешем Kerberos SSSD (Kerberos Cache Manager або KCM). KCM є процесом, який зберігає, стежить і керує кешем реєстраційних даних Kerberos. Ідея створення засобу походить із проєкту Heimdal Kerberos, хоча у бібліотеці Kerberos MIT також надається підтримка з боку клієнта для кешу реєстраційних даних KCM (докладніше про це нижче).

У конфігураціях, де кешем Kerberos керує KCM, бібліотека Kerberos (типово використовується за допомогою якоїсь програми, наприклад kinit(1)) є “клієнтом KCM”, а фонова служба KCM вважається “сервером KCM”. Клієнт і сервер обмінюються даними за допомогою сокета UNIX.

The KCM server keeps track of each credential caches's owner and performs access check control based on the UID and GID of the KCM client.

Кеш реєстраційних даних KCM має декілька цікавих властивостей:

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

    • на відміну від кешу на основі наборів ключів ядра, який є спільним для усіх контейнерів, сервер KCM є окремим процесом, чия точка входу є сокетом UNIX

    • реалізація у SSSD зберігає дані ccache у базі даних, файл якої типово називається /var/lib/sss/secrets. За допомогою цього файла ccache зберігаються протягом періодів перезапуску сервера KCM або перезавантаження комп'ютера.

Це надає змогу системі використовувати кеш реєстраційних даних із врахуванням збірок, одночасно надаючи спільний доступ до кешу реєстраційних даних для декількох контейнерів або без контейнерів взагалі шляхом прив'язування-монтування сокета.

Час очікування на дії типового клієнта KCM дорівнює 5 хвилин, таке значення надає більшу часу на взаємодію користувача із інструментами командного рядка, зокрема kinit.

КОРИСТУВАННЯ КЕШЕМ РЕЄСТРАЦІЙНИХ ДАНИХ KCM

Для використання кешу реєстраційних даних KCM його слід вибрати стандартним типом реєстраційних даних у krb5.conf(5). Назвою кешу реєстраційних даних має бути лише “KCM:” без будь-яких розширень шаблонами. Приклад:

    [libdefaults]
        default_ccache_name = KCM:

Далі, слід визначити однаковий шлях до сокета UNIX для клієнтських бібліотек Kerberos і сервера KCM. Типово, у обох випадках використовується однаковий шлях /var/run/.heim_org.h5l.kcm-socket. Для налаштовування бібліотеки Kerberos змініть значення її параметра “kcm_socket”, як це описано на сторінці підручника krb5.conf(5).

Нарешті, переконайтеся, що з сервером KCM SSSD можна встановити зв'язок. Типово, служба KCM вмикається за допомогою сокета з systemd(1). На відміну від інших служб SSSD, її не можна запустити додаванням рядка “kcm” до інструкції “service”.

    systemctl start sssd-kcm.socket
    systemctl enable sssd-kcm.socket

Будь ласка, зауважте, що відповідні налаштування модулів вже могло бути виконано засобами вашого дистрибутива.

СХОВИЩЕ КЕШУ РЕЄСТРАЦІЙНИХ ДАНИХ

Кеші реєстраційних даних зберігаються у базі даних, дуже подібно до кешів записів користувачів і груп SSSD. Типово, база даних зберігається у “/var/lib/sss/secrets”.

ОТРИМАННЯ ДІАГНОСТИЧНОГО ЖУРНАЛУ

Типово, служба sssd-kcm активує крізь сокет systemd(1). Для створення діагностичних журналів додайте вказані нижче рядки або безпосередньо до файла /etc/sssd/sssd.conf, або як фрагмент налаштувань до каталогу /etc/sssd/conf.d/:

    [kcm]
    debug_level = 10

Далі, перезапустіть службу sssd-kcm:

    systemctl restart sssd-kcm.service

Нарешті, виконайте дії, які не призводять до бажаних для вас наслідків. Журнал KCM буде записано до /var/log/sssd/sssd_kcm.log. Рекомендуємо вимкнути ведення діагностичного журналу, якщо вам не потрібні діагностичні дані, оскільки служба sssd-kcm може породжувати доволі великий обсяг діагностичних даних.

Будь ласка, зауважте, що у поточній версії фрагменти налаштувань буде оброблено, лише якщо взагалі існує основний файл налаштувань /etc/sssd/sssd.conf.

ПОНОВЛЕННЯ

Службу sssd-kcm можна налаштувати на спробу поновлення TGT для поновлюваних TGT, які зберігаються у ccache KCM. Спроби поновлення виконуватимуться при досягненні половини строку дії квитка. Поновлення KCM налаштовуються при встановленні таких параметрів у розділі [kcm]:

    tgt_renewal = true
    krb5_renew_interval = 60m

Крім того, SSSD може успадковувати параметри krb5 для поновлень з наявного домену.

    tgt_renewal = true
    tgt_renewal_inherit = domain-name

Вказані нижче параметри krb5 можна налаштувати у розділі [kcm] для керування поведінкою під час поновлення. Ці параметри докладно описано нижче

    krb5_renew_interval
    krb5_renewable_lifetime
    krb5_lifetime
    krb5_validate
    krb5_canonicalize
    krb5_auth_timeout

ПАРАМЕТРИ НАЛАШТУВАННЯ

Налаштовування служби KCM виконується за допомогою розділу “kcm” файла sssd.conf. Будь ласка, зауважте, що оскільки активація служби KCM, зазвичай, відбувається за допомогою сокетів, після внесення змін до розділу “kcm” файла sssd.conf достатньо перезапустити службу “sssd-kcm”:

    systemctl restart sssd-kcm.service

Налаштування служби KCM виконують за допомогою “kcm”. Докладний опис синтаксичних конструкцій налаштувань наведено у розділі “ФОРМАТ ФАЙЛА” сторінки підручника щодо sssd.conf(5).

Службі kcm можна передавати типові параметри служби SSSD, зокрема “debug_level” та “fd_limit” Із повним списком параметрів можна ознайомитися на сторінці підручника sssd.conf(5). Крім того, передбачено декілька специфічних для KCM параметрів.

socket_path (рядок)
    Сокет, на якому очікуватиме на з'єднання служба KCM.

    Типове значення: /var/run/.heim_org.h5l.kcm-socket

    Зауваження: на платформах, де передбачено підтримку systemd, шлях до сокета буде перезаписано шляхом, який визначено у файлі модуля sssd-kcm.socket.

max_ccaches (ціле число)
    Скільки кешів реєстраційних може мати даних база даних KCM для усіх користувачів.

    Типове значення: 0 (без обмежень, застосовується лише квота на кількість кешів на UID)

max_uid_ccaches (ціле число)
    Скільки кешів реєстраційних може мати даних база даних KCM для окремого UID. Еквівалент значення “кількість реєстраційних даних, які можна ініціювати за допомогою kinit”.

    Типове значення: 64

max_ccache_size (ціле число)
    Наскільки великим може бути кеш реєстраційних даних окремого ccache. Ця квота обчислюється для усіх квитків служб разом.

    Типове значення: 65536

tgt_renewal (булеве значення)
    Вмикає функціональні можливості поновлень TGT.

    Типове значення: False (автоматичні поновлення вимкнено)

tgt_renewal_inherit (рядок)
    Домен, з якого слід успадковувати параметри krb5_*, для використання із поновленнями TGT.

    Типове значення: NULL

krb5_auth_timeout (ціле число)
    Час очікування, по завершенню якого буде перервано запит щодо розпізнавання або зміни пароля у мережі. Якщо це можливо, обробку запиту щодо розпізнавання буде продовжено у автономному режимі.

    Типове значення: 6

krb5_validate (булеве значення)
    Перевірити за допомогою krb5_keytab, чи отриманий TGT не було підмінено. Перевірка записів у таблиці ключів виконується послідовно. Для перевірки використовується перший запис з відповідним значенням області. Якщо не буде знайдено жодного відповідного області запису, буде використано останній запис з таблиці ключів. Цим процесом можна скористатися для перевірки середовищ за допомогою зв’язків довіри між записами областей: достатньо розташувати відповідний запис таблиці ключів на останньому місці або зробити його єдиним записом у файлі таблиці ключів.

    Типове значення: false (надається IPA та AD: true)

    Будь ласка, зауважте, що перевірка квитка є першим кроком при перевірці PAC (див. «pac_check» на сторінці підручника щодо sssd.conf(5), щоб дізнатися більше). Якщо перевірку квитків вимкнено, також буде вимкнено і перевірки PAC.

krb5_renewable_lifetime (рядок)
    Надіслати запит щодо поновлюваного квитка з загальним строком дії, вказаним за допомогою цілого числа, за яким одразу вказано одиницю часу:

    s — секунди

    m — хвилини

    h — години

    d — дні.

    Якщо одиниці часу не буде вказано, вважатиметься, що використано одиницю s.

    Зауваження: не можна використовувати одразу декілька одиниць. Якщо вам потрібно встановити строк дії у півтори години, слід вказати «90m», а не «1h30m».

    Типове значення: не встановлено, тобто TGT не є оновлюваним

krb5_lifetime (рядок)
    Надіслати запит щодо квитка з загальним строком дії, вказаним за допомогою цілого числа, за яким одразу вказано одиницю часу:

    s — секунди

    m — хвилини

    h — години

    d — дні.

    Якщо одиниці часу не буде вказано, вважатиметься, що використано одиницю s.

    Зауваження: не можна використовувати одразу декілька одиниць. Якщо вам потрібно встановити строк дії у півтори години, слід вказати «90m», а не «1h30m».

    Типове значення: не встановлено, тобто типовий строк дії квитка визначатиметься у налаштуваннях KDC.

krb5_renew_interval (рядок)
    Час у секундах між двома послідовними перевірками того, чи слід оновлювати записи TGT. Записи TGT оновлюються після завершення приблизно половини їхнього строку дії, що задається як ціле число з наступним позначенням одиниці часу:

    s — секунди

    m — хвилини

    h — години

    d — дні.

    Якщо одиниці часу не буде вказано, вважатиметься, що використано одиницю s.

    Зауваження: не можна використовувати одразу декілька одиниць. Якщо вам потрібно встановити строк дії у півтори години, слід вказати «90m», а не «1h30m».

    Якщо значення для цього параметра встановлено не буде або буде встановлено значення 0, автоматичного оновлення не відбуватиметься.

    Типове значення: not set

krb5_canonicalize (булеве значення)
    Визначає, чи слід перетворювати реєстраційний запис вузла і користувача у канонічну форму. Цю можливість передбачено з версії MIT Kerberos 1.7.

    Типове значення: false

ТАКОЖ ПЕРЕГЛЯНЬТЕ

sssd(8), sssd.conf(5),

AUTHORS

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