***** ссылка на видео по этой статье *****
За работу компьютера в домене отвечает служба SSSD (System Security Services Daemon, SSSD), которая является на сегодняшний день лучшим решением для обеспечения работы компьютера Linux в составе домена. Ее установка происходит вместе с пакетом aldpro-client, а настройка выполняется при вводе компьютера в домен с помощью утилиты aldpro-client-installer.
Управление службой осуществляется через systemctl с помощью стандартного набора команд: start, stop, restart, status.
Основная задача службы SSSD заключается в предоставлении доступа к информации удаленной службы каталога и механизмам централизованной аутентификации. В качестве поставщика данных для SSSD может выступать FreeIPA, Active Directory, Kerberos домен и даже простой LDAP каталог. Продукт «ALD Pro» построен на базе службы каталога FreeIPA, поэтому в конфигурационных файлах /etc/sssd/sssd.conf на доменных компьютерах будет указан поставщик «ipa», например, «id_provider = ipa», что означает что sssd настроен на работу с поставщиком FreeIPA.
Для обработки запросов на аутентификацию служба SSSD на доменных компьютерах встраивает свой модуль pam_sss.so в PAM-стек, см. файлы common-* из папки /etc/pam.d.
cat /etc/pam.d/common-auth
Строка "auth [success=1 default=ignore] pam_sss.so use_first_pass" говорит о том, что данные аутентификации будут передаваться в том числе модулю pam_sss.so, т.е. будут отправляться в службу sssd.
Для обработки запросов на идентификацию служба SSSD встраивает свои модули в NSS-стек, см. файл /etc/nsswitch.conf.
cat /etc/nsswitch.conf
Из содержимого файла видно, что служба NSS в поисках учётной записи будет сначала просматривать файлы /etc/passwd, /etc/group и /etc/shadow соответственно, а если не найдёт её там, обратится к sss.
Модули службы SSSD и другие клиентские приложения не реализуют внутри себя поддержку протокола Kerberos напрямую. Вместо этого они обращаются к сервисам безопасности через общий программный интерфейс сервисов безопасности (англ. Generic Security Services API, GSSAPI). Это позволяет заменять библиотеки, используемые GSS-API, без необходимости
переписывать приложения.
Для поддержки протокола Kerberos V5 через GSSAPI используются библиотеки libgssapi-krb5, librkb5 и др. В соответствии с настройкой default_ccache_name в конфигурационном файле /etc/krb5.conf библиотека для хранения полученных ключей использует связку ключей Linux (KEYRING). Для управления ключами используются такие утилиты пакета krb5-user, как kinit, klist,
kdestroy, kvno и др.
Интерфейс GSSAPI позволяет не только устанавливать безопасный контекст, но и выполнять шифрование сообщений. Поэтому при выполнении LDAP-запросов с аутентификацией по Kerberos данные будут внутри зашифрованы средствами GSSAPI.
При входе доменного пользователя в систему у него появляется домашняя директория, но служба SSSD не создает его как локального пользователя.
Архитектура службы SSSD
При первом входе доменного пользователя в систему служба SSSD сохраняет информацию о нем в локальном кеше, что ускоряет работу службы и позволяет обеспечить возможность входа в автономном режиме, даже когда нет связи с контроллером домена. Извлечение информации из домена и поддержание кеша в актуальном состоянии является довольно сложной задачей, поэтому SSSD состоит из множества компонентов, которые взаимодействуют друг с другом при помощи различных методов межпроцессного взаимодействия.
В состав службы входят следующие компоненты:
- Монитор (англ. Monitor)
- Серверные части или Бэкенды (англ. Backends)
- Ответчики (англ. Responders)
- Клиентские библиотеки и приложения
Рассмотрим каждый из них подробнее.
Монитор (Monitor)
Службу sssd.service называют Монитором или Наставником, так как она порождает процессы всех других компонентов и управляет ими по протоколу S-Bus, который является внутренней реализацией протокола D-Bus, поэтому к компонентам нельзя обратиться по D-Bus напрямую, он не регистрируют себя в системной шине. Для возможности управления службой по D-Bus предназначен ответчик IFP (info pipe), через него, например, утилита sssctl получает информацию об активном контроллере, который обслуживает хост. На рисунке «Диаграмма загрузки службы SSSD» представлена диаграмма процесса загрузки службы:
1. В момент запуска службы Монитор анализирует файл конфигурации /etc/sssd/sssd.conf (1) и загружает его в кэш расположенный в /var/lib/sss/db/config.ldb (2).
2. Далее Монитор, используя системные вызовы, порождает процесс Бэкенда (3), который загружает информацию из config (кэш конфигураций) (4, 5) и регистрирует себя в Мониторе (6). Теперь Монитор знает, что запущен какой-то Бэкенд, а Бэкенд подключил библиотеку для работы с конкретным поставщиком данных.
3. На следующем шаге Монитор порождает Ответчиков NSS и PAM (7), которые считывают информацию из config (кэш конфигураций) (8, 9) и регистрируются в Мониторе (10) и Бэкенде (11). Теперь Монитор знает, что Ответчики запущены и Бэкенд знает от кого принимать запросы и кому передавать ответы.
Помимо внутреннего взаимодействия через SBus, служба SSSD использует UNIX-сигналы, например, в тех случаях, когда процесс завис и не отвечает через SBus. Обработчики сигналов обычно интегрированы с главным циклом событий tevent с использованием вызова tevent_add_signal:
- SIGTERM - сигнал на завершение работы процесса.
- SIGKILL - сигнал для принудительного завершения работы процесса, который направляется монитором, если процесс не завершается после получения SIGTERM.
- SIGUSR1 - сигнал на переключение Бэкенда в автономный ре
- жим, если поставщик данных недоступен. Если сигнал будет направлен Монитору, то он перешлет его всем дочерним процессам sssd_be.
- SIGUSR2 - сигнал на переключение Бэкенда в режим онлайн. Если сигнал будет направлен Монитору, то он перешлет его всем дочерним процессам sssd_be.
- SIGHUP - может быть передан Монитору, после чего тот начнет новый лог-файл и вызовет метод сброса журналов управляемым процессам, что крайне удобно при отладке. Кроме того, процессы sssd_be перечитывают resolv.conf, а процесс sssd_nss выполнит очистку быстрого кэша.
Серверные части или Бэкенды (Backends)
Бэкенд (англ. Backend, BE) включает в себя Поставщиков данных (англ. Data Provider, DP) – это процесс приложения /usr/lib/x86_64-linux-gnu/sssd/sssd_be, который запускается Монитором для взаимодействия с доменом в соответствии с настройками секции [domain/<имя_домена>] конфигурационного файла /etc/sssd/sssd.conf. Бэкенд не является
монолитом, т.е. в сам процесс не включены все возможные вызовы для различных поставщиков данных, и в зависимости от настроек подключает один и более Поставщиков данных (англ. Data Provider, DP), каждый из которых представляет из себя совместно используемую библиотеку (англ. Shared Object, SO).
ps -aux | grep sssd_be
Т.е. Бэкенды - это процессы, которые непосредственно взаимодействуют с поставщиками данных (с контроллерами доменов). Рассмотрим описание бэкендов в конфигурационном файле командой:
sudo cat /etc/sssd/sssd.conf | head -12
Библиотеки SSSD находятся в каталоге /usr/lib/x86_64-linux-gnu/sssd/, и за работу компьютера в домене «ALD Pro» (FreeIPA), например, отвечает Поставщик ipa, которому соответствует библиотека libsss_ipa.so. Если же ввести Linux компьютер напрямую в домен Active Directory, то будет использоваться libsss_ad.so. Посмотреть библиотеки можно командой:
ls -l /usr/lib/x86_64-linux-gnu/sssd
Каждый Поставщик данных может оказывать Бэкенду SSSD следующие услуги:
- Идентификация (id_provider) - предоставление информации о пользователях, служебных учетных записях, группах и так далее.
- Аутентификация (auth_provider) - проверка аутентичности пользователей и служб.
- Авторизация (access_provider) - проверка прав доступа на запуск служб на уровне HBAC.
- Поставщик sudo (sudo_provider) - предоставление информации о правилах SUDO на повышение привилегий.
- И другие.
Разные модули могут использовать разные настройки, например, для Поставщика ipa требуется задать параметр ipa_server, который используется для определения контроллера домена FreeIPA, с которым требуется поддерживать соединение. По умолчанию в конфигурационном файле sssd.conf для домена явно задается только несколько провайдеров (id, auth, chpass, access), а для других провайдеров подразумевается, что их имя совпадает с именем поставщика идентификационных данных (id_provider). Для удобства из соображений сокращения размера конфигурационного файла, служба SSSD руководствуется следующими правилами:
- Если параметр ipa_domain не указан, то используется FQDN имя домена из секции [domain/<fqdn домена>].
- Если параметр ipa_server не указан, то сервер определяется автоматически через DNS, как буд-то параметр ipa_server равен _srv_.
- Если провайдер не указан, то используется значения id_provider (например, ipa). Исключением является access_provider, если его значение не указано, то по умолчанию параметр принимает значение permit, что означает "всем пользователям разрешен доступ". Для управления доступом параметр access_provider должен быть задан явно.
Таким образом, стандартный файл конфигурации /etc/sssd/sssd.conf может быть упрощен до следующего вида:
[domain/ald.local]
id_provider = ipa
access_provider = ipa
cache_credentials = True
ldap_tls_cacert = /etc/ipa/ca.crt
krb5_store_password_if_offline = True
Ответчики (Responders)
Ответчик служит посредником между пользовательским приложением (таким как id или getent), кэшем SSSD и бэкендом. Когда приложение запрашивает данные, например, ищет пользователя по имени, Ответчик выполняет поиск в локальном кэше и, если данные не найдены или устарели, обращается к Бэкенду, чтобы тот совершил запрос к северу службы каталога.
Клиентские библиотеки взаимодействуют с Ответчиком через Unix socket (например, /var/lib/sss/pipes/nss), а внутри SSSD между Ответчиками, Бэкендами и Монитором взаимодействие осуществляется через SBus.
Каждый Ответчик работает в отдельном процессе и выполняет строго определенные задачи, например:
- Ответчик NSS (sssd_nss) обеспечивает данными диспетчер службы имен (англ. Name Service Switch, NSS).
- Ответчик PAM (sssd_pam) предоставляет данные для работы подключаемых модулей аутентификации (англ. Pluggable Authentication Modules, PAM).
- Ответчик SUDO (sssd_sudo) обеспечивает правилами утилиту sudo.
- И так далее.
Клиентские библиотеки и приложения
Для взаимодействия с Ответчиком приложению нужно обращаться к соответствующему unix сокету по специфичному сетевому протоколу, поэтому для упрощения разработки клиентских приложений были созданы вспомогательные совместно используемые библиотеки, такие как libnss_sss.so.2, pam_sss.so и др., которые можно найти в каталоге /usr/lib/x86_64-linux-gnu.
Например, если в конфигурационном файле /etc/nsswitch.conf для базы sudoers источником данных будет указан sss, то утилита sudo для взаимодействия с Ответчиком sssd_sudo воспользуется функциями из библиотеки libsss_sudo.so. Аналогичным образом работает autofs.
Однако есть и такие приложения, которые могут даже не знать о существовании SSSD, если используют более универсальные функции из библиотек pam и glibc, которые взаимодействуют с клиентскими библиотеками SSSD от имени приложения. Например, утилиты id, getent, ls вызывают стандартные функции NSS, которые извлекают информацию из нескольких баз данных имен (например, passwd, group, service, netgroup и так далее). На рисунке «Диаграмма потока данных при вызове команды id» отражен поток данных, создаваемый клиентским приложением id, выполняющим NSS запрос через службу SSSD:
- Клиентское приложение /usr/bin/id вызывает функцию getpwnam() из библиотеки glibc для получения информации о пользователе (1).
- Библиотека glibc загружает конфигурационный файл nsswitch.conf (2, 3) и в соответствии с его настройками загружает совместно используемую библиотеку libnss_sss.so.2 и вызывает ее функцию _nss_sss_getpwnam_r (4).
- Для получения данных от Ответчика /usr/lib/x86_64-linux-gnu/sssd/sssd_nss библиотека libnss_sss.so.2 отправляет запрос через unix сокет /var/lib/sss/pipes/nss по специализированному протоколу обмена данными (5).
- Ответчик NSS проверяет наличие данных в кэше (6, 7), и в случае отсутствия данных или истекшего срока их действия отправляет запрос getAccountInfo к Бэкенду, запрашивая необходимые данные (8).
- Бэкенд из-под учетной записи хоста /etc/krb5.ketyab направляет LDAP-запрос для получения данных от службы каталога (9). Если запрашиваемый пользователь принадлежит тому же домену, то это будет прямой запрос на поиск информации, в противном случае SSSD выполнит расширенную LDAP операцию.
Ответчик PAM работает немного иначе. Локальный кэш будет использоваться только в том случае, если служба находится в режиме оффлайн, а если связь с сервером есть, то при входе пользователя в систему Ответчик запросит проверку аутентичности у контроллера и обновит информацию об участии пользователя в группах, даже если срок действия кэша еще не истек. В
качестве примеров клиентских приложений, использующих PAM, можно привести login, su и sshd.
Несмотря на то, что клиентские приложения и библиотеки не являются синонимами, в рабочей документации и программном коде службы SSSD под словосочетанием SSSD Client (суффикс sss_cli) часто подразумеваются именно клиентские библиотеки, а не сами приложения. Например, идентификатором sss_cli обозначается сетевой протокол, с помощью которого клиентские
библиотеки общаются с Ответчиками службы SSSD.
Механизм кэширования службы SSSD
Служба SSSD в своей работе активно использует кэш, что позволяет исключить повторные обращения к серверу за информацией, когда в этом нет необходимости, и обеспечивает возможность работы в автономном режиме без подключения к серверу. Время кеширования 5400 секунд или 90 минут, а попытка обновить кэш будет по прошествии 50% этого времени, т.е. через 45 минут. Система кэширования довольно сложна и включает в себя несколько взаимодополняющих механизмов.
---------------------------------------------------------------------------------------------
Локальный кэш (local cache, cache)
Локальный кэш – это база данных, в которую Бэкенды записывают результаты, получаемые из службы каталога, чтобы Ответчики могли считывать их напрямую. При помещении объектов в кэш им назначается срок жизни, и до тех пор, пока он не истечет, все последующие запросы к этим данным обрабатываются без обращения к серверу. Устаревшие данные могут извлекаться из кэша только в том случае, если служба находится в автономном режиме.
Файлы локального кэша находятся на диске в каталоге /var/lib/sss/db/, для работы с этим кэшем служба sssd использует встроенную библиотеку баз данных облегченного доступа (англ. Light Weight Embedded Database Library, ldb) - ту же библиотеку, с помощью которой реализована база данных службы каталога Samba AD. Если установить пакет ldb-tools, то вам станет доступна утилита ldbsearch, с помощью которой можно заглянуть внутрь ldb-файлов. Структура этой базы данных подобна LDAP-каталогу, а параметры ldbsearch во многом повторяют параметры утилиты ldapsearch:
Установим пакет ldb-tools:
sudo apt install ldb-tools
Выполним утилитой ldbsearch поиск информации по нашей учетной записи admin:
sudo ldbsearch -H /var/lib/sss/db/cache_ald.local.ldb -b name=admin@ald.local,cn=users,cn=ald.local,cn=sysdb fullName uidNumber cachedPassword
В данном запросе ключ -b (--basedn) задет отличительное имя записи для поиска. Как можно заметить, информация в базе есть и пароль закэширован, поэтому пользователь может успешно выполнить вход даже в автономном режиме. Если указать только uidNumber без cachedPassword, то нельзя с уверенностью говорить о том, что этот пользователь входил в систему, возможно по нему просто кто-то запрашивал информацию, например утилитой id. Именно наличие закэшированного пароля говорит об успешном входе пользователя.
Теперь зайдем в сессию супер-пользователя, выполним удаление кэша очисткой каталога /var/lib/sss/db/, перезапустим службу sssd и повторим поиск: Войдем в одну из виртуальных консолей (Ctrl + ALT + F1) без графического интерфейса (tty1-tty6) под локальным пользователей, запустим оболочку от имени суперпользователя, очистим содержимое каталога /var/lib/sss/db/, перезапустим службу sssd и попробуем выполнить поиск в базе локального кэша утилитой ldbsearch.
sudo -i
rm -rf /var/lib/sss/db/*
systemctl restart sssd
ldbsearch -H /var/lib/sss/db/cache_ald.local.ldb -b name=admin@ald.local,cn=users,cn=ald.local,cn=sysdb uidNumber
, где ключ -b (--basedn) это отличительное имя базы для поиска.
Как мы видим, запрос в базу не вывел ни одного результата.
Для проверки кэша мы запросим информацию командой id, повторим запрос и посмотрим, что сохранилось в локальном кэше:
id admin
ldbsearch -H /var/lib/sss/db/cache_ald.local.ldb -b name=admin@ald.local,cn=users,cn=ald.local,cn=sysdb uidNumber
Команду id нужно запустить именно для доменного пользователя (в моем случае доменный администратор admin), запуск команды id для локального пользователя не приведет к результату.
На низком уровне ldb использует библиотеку Trivial DataBase, поэтому сырые данные в формате ключ-значение можно извлекать с помощью утилит из пакета tdb-tools:
sudo apt install tdb-tools
sudo tdbtool /var/lib/sss/db/config.ldb keys
В папке /var/lib/sss/db/ находятся следующие ldb-файлы локального кэша:
- config.ldb - кэш для хранения настроек службы, загружаемых из конфигурационного файла /etc/sssd/sssd.conf.
- sssd.ldb - база данных локального домена (local provider), которая позволяет использовать возможности вложенных групп без централизованной службы каталога. Для администрирования использовались команды sss_useradd, sss_groupadd и др., поддержка функции прекращена с версии SSSD 2.0.0
- cache_ald.local.ldb - кэш для хранения критически важной информации, получаемой из домена. Сохранение таких данных на диск требуется выполнять сразу при получении новых данных.
- timestamps_ald.local.ldb - кэш для хранения некритичной и часто обновляемой информации. Сохранение данных на диск выполняется в фоновом режиме по усмотрению операционной системы.
Кроме файлов локального кэша в этой же папке находятся файлы кэша учетных данных Kerberos, которые можно просматривать с помощью утилиты klist с ключом «c»:
- ccache_ALD.LOCAL - кэш для хранения Kerberos-билетов службы SSSD, с помощью которых она выполняет LDAP-запросы к службе каталога.
- fast_ccache_ALD.LOCAL - кэш для хранения TGT-билета, с помощью сессионного ключа которого обеспечивается дополнительное шифрование запросов по технологии FAST Armoring. Этот кэш появляется, когда компьютер проходит дополнительную аутентификацию в домене и он используется для дополнительного шифрования трафика между клиентом и сервером.
Удаление всех файлов из директории db является самым простым, но в тоже время и самым полным способом очистки локального кэша службы sssd:
sudo -i
sudo systemctl stop sssd
sudo rm -rf /var/lib/sss/db/*
sudo systemctl start sssd
Тоже самое можно сделать с помощью команды cache-remove утилиты sssctl из состава пакета sssd-tools:
sudo apt install sssd-tools
sudo sssctl cache-remove
Однако для отладки SSSD на нагруженном сервере рекомендуют использовать специализированную утилиту sss_cache из того же пакета sssd-tools. С ее помощью можно отметить как недействительным весь кэш:
sudo sss_cache -E
так и отметить недействительными только отдельные записи, например, по конкретному пользователю, чтобы они были повторно извлечены из каталога при следующем обращении:
sudo sss_cache -u admin
Отличие sssctl cache-remove и sss_cache -E в том, что первая удаляет кэш немедленно, а вторая помечает его как недействительный, и при следующем обращении он будет обновлен.
---------------------------------------------------------------------------------------------
Быстрый кэш (in-memory cache, memcache)
Все процессы SSSD (Монитор, Бэкенд, Ответчик), являются однопоточными приложениями и обрабатывают запросы со скоростью одного ядра, поэтому Ответчик мог бы стать узким местом и ограничить возможности вертикального масштабирования. В тоже время, из соображений безопасности клиентским библиотекам нельзя давать прямой доступ к локальному кэшу, т.к. в нем содержатся в том числе конфиденциальные данные, например, хэши паролей. Для устранения противоречия был создан дополнительный быстрый кэш, который доступен клиентским библиотекам напрямую, но содержит при этом только общую информацию о пользователях и группах.
Быстрый кэш представляет из себя хэш-таблицы, которые находятся в каталоге /var/lib/sss/mc/ и отображаются на память (Memory-mapped).
Ответчик NSS записывает информацию в быстрый кэш и до тех пор, пока эти данные остаются актуальными, клиентской библиотеке не требуется связываться с SSSD для их извлечения. Если же запись будет отсутствовать в кэше или ее срок жизни истек, запрос будет перенаправлен Ответчику NSS, который извлечет данные из локального кэша или обратится к контроллеру домена через Бэкенд.
По умолчанию время хранения записей в быстром кэше составляет 600 секунд и может быть изменено с помощью параметра memcache_timeout в файле /etc/sssd/sssd.conf.
cat /etc/sssd/sssd.conf | grep memcache
Для отключения быстрого кэша нужно установить memcache_timeout=0, а для очистки, как и в случае локального кэша, просто удалить файлы и перезапустить службу:
sudo -i
sudo systemctl stop sssd
sudo rm -rf /var/lib/sss/mc/*
sudo systemctl start sssd
Команда cache-remove утилиты sssctl не удаляет файлы быстрого кэша, но sss_cache, как и в случае локального кэша, позволяет отметить недействительными отдельные записи, например, по конкретному пользователю, чтобы они были повторно извлечены из каталога при следующем обращении.
sudo sss_cache -u admin
---------------------------------------------------------------------------------------------
Негативный или безрезультатный кэш (negative cache, ncache)
Для уменьшения нагрузки на сервер при обращении к несуществующим объектам каталога, внутри Ответчика NSS и ряда других компонентов реализован так называемый негативный или безрезультатный кэш. Этот кэш находится в оперативной памяти и обновляется каждые 15 секунд, изменить эту настройку можно с помощью параметра entry_negative_timeout в конфигурационном файле /etc/sssd/sssd.conf. Для полной очистки негативного кэша достаточно просто перезапустить службу командой:
sudo systemctl restart sssd
---------------------------------------------------------------------------------------------
Алгоритм использования кэша (cache lookup)
Служба SSSD кэширует пользователей, группы, правила HBAC/SUDO, SSH-ключи, карты монтирования дисков и другую информацию, но вне зависимости от типов объектов поиск в кэше выполняется очень похожим образом. Упрошенный алгоритм поиска показан на рисунке ниже.
В действительности алгоритм немного сложнее и выполняется чуть больше проверок и действий (например, если мы уже знаем, к какому домену относится учетная запись пользователя, то эта информация используется, как подсказка), но приведенной схемы достаточно для получения общих представлений.
На рисунке ниже отражен поток данных при поиске информации с использованием кэша.
Рассмотрим последовательность взаимодействия компонентов подробнее:
- Клиентское приложение вызывает функцию getpwnam() из библиотеки glibc, которая в соответствии c настройками из /etc/nsswitch.conf загружает клиентскую библиотеку libnss_sss.so.2 и вызывает ее функции, подробнее см. в разделе «Клиентские приложения и библиотеки».
- Клиентская библиотека проверяет, есть ли информация о запрашиваемом объекте в быстром кэше (memcache), и только после этого обращается к Ответчику sssd_nss.
- Ответчик проверяет, есть ли информация о запрашиваемом объекте в локальном кэше, и только после этого обращается к Бэкенду sssd_be.
- Бэкенд выполняет запрос к LDAP-каталогу, сохраняет информацию в локальный кэш и сообщает Ответчику о готовности.
- Ответчик повторно обращается к локальному кэшу, извлекает оттуда необходимую информацию, записывает ее в быстрый кэш и передает Клиентской библиотеке в качестве ответа.
- Клиентская библиотека возвращает ответ в функцию glibc, на чем поиск завершается.
Для управления службой используется приложение systemctl, которое позволяет запускать и останавливать службу, а также просматривать ее текущее состояние.
sudo systemctl stop sssd - остановка службы sssd. Работая из-под учетной записи доменного администратора не стоит выполнять эту команду, так как выполнить следующую через sudo не получится, из-за остановленной службы sssd и отсутствия возможности провести аутентификацию пользователя. Однако службу sssd можно будет запустить из-под учетной записи локального администратора, войдя им в одну из виртуальных консолей (tty1-tty6).
Работа компьютера в автономном режиме
Для обеспечения комфортной работы пользователей в условиях нестабильного подключения к локальной сети по Wi-Fi или через VPN, служба SSSD может предоставлять часть сервисов автономно без подключения к серверу. Переход в автономный режим происходит автоматически в следующих случаях:
- пропало подключение к сети;
- нет возможности преобразовать fqdn сервера в IP адрес;
- не удается подключиться к серверу.
Работая автономно, Монитор службы SSSD предпринимает попытки возврата в режим онлайн по следующим триггерам:
- получено уведомление об изменении настроек сети, например, о подключении кабеля или изменении таблицы маршрутизации (см. информацию по библиотеке netlink);
- получено уведомление об изменении конфигурационного файла /etc/resolv.conf (см. информацию по подсистеме inotify);
- по расписанию каждые 30 секунд;
В ходе отладки администратор может переключать режимы вручную, отправляя процессу SSSD сигналы SIGUSR1 (перейти в offline) и SIGUSR2 (перейти в online), но в большинстве случаев достаточно включить/выключить всю службу целиком.
sudo sssctl domain-status ald.local | grep status
sudo kill -SIGUSR1 $(pidof sssd)
sudo sssctl domain-status ald.local | grep status
sudo kill -SIGUSR2 $(pidof sssd)
sudo sssctl domain-status ald.local | grep status
Автономный вход по кэшу пароля
Когда пользователь в первый раз входит в компьютер, его аутентификация возможна только через контроллер домена, но при получении успешного статуса PAM_SUCCESS служба SSSD сохранит SHA512 хэш в локальной базе, что гарантирует возможность автономной аутентификации этого пользователя даже в условиях отсутствия связи с сервером. Извлечь хэш пользовательского
пароля из ldb-файла и проверить его валидность можно с помощью утилит ldbsearch и openssl.
sudo ldbsearch -H /var/lib/sss/db/cache_ald.local.ldb -b name=admin@ald.local,cn=users,cn=ald.local,cn=sysdb cachedPassword
openssl passwd -6 -salt 'NvH.nZtfD1WcZhra' 'P@ssw0rd'
Функция хранения кэшей включена по умолчанию, за это отвечает параметр cache_credentials из файла sssd.conf. Срок хранения паролей не ограничен, так как параметр offline_credentials_expiration не задан.
Для первого входа в систему компьютер должен иметь доступ к контроллеру домена, что легко обеспечить из офиса, подключив устройство кабелем к локальной сети, но трудно выполнимо, если устройство нужно передать сотруднику для удаленной работы через службу доставки. В этом случае, может оказаться, что офисная сеть будет ему недоступна до тех пор, пока он не войдет в систему и не подключится через домашний Wi-Fi.
Для решения этой проблемы в составе sssd-tools есть утилита sss_seed, которая позволяет имитировать первый вход, принудительно устанавливая ldb-кэш пароля:
echo 'P@ssw0rd' > /tmp/ssd-pwd.txt
sudo sss_seed --domain ALD.LOCAL --username ald-user1 --password-file /tmp/ssd-pwd.txt
Имя пользователя должно быть известно в домене, иначе команда не сможет получить его идентификатор и другие сведения. Если на момент выполнения команды пользователь уже входил в это устройство, то утилита переопределит кэш его пароля.
Автоматическая Kerberos аутентификация при переходе в онлайн режим
Хэш SHA512 отлично подходит для долгосрочного хранения секретов на диске, но с его помощью не получится пройти Kerberos аутентификацию, поэтому при входе в компьютер в автономном режиме служба SSSD помещает пароль в связку ключей ядра Linux, чтобы иметь возможность выписать TGT-билет, когда связь с сервером будет восстановлена. За возможность автоматической
Kerberos-аутентификации пользователя при переключении в онлайн режим отвечает параметр krb5_store_password_if_offline, который по умолчанию равен True.
Если потребуется, извлечь пароль из Keyring можно с помощью утилиты keyctl, но из-за настроек прав доступа выполнять эти команды нужно будет в контексте процесса службы SSSD.
Подключиться к действующему процессу можно с помощью отладчика gdb (GNU Debugger), для работы которого нужно будет отключить блокировку функции ptrace. Данная техника работает описанным ниже способом. Для этого сначала необходимо установить отладчик и отключить блокировку ptrace.
sudo apt install gdb
sudo astra-ptrace-lock disable
sudo reboot
После перезагрузки выполнить вход в систему тем же пользователем и просмотреть pid службы sssd для подключения к процессу Монитора и номер текущего окна терминала для перенаправления стандартного вывода. Сетевая связанность компьютера с контроллером домена в этот момент должна быть заблокирована, т.к. после получения TGT-билета пароль больше не
требуется и будет удален из связки ключей.
pidof sssd
tty
Теперь необходимо подключиться к процессу, чтобы извлечь содержимое ключа.
gdb -p 411
Важно обратить внимание, что технология автоматической Kerberos аутентификации при переходе в онлайн режим является безопасной, т.к.
- пароль хранится в оперативной памяти и не сохраняется в системе при выключении компьютера;
- пароль хранится в системе ограниченное время и автоматически удаляется при появлении связи с контроллером домена;
- извлечь пароль может только пользователь, обладающий привилегиями
суперпользователя.
Динамическое обновление DNS-записей в домене
Компьютеры в домене взаимодействуют между собой по доменным именам, поэтому в каталоге важно иметь актуальную информацию по IP-адресам, которые закреплены за этими хостами. С серверами обычно не возникает проблем, т.к. им назначаются статические адреса, а вот интерфейсы рабочих станций настраиваются динамически, поэтому администраторам нужно обеспечить такое же динамическое обновление этой информации в каталоге.
Обновление DNS записей возможно как по инициативе DHCP-сервера (Remote Name Daemon Control, RNDC), так и по инициативе рабочей станции (GSS-TSIG). У каждого из подходов есть свои сильные и слабые стороны. Второй способ видится наиболее простым и безопасным, так как в этом случае запросы на обновление DNS-записей авторизуются с помощью Kerberos аутентификации.
Для настройки динамического обновления DNS-записей в конфигурационном файле /etc/sssd/sssd.conf на стороне рабочей станции нужно добавить следующие параметры:
[domain/ad.example.com]
...
dyndns_update = true
dyndns_refresh_interval = 43200
dyndns_update_ptr = true
dyndns_ttl = 3600
...
После внесения указанных изменений можно перезапустить службу sssd и проверить обновление записей в каталоге при изменении IP-адреса на хосте.
---------------------------------------------------------------------------------------------
Отладка службы sssd и Kerberos
Служба SSSD предоставляет две основные функции: получение информации о пользователях и их аутентификацию. Каждая из этих функций использует свои программные интерфейсы, поэтому должна рассматриваться отдельно. Однако успешная аутентификация возможна, только если информация о пользователе получена успешно, поэтому, если что-то не работает, то в первую очередь нужно убедиться, что возможно получить хотя бы информацию о пользователе с помощью команд getent и id.
getent passwd $USER
id $USER
Журналы отладки SSSD
Служба SSSD состоит из множества компонентов и для настройки каждого из них в конфигурационном файле (/etc/sssd/sssd.conf) предназначена отдельная секция (например, за настройки монитора отвечает секция [sssd], а бэкенд настраивается в секции [domain/...]), поэтому для включения отладки конкретного компонента в его секции следует задать параметр «debug_level=N», где N - это число от 1 до 10.
Уровни отладки 1-3 регистрируют сбои, а уровни 8-10 обеспечивают излишнюю детализацию, которая затрудняет быстрый анализ журналов, поэтому для решения большинства проблем начать лучше с шестого уровня.
Уровень отладки можно менять не только через конфигурационный файл, но и «на лету» без перезагрузки службы SSSD, отправляя ей команды через D-Bus с помощью утилиты 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'
В результате выполнения мы видим начало нужного нам события:
(2024-07-12 10:29:25): [sssd] [server_common_rotate_logs] (0x0010): Debug level changed to 0x07f0
Повысим уровень логирования до 8:
sudo sssctl debug-level 8
sudo cat /var/log/sssd/sssd.log | grep 'Debug level changed'
В результате мы можем видеть два события начало и конец. Это нужно для удобного просмотра лога, чтобы знать где искать интервал отладочной информации от и до:
(2024-07-12 10:29:25): [sssd] [server_common_rotate_logs] (0x0010): Debug level changed to 0x07f0
(2024-07-12 10:32:36): [sssd] [server_common_rotate_logs] (0x0010): Debug level changed to 0x37f0
Выбрать строки между кодами смены уровня отладки 0x07f0 и 0x37f0 можно с помощью regex:
sudo 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 dc1» и, указаны ли в /etc/resolv.conf правильные DNS сервера.
- Работает ли сама служба SSSD с помощью команды «systemctl status sssd».
- Конфигурацию в /etc/nsswitch.conf, что модуль sss указан для следующих баз данных:
passwd, group, shadow, services, netgroup, sudoers, automount.
- Поведение команды id на контроллере домена ALD Pro.
- Доходит ли запрос до Ответчика. Для этого в разделе [nss]\ установите debug_level = 6 и перезапустите службу sssd. Приведу пример успешного запроса информации по пользователю:
sudo tail -f /var/log/sssd/sssd_nss.log
id ald-user1
Приведу пример неудачного запроса:
Если команда достигает Ответчика NSS, проверьте что она передается Поставщику данных (Data Provider). Неудачный запрос может выглядеть так:
Успешно обработанный запрос напротив будет выглядеть так:
Если запрос к Поставщику данных успешно завершен, но вы по-прежнему не видите никаких результатов, следует переходить к журналам Бэкенда.
Отладка Бэкенда SSSD
Бэкенд выполняет несколько различных операций, поэтому бывает трудно сразу понять, в чем заключается проблема. На самом высоком уровне Бэкенд выполняет следующие шаги в указанном порядке:
1. Бэкенд получает запрос от клиентской библиотеки и решает, к какому серверу следует подключиться для его обработки. Этот шаг может включать в себя поиск по SRV-записям.
2. Бэкенд устанавливает соединение с сервером и проходит аутентификацию, используя учетные данные из keytab файла хоста, если это требуется.
3. Как только соединение установлено, бэкенд отправляет запрос на поиск информации, поэтому вы должны увидеть в запросе критерии фильтрации, базовую запись и запрашиваемые атрибуты.
4. После того, как поиск завершится, соответствующие записи будут сохранены в кэше. Код состояния возвращается собеседнику.
При отладке работы Бэкенда в первую очередь убедитесь, что Бэкенд находится в режиме онлайн, сделать это можно с помощью
утилиты sssctl:
sudo sssctl domain-status ald.local
Проверьте, можно ли установить соединение с теми же параметрами безопасности, которые использует SSSD:
sudo kinit -k && klist
Проверьте запрос в LDAP, где Ключи -H и -ZZ делают запрос ближе к тому, как служба SSSD взаимодействует с каталогом:
ldapsearch -ZZ -H ldap://dc1.ald.local -b uid=admin,cn=users,cn=accounts,dc=ald,dc=local cn
Для отладки GSSAPI аутентификации команду kinit можно использовать в сочетании с переменной окружения KRB5_TRACE. Если вы установите для Бэкенда десятый уровень, то информация о трассировке Kerberos аутентификации будет отражаться также в журнале krb5_child.log.
set +o history
env KRB5_TRACE=/dev/stdout kinit admin <<< 'P@ssw0rd'
set -o history
Проверьте, присутствуют ли на сервере все атрибуты, необходимые для службы 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, но получаете ошибку от Бэкенда, проверьте журналы Бэкенда. Пример ошибки может выглядеть как:
3. Бэкенд обрабатывает запрос. Это может включать эквивалент выполнения команды kinit в процессе krb5_child, аутентификацию по LDAP или проверку по списку контроля доступа.
После того, как запрос к бэкенду завершится, результат отправляется обратно Ответчику PAM. Посмотрите также файл krb5_child.log, если установить уровень отладки debug_level = 10, то в этот файл будет включаться также низкоуровневая информация для трассировки работы протокола Kerberos. Вы также можете имитировать аутентификацию вручную с помощью утилиты kinit.
4. Ответчик PAM получает результат и пересылает его обратно в модуль pam_sss. Ищите сообщения об ошибке или статусе в /var/log/auth.log.
---------------------------------------------------------------------------------------------
Механизм автообнаружения в SSSD
SSSD во время работы каждые 30 секунд проверяет статус Бэкенда, что он online.
Когда Бэкенд находится в статусе online, он создает файл /var/lib/sss/pubconf/kdcinfo.ALD.LOCAL (в вашем случае ALD.LOCAL заменится на Ваш реалм).
Рассмотрим этот файл, открыв его следующей командой:
cat /var/lib/sss/pubconf/kdcinfo.ALD.LOCAL
В этом файле, при наличии у Вас двух контроллеров домена всегда присутствует три записи. Третья запись повторяет первую. Это происходит из-за того, что в файле /etc/sssd/sssd.conf указано использовать для поиска контроллера домена сначала _SRV_ записи из DNS сервера и только затем подключаться к первому контроллеру домена dc1.ald.local:
Поэтому через _SRV_ мы получаем два контроллера домена (первые две записи), а третья запись прилетает из явно указанной в конфиге (dc1.ald.local).
Вернемся к файлу /var/lib/sss/pubconf/kdcinfo.ALD.LOCAL:
Логика его работы такая, что если к какому-то из контроллеров ни разу не было подключения, то он будет записан доменным именем (FQDN) не разрешенным в IP адрес (в моем случае это контроллер домена dc2.ald.local). Если подключение к контроллеру домена было, то в этом файле будет записан сразу IP адрес этого контроллера домена.
Командой sudo sssctl domain-status ald.local мы можем посмотреть с каким контроллером домена общается SSSD для получения данных:
sudo sssctl domain-status ald.local
Но в системе есть еще библиотеки Kerberos, которые используются когда мы делаем команды kinit, kvno и др. И настройки Kerberos библиотек регулируются файлом /etc/krb5.conf:
И перед тем как начнется dns_lookup (строчки выделены на рис выше) у нас в системе есть плагин для библиотеки krb5 и этот плагин как раз использует файл /var/lib/sss/pubconf/kdcinfo.ALD.LOCAL (о нем говорилось выше). То есть SSSD подготавливает файл kdcinfo.ALD.LOCAL для плагина библиотеки krb5. И поэтому, если у нас SSSD включен, он будет брать результаты Discovered в файле /var/lib/sss/pubconf/kdcinfo.ALD.LOCAL. А если мы на доменном компьютере выключим SSSD, то тогда для обнаружения контроллеров домена будет использоваться настройка dns_lookup_kdc = true из файла /etc/krb5.conf
И каждый раз, например, при использовании команды kinit будет выполнятся поиск _SRV_ записей в DNS сервере. Поэтому при включенном SSSD у нас нет никаких действий в соответствии с настройкой dns_lookup_kdc = true, потому что эта информация уже есть в /var/lib/sss/pubconf/kdcinfo.ALD.LOCAL. При выключенном SSSD при каждом kinit мы будем видеть пачки DNS запросов.
ВАЖНО! На контроллере домена эта схема еще больше усложняется, потому что на контроллере домена, кроме службы SSSD еще установлена служба winbind. Winbind это один из трех компонентов Samba, это аналог SSSD от Samba. Именно winbind осуществляет NTLM аутентификацию и через него Samba осуществляет преобразование идентификаторов. Так же как и SSSD добавляет свой плагин в krb5 библиотеки, так же и winbind добавляет свой плагин. Причем плагин winbind имеет приоритет выше чем плагин SSSD. И поэтому когда Вы на контроллерах домена делаете Kerberos операции, то сначала Discovered работает от winbind, потом Discovered от SSSD и только если эти две службы будут выключены - произойдет переключение на Discovered от krb5.
Посмотреть кого выбрал winbind можно командой (на контроллере домена):
wbinfo --dsgetdcname ALD.LOCAL
На скриншоте видим, что взаимодействие будет с контроллером домена у которого IP адрес - 10.0.2.7
Сделаем kinit с трассировкой командой:
KRB5_TRACE=/dev/stdout kinit admin
И мы так же увидим, что происходит обращение к контроллеру домена у которого IP адрес - 10.0.2.7
Суть вышеизложенного такова, что в больших инфраструктурах не всегда можно сразу понять что происходит, потому что есть целых три последовательных механизма автообнаружения сервисов для Kerberos аутентификации, поэтому чтобы понять через какой контроллер Вы аутентифицируетесь пользуйтесь вышеизложенной схемой.
---------------------------------------------------------------------------------------------
Расположение значимых файлов
В следующей таблице представлена сводная информация по наиболее полезным файлам для отладки компонентов системы.