Linux LDAP-клиент через SSSD: централизованная аутентификация — АйТи Фреш
🐧 Linux 📅 20.02.2026 ⏱️ 13 мин чтения ✍️ АйТи Фреш

Linux LDAP-клиент через SSSD: централизованная аутентификация

Linux LDAP-клиент через SSSD: централизованная аутентификация

Зачем нужен SSSD и что он умеет

SSSD (System Security Services Daemon) — демон для централизованной аутентификации в Linux. Его главная задача: дать Linux-серверу возможность авторизовывать пользователей через Active Directory, FreeIPA или чистый LDAP — так же, как Windows-компьютеры в домене.

Без SSSD каждый Linux-сервер хранит своих пользователей локально. 20 серверов — 20 отдельных баз /etc/passwd. Уволился сотрудник — нужно удалять учётку на каждом. Неудобно и небезопасно. SSSD решает это централизацией.

Что умеет SSSD:

  • Аутентификация через AD, FreeIPA, OpenLDAP
  • Кэширование учётных данных — работает при недоступном сервере каталогов
  • Интеграция с sudo через LDAP
  • SSH-ключи из LDAP/AD
  • Kerberos-аутентификация
  • Ограничение доступа по группам AD

Подключение к Active Directory

Самый распространённый сценарий в нашей практике — Linux-серверы в Windows-домене Active Directory. Разберём пошагово.

Установка и ввод в домен

На Ubuntu 22.04 / Debian 12:

# Установка необходимых пакетов
apt install sssd sssd-ad sssd-tools realmd adcli \
  packagekit samba-common-bin oddjob oddjob-mkhomedir -y

# Проверяем, видим ли домен
realm discover corp.company.ru
# corp.company.ru
#   type: kerberos
#   realm-name: CORP.COMPANY.RU
#   domain-name: corp.company.ru
#   configured: no
#   ...

# Вводим машину в домен (нужны права Domain Admin или делегированные)
realm join corp.company.ru -U Administrator
# Password for Administrator: ****

# Проверяем
realm list
id Administrator@corp.company.ru

Команда realm join автоматически создаёт запись компьютера в AD, генерирует keytab, настраивает sssd.conf и PAM. Это удобнее ручной настройки.

Ручная настройка sssd.conf для AD

Если нужен полный контроль — конфигурируем вручную:

# /etc/sssd/sssd.conf (chmod 600!)
[sssd]
domains = corp.company.ru
config_file_version = 2
services = nss, pam, sudo

[domain/corp.company.ru]
ad_domain = corp.company.ru
krb5_realm = CORP.COMPANY.RU
realmd_tags = manages-system joined-with-adcli
cache_credentials = True
id_provider = ad
krb5_store_password_if_offline = True
default_shell = /bin/bash
ldap_id_mapping = True
use_fully_qualified_names = True  # john@corp.company.ru
fallback_homedir = /home/%u@%d
access_provider = ad

# Ограничить вход по группе AD
access_provider = simple
simple_allow_groups = linux-admins@corp.company.ru, linux-users@corp.company.ru

# Запускаем
systemctl enable --now sssd

# Автосоздание домашних каталогов
# /etc/pam.d/common-session
# session optional pam_mkhomedir.so skel=/etc/skel umask=0022
Подключение к FreeIPA

Подключение к FreeIPA

FreeIPA — open source-альтернатива AD для Linux-инфраструктуры. Используем у клиентов, где нет Windows-домена.

Ввод в домен FreeIPA

Подключение Linux к FreeIPA через ipa-client:

# Установка клиента
apt install freeipa-client -y

# Автоматическая настройка (если DNS настроен правильно)
ipa-client-install --mkhomedir

# Ручная настройка с явными параметрами
ipa-client-install \
  --server=ipa.company.ru \
  --domain=company.ru \
  --realm=COMPANY.RU \
  --principal=admin \
  --password='AdminPassword' \
  --mkhomedir \
  --unattended

# Проверяем
ipa whoami
id john@company.ru

FreeIPA настраивает SSSD, Kerberos и NSS автоматически. После ipa-client-install сервер уже в домене — можно проверять аутентификацию.

Sudo через SSSD

Права sudo хранятся в LDAP/AD и применяются на всех серверах сразу — не нужно редактировать sudoers на каждой машине.

Настройка sudo через AD

Конфигурация sudo через LDAP для AD-домена:

# В sssd.conf добавляем:
[domain/corp.company.ru]
# ... существующие настройки ...
sudo_provider = ad

[sssd]
services = nss, pam, sudo  # добавляем sudo

# /etc/sudo-ldap.conf (для классического LDAP-sudo)
uri ldap://ldap.company.ru
sudoers_base ou=SUDOers,dc=company,dc=ru
binddn cn=sudo-reader,ou=Service Accounts,dc=company,dc=ru
bindpw 

# /etc/nsswitch.conf
sudoers: files sss  # добавляем sss

# Проверяем
sudo -l -U john@corp.company.ru

В FreeIPA sudo-правила создаются через веб-интерфейс или ipa sudorule-add — намного удобнее, чем LDIF-записи в OpenLDAP.

Диагностика SSSD

Диагностика SSSD

SSSD бывает капризным при настройке. Вот инструменты, которые реально помогают.

Команды диагностики

Набор команд при возникновении проблем с SSSD:

# Статус и логи
systemctl status sssd
journalctl -u sssd -f

# Детальные логи (добавить в sssd.conf)
# [domain/corp.company.ru]
# debug_level = 7
# systemctl restart sssd
# journalctl -u sssd | tail -100

# Проверка пользователя
id john@corp.company.ru
getent passwd john@corp.company.ru
getent group 'domain admins@corp.company.ru'

# Полная диагностика через sssctl
sssctl user-checks john@corp.company.ru
sssctl domain-status corp.company.ru

# Очистка кэша (при устаревших данных)
sss_cache -E  # очистить всё
sss_cache -u john@corp.company.ru  # конкретный пользователь

# Проверка Kerberos-тикета
kinit john@CORP.COMPANY.RU
klist

Часто задаваемые вопросы

SSSD кэширует данные пользователей — вход работает даже при недоступном AD/LDAP. Поддерживает несколько провайдеров. Интегрирует sudo, SSH-ключи, Kerberos. PAM через pam_ldap проще, но теряет кэширование и не работает при обрыве связи.

id username@domain.local — UID, GID и группы. getent passwd username@domain.local — запись из NSS. sssctl user-checks username@domain.local — полная диагностика. sss_cache -G -U — очистить кэш при проблемах.

Да, для пользователей с кэшированными данными. Параметр cache_credentials = True и offline_credentials_expiration = 7 в секции [pam]. После 7 дней без связи вход блокируется. Всегда держите локальный root с SSH-ключом.

В /etc/pam.d/common-session добавьте: session required pam_mkhomedir.so skel=/etc/skel umask=0022. При первом входе домашний каталог создаётся автоматически.

Да, в sssd.conf: access_provider = simple, simple_allow_groups = linux-admins, linux-users. Только члены этих групп AD смогут войти. Или через access_provider = ad и GPO — гибче, но сложнее.

#linux ldap client #sssd настройка #sssd active directory

Столкнулись с похожей задачей? Обращайтесь — решим

Если у вас происходит что-то из описанного в этой статье — или любая другая проблема с ИТ-инфраструктурой, — обращайтесь в любое время. Мои специалисты и я лично разберём ситуацию, найдём настоящую причину и доведём до решения.

Возьмёмся и за разовую задачу, и за постоянное обслуживание. Первичная консультация — бесплатно и без обязательств.

📞 +7 903 729-62-41 💬 MAX: +7 903 729-62-41 ✈️ Telegram @ITfresh_Boss

С уважением, Семёнов Евгений Сергеевич, директор «АйТи Фреш» — IT-аутсорсинг для компаний до 50 рабочих мест, 15+ лет практики

Подпишитесь на рассылку ITfresh

Каждую неделю мы выпускаем практические гайды для руководителей IT и системных администраторов. Это не просто теория! Здесь вы найдёте всё: безопасность, 1С, миграции, резервные копии и проверенные лайфхаки из наших реальных проектов.

Письмо придёт в течение минутыНе нашли его во «Входящих» — загляните в папку «Спам» или «Промоакции» и нажмите «Не спам». Так все следующие выпуски будут приходить прямо в основную почту.
Реквизиты оператора персональных данных

ООО «АЙТИ-ФРЕШ», ИНН 7719418495, КПП 771901001. Юридический адрес: 105523, г. Москва, Щёлковское шоссе, д. 92, корп. 7. Контакт: info@itfresh.ru, +7 903 729-62-41. Оператор обрабатывает e-mail подписчика в целях рассылки информационных и рекламных материалов до момента отзыва согласия.