SSSD-KCM(8)

NAME
sssd-kcm - Диспетчер кэшей Kerberos SSSD

ОПИСАНИЕ

На этой справочной странице представлено описание настройки диспетчера кэшей Kerberos SSSD (Kerberos Cache Manager или KCM). KCM — это процесс, который хранит кэши учётных данных Kerberos, отслеживает эти кэши и управляет ими. Он был создан на основе проекта Heimdal Kerberos, хотя библиотека MIT Kerberos также предоставляет поддержку со стороны клиента (подробнее об этом далее) для кэша учётных данных KCM.

В конфигурации, где кэшами Kerberos управляет KCM, библиотека Kerberos (обычно используемая через приложение, например kinit(1)) является “клиентом KCM”, а внутренняя служба KCM называется “сервером KCM”. Клиент и сервер обмениваются данными с помощью сокета UNIX.

Сервер KCM следит за всеми владельцами кэшей учётных данных и осуществляет управление проверками прав доступа на основе UID и GID клиента KCM.

Кэш учётных данных KCM обладает несколькими интересными свойствами:

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

    • в отличие от кэша на основе набора ключей ядра, который является общим для всех контейнеров, сервер KCM представляет собой отдельный процесс, точкой входа которого является сокет UNIX

    • реализация SSSD сохраняет данные ccache в базе данных (обычно она находится по адресу /var/lib/sss/secrets), что позволяет не терять эти данные при перезапусках сервера 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

Для управления поведением обновлений в разделе [kcm] можно настроить следующие параметры krb5 (подробное описание этих параметров приводится далее)

    krb5_renew_interval
    krb5_renewable_lifetime
    krb5_lifetime
    krb5_validate
    krb5_canonicalize
    krb5_auth_timeout

ПАРАМЕТРЫ КОНФИГУРАЦИИ

Служба KCM настраивается в разделе “kcm” файла sssd.conf. Обратите внимание: так как служба KCM обычно активируется с помощью сокета, достаточно просто перезапустить службу “sssd-kcm” после изменения параметров в разделе “kcm” sssd.conf:

    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», автоматическое обновление отключено.

    По умолчанию: не задано

krb5_canonicalize (логическое значение)
    Позволяет указать, следует ли приводить в каноническую форму имя участника-узла и участника-пользователя. Эта возможность доступна в MIT Kerberos 1.7 и выше.

    По умолчанию: false

СМ. ТАКЖЕ

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

AUTHORS

Восходящий источник («апстрим») SSSD — https://github.com/SSSD/sssd/