Централизованная аутентификация Linux через LDAP: настройка SSSD с failover и кэшированием

Зачем нужна централизованная аутентификация и почему SSSD

Десять серверов, двадцать локальных пользователей на каждом, пароли на стикерах и zero audit trail. Эта картина знакома каждому сисадмину, который хотя бы раз наследовал парк машин без единой системы управления доступом. Решение - LDAP-каталог как единый источник правды об учётных записях. Вы создаёте пользователя один раз в каталоге, и он мгновенно получает доступ ко всем серверам, где настроена интеграция. Увольнение сотрудника сводится к блокировке одной учётной записи в LDAP, а не к лихорадочному обходу десятка хостов.

SSSD (System Security Services Daemon) - это клиентский демон, который с 2012 года стал стандартом де-факто для подключения Linux-машин к LDAP и Active Directory. В отличие от устаревшего nslcd, SSSD умеет кэшировать учётные данные локально, автоматически переключаться на резервный сервер при отказе основного и централизованно управлять sudo-правилами. nscd кэширует только результаты DNS-запросов и не работает с паролями, а nslcd не поддерживает офлайн-аутентификацию. SSSD закрывает все эти сценарии в одном демоне.

В этом руководстве вы настроите SSSD на CentOS Stream 9 и Ubuntu 24.04, подключите оба сервера к одному LDAP-каталогу, включите failover на резервный контроллер домена и активируете кэширование для входа при недоступности сети. Бонусом - интеграция sudo-правил из LDAP, чтобы права на повышение привилегий управлялись централизованно. Все команды и конфигурации проверены на указанных версиях дистрибутивов в июле 2026 года.

Подготовка окружения: CentOS Stream 9 и Ubuntu 24.04

Три вещи, которые сломают аутентификацию ещё до того, как вы запустите SSSD: рассинхронизация времени, неверное разрешение имён и недоступность LDAP-портов. Устраните их на старте.

На обоих серверах настройте синхронизацию времени. Kerberos, который часто работает поверх LDAP, требует расхождения не более 5 минут, но держите разницу в пределах секунды. На CentOS Stream 9 chrony запущен по умолчанию, проверьте статус:

systemctl status chronyd
chronyc tracking

На Ubuntu 24.04 используется systemd-timesyncd:

systemctl status systemd-timesyncd
timedatectl show-timesync

Далее - разрешение имён. LDAP-сервер должен быть доступен по FQDN. Если у вас нет DNS, добавьте записи в /etc/hosts на каждом клиенте:

192.168.1.10 ldap-master.example.com
192.168.1.11 ldap-slave.example.com

Проверьте доступность портов 389 (LDAP) или 636 (LDAPS) с клиентских машин:

nc -zv ldap-master.example.com 389

Если соединение не устанавливается, проверьте правила файрвола на клиенте и сервере. На CentOS Stream 9 используется firewalld, на Ubuntu - ufw. Временно отключите файрвол для теста или добавьте разрешающие правила.

Установка пакетов SSSD и зависимостей

CentOS Stream 9. Установите SSSD, LDAP-провайдер и oddjob-mkhomedir - сервис, который автоматически создаёт домашние каталоги при первом входе доменного пользователя:

dnf install -y sssd sssd-ldap oddjob-mkhomedir

Ubuntu 24.04. Пакеты называются иначе, добавьте модули PAM и NSS:

apt update
apt install -y sssd sssd-ldap libpam-sss libnss-sss

oddjob-mkhomedir в Ubuntu заменяется встроенным модулем pam_mkhomedir.so, который активируется автоматически при использовании authselect (разберём ниже).

Базовая конфигурация SSSD для подключения к LDAP

Файл /etc/sssd/sssd.conf - единственная точка конфигурации. SSSD крайне требователен к правам: владелец root, группа root, маска 600. Любое отклонение - демон не запустится с ошибкой «Permission denied» в логах.

Создайте файл с нуля. Вот минимальная рабочая конфигурация для анонимного доступа к LDAP (без binddn, только чтение):

[sssd]
services = nss, pam
config_file_version = 2
domains = LDAP

[nss]
filter_users = root
filter_groups = root

[pam]

[domain/LDAP]
id_provider = ldap
auth_provider = ldap
ldap_uri = ldap://ldap-master.example.com
ldap_search_base = dc=example,dc=com
ldap_tls_reqcert = never
cache_credentials = false
entry_cache_timeout = 600

Разбор ключевых параметров:

services = nss, pam - включает провайдеры для имён (NSS) и аутентификации (PAM).
domains = LDAP - имя домена, совпадает с названием секции [domain/LDAP].
id_provider = ldap - SSSD получает информацию о пользователях и группах из LDAP.
auth_provider = ldap - проверка паролей через LDAP-банд.
ldap_uri - URI основного LDAP-сервера.
ldap_search_base - корень дерева каталога, откуда начинается поиск пользователей.
ldap_tls_reqcert = never - отключает проверку сертификата. Только для тестовой среды. В production используйте ldap_tls_reqcert = demand с корректным CA-сертификатом.

Если ваш LDAP-сервер требует аутентификации для поиска (binddn), добавьте в секцию [domain/LDAP]:

ldap_default_bind_dn = cn=readonly,dc=example,dc=com
ldap_default_authtok = secret_password

После создания файла выставьте права и запустите службу:

chmod 600 /etc/sssd/sssd.conf
chown root:root /etc/sssd/sssd.conf
systemctl enable --now sssd

Проверьте статус: systemctl status sssd. Если демон запущен, проверьте, видит ли система доменных пользователей: getent passwd username. Команда должна вернуть строку с UID, GID и домашним каталогом из LDAP. Если ответа нет - переходите к разделу отладки, проблема в search_base или сетевой доступности.

Настройка PAM и NSS для использования SSSD

Самый быстрый способ интегрировать SSSD с PAM и NSS на обоих дистрибутивах - утилита authselect. Она заменяет ручное редактирование /etc/nsswitch.conf и /etc/pam.d/*, снижая риск ошибок.

CentOS Stream 9 и Ubuntu 24.04:

authselect select sssd with-mkhomedir --force

Флаг with-mkhomedir включает автоматическое создание домашних каталогов при первом входе. На CentOS Stream 9 для этого также должен быть запущен oddjobd: systemctl enable --now oddjobd. На Ubuntu 24.04 authselect сам пропишет pam_mkhomedir.so в PAM-стек.

Если authselect недоступен (минимальная установка), на Ubuntu используйте:

pam-auth-update --enable sss

И вручную добавьте sss в /etc/nsswitch.conf для passwd, group и shadow:

passwd: files sss
group:  files sss
shadow: files sss

Перезапустите SSSD после изменения NSS-конфигурации: systemctl restart sssd. Проверьте ещё раз: getent passwd должен показать и локальных, и доменных пользователей.

Настройка отказоустойчивости: автоматический failover на резервный LDAP-сервер

Один LDAP-сервер - это единая точка отказа. Если он упадёт, аутентификация остановится на всех клиентах. SSSD решает эту проблему параметром ldap_uri, который принимает список серверов через запятую.

Измените ldap_uri в секции [domain/LDAP]:

ldap_uri = ldap://ldap-master.example.com,ldap://ldap-slave.example.com

SSSD перебирает серверы в порядке перечисления. Если первый не отвечает, демон переключается на второй. Важно: SSSD не выполняет балансировку, всегда используется первый доступный сервер по списку. Чтобы демон не ждал вечность при зависшем соединении, настройте таймауты:

ldap_network_timeout = 3
ldap_opt_timeout = 5

ldap_network_timeout - время ожидания установки TCP-соединения в секундах. ldap_opt_timeout - таймаут на выполнение LDAP-операции. С этими значениями failover срабатывает через 3-5 секунд после отказа основного сервера.

Проверка failover. На основном LDAP-сервере временно остановите slapd или закройте порт через iptables:

systemctl stop slapd

На клиенте попробуйте войти доменным пользователем по SSH или выполнить getent passwd username. Операция должна выполниться успешно, но с небольшой задержкой. В логах /var/log/sssd/sssd_LDAP.log вы увидите попытку подключения к ldap-master, таймаут и переключение на ldap-slave. Верните основной сервер в строй - SSSD автоматически вернётся на него при следующем запросе.

Включение кэширования учётных данных для офлайн-доступа

Сервер в удалённом офисе, ноутбук администратора в дороге, временный обрыв VPN до ЦОДа - во всех этих сценариях пользователи должны входить в систему, даже если LDAP-сервер недоступен. SSSD умеет кэшировать учётные данные в локальной базе ldb и проверять пароли без обращения к каталогу.

В секции [domain/LDAP] измените или добавьте параметры:

cache_credentials = true
entry_cache_timeout = 86400
account_cache_expiration = 7

Что происходит при такой конфигурации:

cache_credentials = true - SSSD сохраняет хэш пароля в локальной базе после первого успешного входа. Хранилище - файлы в /var/lib/sss/db/, формат ldb.
entry_cache_timeout = 86400 - информация о пользователе (UID, GID, shell) кэшируется на 24 часа. После истечения таймаута SSSD запросит свежие данные из LDAP.
account_cache_expiration = 7 - если LDAP-сервер недоступен, кэшированные учётные данные считаются валидными 7 дней. После этого срока вход будет заблокирован до восстановления связи с каталогом.

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

Проверка офлайн-доступа. Отключите сетевой интерфейс на клиенте: ip link set eth0 down. Попробуйте войти по SSH пользователем, который ранее логинился на этой машине. Вход должен пройти успешно. В логах SSSD появится запись об использовании кэшированных credentials.

Интеграция sudo-правил из LDAP

Редактировать /etc/sudoers на двадцати серверах ради добавления одного администратора - это рутина, которая приводит к рассинхронизации и дырам в безопасности. LDAP позволяет хранить sudo-правила централизованно и применять их через SSSD.

Первый шаг - загрузите sudo-схему в ваш LDAP-каталог. На сервере с OpenLDAP импортируйте schema/sudo.ldif из пакета sudo-ldap. Если сервером выступает FreeIPA, схема уже включена. Пример LDIF для создания sudoRole:

dn: cn=devops-sudo,ou=sudoers,dc=example,dc=com
objectClass: sudoRole
objectClass: top
cn: devops-sudo
sudoUser: %devops
sudoHost: ALL
sudoCommand: ALL
sudoRunAsUser: ALL

Эта запись разрешает всем членам группы devops выполнять любые команды на любых хостах. Вы можете сузить sudoCommand до конкретных бинарников (например, /usr/bin/systemctl) и sudoHost до конкретных серверов.

На клиенте добавьте в секцию [domain/LDAP] файла sssd.conf:

sudo_provider = ldap
ldap_sudo_search_base = ou=sudoers,dc=example,dc=com

В секции [sssd] добавьте sudo в список сервисов:

services = nss, pam, sudo

Настройте /etc/nsswitch.conf, чтобы sudoers искались сначала в локальных файлах, затем через SSSD:

sudoers: files sss

Перезапустите SSSD: systemctl restart sssd. Проверьте, какие sudo-правила применились для пользователя: sudo -l -U username. Команда должна показать правила из LDAP.

Важный нюанс: кэширование sudo-правил работает по умолчанию с таймаутом entry_cache_timeout. Если вы изменили sudoRole в LDAP, изменения применятся на клиенте через 600 секунд (или другой заданный вами кэш-таймаут). Для немедленного применения сбросьте кэш: sss_cache -E.

Отладка и проверка работы SSSD

Три команды для быстрой диагностики:

sssctl domain-status LDAP - показывает состояние домена, список подключённых LDAP-серверов и время последнего успешного запроса.
sssctl user-checks username - симулирует вход пользователя, проверяет PAM-стек и выводит пошаговый отчёт.
sss_cache -u username - сбрасывает кэш конкретного пользователя, заставляя SSSD перезапросить данные из LDAP.

Логи SSSD лежат в /var/log/sssd/. Файл sssd.log содержит общую информацию о работе демона, sssd_LDAP.log - детализацию LDAP-запросов. Чтобы включить подробное логирование, добавьте в нужную секцию sssd.conf параметр debug_level:

[domain/LDAP]
debug_level = 7

Уровни от 1 (только ошибки) до 9 (максимальная детализация). Для production используйте 2-3, чтобы не забивать диск.

Типичные проблемы и их решение

SSSD не запускается: «No such file or directory». Проверьте права на /etc/sssd/sssd.conf. Должны быть 600, владелец root:root. Также проверьте, что файл существует и не пуст.

getent passwd не показывает доменных пользователей. Проверьте ldap_search_base. Если база указана неверно, SSSD ищет пользователей в несуществующей ветке каталога. Выполните ручной поиск через ldapsearch: ldapsearch -x -H ldap://ldap-master.example.com -b dc=example,dc=com. Убедитесь, что пользователи видны.

Ошибка TLS: «unable to get local issuer certificate». Вы используете ldaps:// или ldap_tls_reqcert = demand, но CA-сертификат не установлен. Для тестов временно установите ldap_tls_reqcert = never. Для production скопируйте корневой сертификат LDAP-сервера на клиент, добавьте в системное хранилище и укажите путь в ldap_tls_cacert.

Домашний каталог не создаётся при входе. На CentOS Stream 9 убедитесь, что oddjobd запущен: systemctl status oddjobd. На Ubuntu проверьте, что authselect применил профиль с with-mkhomedir: authselect current. Если профиль без mkhomedir, перепримените: authselect select sssd with-mkhomedir --force.

Если вы настраиваете интеграцию с Active Directory или планируете развернуть полноценный LDAP-сервер с нуля, вам пригодятся наши руководства по централизованной аутентификации через FreeIPA и OpenLDAP и защищённому подключению к Active Directory через SSL/TLS.

Заключение: итоговая конфигурация и дальнейшие шаги

Вы настроили централизованную аутентификацию на CentOS Stream 9 и Ubuntu 24.04, подключили failover на резервный LDAP-сервер, включили кэширование для офлайн-доступа и вынесли sudo-правила в каталог. Итоговый sssd.conf, собранный из всех разделов:

[sssd]
services = nss, pam, sudo
config_file_version = 2
domains = LDAP

[nss]
filter_users = root
filter_groups = root

[pam]

[domain/LDAP]
id_provider = ldap
auth_provider = ldap
sudo_provider = ldap
ldap_uri = ldap://ldap-master.example.com,ldap://ldap-slave.example.com
ldap_search_base = dc=example,dc=com
ldap_sudo_search_base = ou=sudoers,dc=example,dc=com
ldap_tls_reqcert = demand
ldap_network_timeout = 3
ldap_opt_timeout = 5
cache_credentials = true
entry_cache_timeout = 86400
account_cache_expiration = 7

Дальнейшие шаги для усиления инфраструктуры: настройте TLS для шифрования LDAP-трафика (замените ldap:// на ldaps:// и пропишите ldap_tls_cacert), добавьте второй фактор аутентификации через PAM-модуль google-authenticator, настройте автоматический аудит безопасности серверов. Для комплексной защиты ознакомьтесь с нашим руководством по практическому харденингу Linux-серверов и полным руководством по аудиту безопасности. Если вы только начинаете путь в системном администрировании, фундаментальные знания собраны в практическом руководстве по Linux для IT-специалистов.

Для развёртывания тестовой среды или продакшен-инфраструктуры с предсказуемой производительностью обратите внимание на облачные серверы Timeweb Cloud - VDS/VPS с гибким масштабированием ресурсов и готовыми образами CentOS и Ubuntu.