Отладка работы службы SSSD

Служба SSSD предоставляет две основные функции: получение информации о пользователях и их аутентификацию. Каждая из этих функций использует свои программные интерфейсы, поэтому должна рассматриваться отдельно. Однако успешная аутентификация возможна, только если информация о пользователе получена успешно, поэтому, если что-то не работает, то в первую очередь нужно убедиться, что возможно получить хотя бы информацию о пользователе с помощью команд getent и id:

getent passwd $USER

Результат выполнения:

admin:*:1421600000:1421600000:Administrator:/home/admin:/bin/bash

Выполнить команду id:

id $USER

Результат выполнения:

uid=959800000(admin) gid=959800000(admins) группы=959800000(admins),1001(astra-admin),113(lpadmin)

Журналы отладки SSSD

Служба SSSD состоит из множества компонентов и для настройки каждого из них в конфигурационном файле предназначена отдельная секция (например, за настройки монитора отвечает секция [sssd], а Бэкенд настраивается в секции [domain/...]), поэтому для включения отладки конкретного компонента в его секции следует задать параметр debug_level=N, где N - это число от 1 до 10.

Уровни отладки 1-3 регистрируют сбои, а уровни 8-10 обеспечивают излишнюю детализацию, которая затрудняет быстрый анализ журналов, поэтому для решения большинства проблем начать лучше с шестого уровня. Открыть конфигурацию командой:

sudo cat /etc/sssd/sssd.conf

Результат выполнения:

[domain/ald.company.lan]
debug_level = 10
id_provider = ipa
...
[sssd]
debug_level = 10
services = ifp
domains = ald.company.lan
[nss]
debug_level = 10
homedir_substring = /home
...

Уровень отладки можно менять не только через конфигурационный файл, но и «на лету» без перезагрузки службы SSSD, отправляя ей команды через SBus с помощью утилиты sssctl из пакета sssd-tools. Очистить логи, чтобы удобно было смотреть отладочную информацию:

sudo sssctl logs-remove

Изменить уровень отладки командой и просмотреть в лог файле изменение grep „Debug level changed“:

sudo sssctl debug-level 6
sudo cat /var/log/sssd/sssd.log | grep 'Debug level changed'

Результат выполнения отображает начало нужного события:

(2023-08-20 22:17:00): [sssd] [server_common_rotate_logs] (0x0010): Debug level changed to 0x07f0

Повысить уровень логирования до 8:

sssctl debug-level 8
cat /var/log/sssd/sssd.log | grep 'Debug level changed'

В результате можно увидеть два события начало и конец. Это нужно для удобного просмотра лога, чтобы знать где искать интервал отладочной информации от и до:

...[sssd] [server_common_rotate_logs] (0x0010): Debug level changed to 0x07f0
...[sssd] [server_common_rotate_logs] (0x0010): Debug level changed to 0x37f0

Выбрать все строки между кодами смены уровня отладки 0x07f0 и 0x37f0 можно с помощью regex запроса:

cat /var/log/sssd/sssd.log | grep -zoP '(?<=0x07f0)(?s).*(?=0x37f0)'

В операционной системе Astra Linux журналы отладки хранятся в папке /var/log/sssd, по одному файлу журнала на каждый компонент. Ответчики пишут в файлы с именами SSSD_$service, например, собеседник NSS пишет в файл /var/log/sssd/sssd_nss.log. Сообщения от Бэкенда пишутся в файл с именем sssd_$domainname.log. Есть еще журналы вспомогательных процессов, таких как ldap_child.log и krb5_child.log.

Прежде чем погружаться в изучение журналов и файлов конфигурации, желательно внимательно ознакомиться с описанием архитектуры службы SSSD.

Во многих случаях полезно воспроизвести ошибку после очистки кэша, чтобы исключить его влияние, но важно помнить, что в локальной базе кэшируются также и учетные данные, поэтому не стоит удалять кэш, если работа идет в автономном режиме. А также важно обратить внимание, что приведенные примеры сообщений отладки могут меняться для последующих релизов.

Общие рекомендации

Если команды getent или id не выводят вообще никакой информации о пользователе или группе, то нужно проверить:

  • Работу службы разрешения имен командой ping dc-1 и, указаны ли в /etc/resolv.conf правильные DNS-сервера.

  • Работает ли служба с помощью команды systemctl status sssd.

  • Конфигурацию /etc/nsswitch.conf, что модуль sss указан для следующих баз данных: passwd, group, shadow, services, netgroup, sudoers, automount.

  • Поведение команды id на контроллере домена ALD Pro.

  • Доходит ли запрос до Ответчика. Для этого в разделе [nss] установите debug_level = 6 и перезапустите службу sssd.

Приведем пример успешного запроса информации по пользователю.

[sssd[nss]] [get_client_cred] (0x4000): Client creds: euid[10327] egid[10327] pid[18144].
[sssd[nss]] [setup_client_idle_timer] (0x4000): Idle timer re-set for client [0x13c9960][22]
[sssd[nss]] [accept_fd_handler] (0x0400): Client connected!
[sssd[nss]] [sss_cmd_get_version] (0x0200): Received client version [1].
[sssd[nss]] [sss_cmd_get_version] (0x0200): Offered version [1].
[sssd[nss]] [nss_getby_name] (0x0400): Input name: admin

Если команда достигает Ответчика NSS, передается ли она Поставщику данных (Data Provider). Неудачный запрос может выглядеть так:

[sssd[nss]] [cache_req_search_dp] (0x0400): CR #3: Looking up [admin@ipa.test] in data provider
[sssd[nss]] [sss_dp_issue_request] (0x0400): Issuing request for [0x41e51c:1:admin@ipa.test@ipa.test]
[sssd[nss]] [sss_dp_get_account_msg] (0x0400): Creating request for [ipa.test][0x1][BE_REQ_USER][name=admin@ipa.test:-]
[sssd[nss]] [sss_dp_internal_get_send] (0x0400): Entering request [0x41e51c:1:admin@ipa.test@ipa.test]
[sssd[nss]] [sss_dp_req_destructor] (0x0400): Deleting request: [0x41e51c:1:admin@win.trust.test@win.trust.test]
[sssd[nss]] [sss_dp_get_reply] (0x0010): The Data Provider returned an error [org.freedesktop.sssd.Error.DataProvider.Offline]
[sssd[nss]] [cache_req_common_dp_recv] (0x0040): CR #3: Data Provider Error: 3, 5, Failed to get reply from Data Provider
[sssd[nss]] [cache_req_common_dp_recv] (0x0400): CR #3: Due to an error we will return cached data

Успешно обработанный запрос напротив будет выглядеть так:

[sssd[nss]] [cache_req_search_dp] (0x0400): CR #3: Looking up [admin@ipa.test] in data provider
[sssd[nss]] [sss_dp_issue_request] (0x0400): Issuing request for [0x41e51c:1:admin@ipa.test@ipa.test]
[sssd[nss]] [sss_dp_get_account_msg] (0x0400): Creating request for [ipa.test][0x1][BE_REQ_USER][name=admin@ipa.test:-]
[sssd[nss]] [sss_dp_get_reply] (0x1000): Got reply from Data Provider - DP error code: 0 errno: 0 error message: Success
[sssd[nss]] [cache_req_search_cache] (0x0400): CR #3: Looking up [admin@ipa.test] in cache

Если запрос к Поставщику данных успешно завершен, но по-прежнему не отображаются результаты, следует переходить к журналам Бэкенда.

Отладка Бэкенда

Бэкенд выполняет несколько различных операций, поэтому бывает трудно сразу понять, в чем заключается проблема. На самом высоком уровне Бэкенд выполняет следующие шаги в указанном порядке:

  1. Бэкенд получает запрос от клиентской библиотеки и решает, к какому серверу следует подключиться для его обработки. Этот шаг может включать в себя поиск по SRV-записям.

  2. Бэкенд устанавливает соединение с сервером и проходит аутентификацию, используя учетные данные из keytab-файла хоста, если это требуется.

  3. Как только соединение установлено, Бэкенд отправляет запрос на поиск информации, поэтому вы должны увидеть в запросе критерии фильтрации, базовую запись и запрашиваемые атрибуты.

  4. После того, как поиск завершится, соответствующие записи будут сохранены в кэше. Код состояния возвращается собеседнику. Установите debug_level=6 в разделе [domain/], перезапустите службу и выполните еще раз неудачный поиск информации о пользователе. При отладке работы Бэкенда в первую очередь убедитесь, что Бэкенд находится в режиме онлайн, сделать это можно с помощью утилиты sssctl.

sudo sssctl domain-status ald.company.lan

Результат выполнения:

Online status: Online

Active servers:
IPA: dc-1.ald.company.lan

Discovered IPA servers:
- dc-1.ald.company.lan

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

kinit -k && klist

Результат выполнения:

Ticket cache: KEYRING:persistent:959800000:krb_ccache_pMxi5Bu
Default principal: host/dc-1.ald.company.lan@ALD.COMPANY.LAN

Valid starting       Expires              Service principal
20.08.2023 23:15:25  21.08.2023 23:15:25  krbtgt/ALD.COMPANY.LAN@ALD.COMPANY.LAN

Проверить запрос в LDAP, где Ключи -H и -ZZ делают запрос ближе к тому, как служба SSSD взаимодействует с каталогом:

ldapsearch –ZZ –H ldap://dc-1.ald.company.lan -b uid=admin,cn=users,cn=accounts,dc=ald,dc=company,dc=lan cn

Результат выполнения:

# admin, users, accounts, ald.company.lan
dn: uid=admin,cn=users,cn=accounts,dc=ald,dc=company,dc=lan
cn: Administrator

Для отладки GSSAPI аутентификации команду kinit можно использовать в сочетании с переменной окружения KRB5_TRACE. Если установлен для Бэкенда десятый уровень, то информация о трассировке Kerberos аутентификации будет отражаться также в журнале ldap_child.log.

sudo i
set +o history
env KRB5_TRACE=/dev/stdout kinit <<< AstraLinux_176
set -o history
exit

Результат выполнения:

[23001] 1696515238.426608: Getting initial credentials for admin@ALD.COMPANY.LAN
[23001] 1696515238.426610: Sending unauthenticated request
[23001] 1696515238.426611: Sending request (191 bytes) to ALD.COMPANY.LAN
[23001] 1696515238.426612: Initiating TCP connection to stream 10.0.1.11:88
[23001] 1696515238.426613: Sending TCP request to stream 10.0.1.11:88
[23001] 1696515238.426614: Received answer (514 bytes) from stream 10.0.1.11:88
[23001] 1696515238.426615: Terminating TCP connection to stream 10.0.1.11:88
[23001] 1696515238.426616: Response was from master KDC
...
[23001] 1696515238.426651: Storing admin@ALD.COMPANY.LAN → krb5_ccache_conf_data/pa_type/krbtgt\/ALD.COMPANY.LAN\@ALD.COMPANY.LAN@X-CACHECONF: in KEYRING:persistent:1421600000:krb_ccache_kFlzpn6

Необходимо проверить, присутствуют ли на сервере все атрибуты, необходимые для службы SSSD, правильно ли указана база поиска, особенно для доверенных поддоменов. По возможности, выполнить такой же поиск вручную утилитой ldapsearch.

Устранение неисправностей аутентификации, изменения пароля и контроля доступа

Если информация о пользователе может быть успешно получена, но аутентификация не проходит, то в первую очередь нужно смотреть журнал /var/log/auth.log на предмет сообщений от pam_sss. Аутентификация начинается в PAM-стеке на фазе auth и выполняется с помощью провайдера аутентификации (auth_provider) службы SSSD. Однако, не все запросы на аутентификацию проходят через SSSD, например, аутентификация по SSH происходит непосредственно в SSHD, а SSSD взаимодействует с PAM стеком только на фазе account. Контроль доступа начинается в PAM стеке на фазе account и выполняется с помощью провайдера доступа (access_provider) службы SSSD.

Смена пароля начинается на стороне PAM стека на фазе password и выполняется с помощью провайдера смены пароля (chpass_provider) службы SSSD.

Аутентификация через PAM стек происходит по следующему шаблону:

  1. Приложение с поддержкой PAM аутентификации начинает диалог. В зависимости от настроек PAM-стека в диалог может быть вовлечен модуль pam_sss. Для отладки процесса аутентификации, сначала нужно проверить журнал /var/log/auth.log на предмет того, есть ли вообще обращения к pam_sss. Если нет упоминания pam_sss, скорее всего, PAM стек настроен неправильно. Если обращения к pam_sss есть, нужно включить отладку для Ответчика PAM.

  2. Ответчик PAM службы SSSD получает запрос на аутентификацию и в большинстве случаев пересылает его Бэкенду. Важно обратить внимание, что в отличие от запросов на идентификацию, запросы на аутентификацию и контроль доступа обычно не кэшируется и всегда завершаются обращением к серверу. В некоторых случаях это может приводить к задержкам, но это достаточно важно, потому что дополнительные группы в GNU/Linux устанавливаются только в момент входа в систему.

Журналы собеседника PAM должны показывать запросы, которые пришли от PAM-стека и были перенаправлены на Бэкенд. Если отображается запрос на аутентификацию к собеседнику PAM, но получается ошибка от Бэкенда, важно проверить журналы Бэкенда.

Пример ошибки может выглядеть как:

[sssd[pam]] [sss_dp_issue_request] (0x0400): Issuing request for [0x411d44:3:admin@ipa.example.com]
[sssd[pam]] [sss_dp_get_account_msg] (0x0400): Creating request for [ipa.example.com][3][1][name=admin]
[sssd[pam]] [sss_dp_internal_get_send] (0x0400): Entering request [0x411d44:3:admin@ipa.example.com]
[sssd[pam]] [sss_dp_get_reply] (0x1000): Got reply from Data Provider - DP error code: 1 errno: 11 error message: Offline
[sssd[pam]] [pam_check_user_dp_callback] (0x0040): Unable to get information from Data Provider Error: 1, 11, Offline

  1. Бэкенд обрабатывает запрос. Это может включать эквивалент выполнения команды kinit в процессе krb5_child, аутентификацию по LDAP или проверку по списку контроля доступа. После того, как запрос к Бэкенду завершится, результат отправляется обратно собеседнику PAM. Важно посмотреть также файл krb5_child.log, если установить уровень отладки debug_level = 10, то в этот файл будет включаться также низкоуровневая информация для трассировки работы протокола Kerberos. Также можно имитировать аутентификацию вручную с помощью утилиты kinit.

  2. Ответчик PAM получает результат и пересылает его обратно в модуль pam_sss. Сообщения об ошибке или статусе отображается в /var/log/auth.log.