SSSD

Автор: Летописец, Дата: 2026-10-18

SSSD (System Security Services Daemon) — служба, через которую ноутбук или сервер берёт учётные записи не из своих файлов, а из внешнего источника: каталога LDAP, домена Active Directory, FreeIPA. Для системы она выглядит как обычные пользователи и группы, но живут они не в /etc/passwd, а на сервере домена.

Раздел отвечает на прикладной вопрос: как подключить машину к домену и входить в неё доменной учётной записью. Пример здесь — ноутбук с Ubuntu, домен — Active Directory.

Зачем это нужно

Без SSSD доменный вход собирают из кучи отдельных служб: NSS-модуль для LDAP, PAM-модуль для Kerberos, ещё один — для смены пароля. Работает, но каждая часть настраивается отдельно, и ломается тоже отдельно.

SSSD закрывает это одной службой с одним файлом настроек. Что он даёт:

доменные учётные записи в системе — getent passwd, id, su, sudo видят доменных пользователей и группы;
вход и смена пароля — через PAM, с проверкой пароля в домене (Kerberos или LDAP-bind);
кэш — учётные данные остаются доступны, когда машины нет в сети домена (ноутбук в дороге это и есть обычный случай);
единый вход — билет Kerberos даёт вход в доменные ресурсы без повторного ввода пароля;
правила доступа — кому из домена пускать на эту машину, а кому нет;
динамические домашние каталоги — каталог создаётся при первом входе.

Из чего он состоит

Часть	Что делает
`sssd`	Служба-посредник. Держит домены, кэш, отвечает клиентам
Провайдеры (`id_provider`, `auth_provider`, `access_provider`)	Отвечают, откуда брать данные: `ldap`, `ad`, `ipa`, `krb5`, `proxy`
`libnss_sss`	Подключает SSSD к NSS — системе, которая разрешает имена в учётные записи
`pam_sss`	Подключает SSSD к PAM — то есть к входу в систему
Кэш	Локальные базы в `/var/lib/sss/db/`; здесь живут данные, пока нет сети
`/etc/sssd/sssd.conf`	Единственный файл настройки доменов

Как выглядит путь при входе:

программа → PAM (pam_sss) → sssd → провайдер → LDAP или Active Directory
     getent → NSS (libnss_sss) → sssd → провайдер → …

Установка

Пакеты разделены по назначению: сам демон, и отдельно — провайдеры под каждый каталог.

# Для домена Active Directory
$ sudo apt install sssd-ad sssd-tools realmd adcli

# Для обычного каталога LDAP
$ sudo apt install sssd-ldap sssd-tools

# Автосоздание домашнего каталога при первом входе
$ sudo apt install libpam-sss oddjob-mkhomedir

realmd и adcli нужны для подключения к домену «одной командой» — о них в разделе «Вход в домен».

Проверить, что поставилось, и снять след версий:

$ sssd --version
$ apt-cache policy sssd sssd-ad sssd-ldap realmd adcli

Настройка: каркас

Настройка — один файл /etc/sssd/sssd.conf. Порядок такой:

1. Домены и службы. В секции [sssd] — какие домены обслуживать и какому клиенту отвечать:

[sssd]
config_file_version = 2
services = nss, pam
domains = example.com

2. Домен. Отдельная секция [domain/имя], где имя совпадает с domains:

[domain/example.com]
id_provider = ad
auth_provider = ad
access_provider = ad
ad_domain = example.com
krb5_realm = EXAMPLE.COM

Так выглядят провайдеры AD. Для LDAP вместо ad будет ldap — см. «SSSD и LDAP» и «SSSD и Active Directory».

3. Права на файл. Внутри есть пароль служебной учётной записи, поэтому:

$ sudo chmod 600 /etc/sssd/sssd.conf

Без этого SSSD отказывается работать и пишет об этом в журнал — частая первая ошибка.

4. Подключение к системе. Сказать NSS и PAM, что теперь есть SSSD:

# nsswitch.conf: добавить sss в конце строк passwd/group
$ grep '^passwd\|^group' /etc/nsswitch.conf
passwd:         files sss
group:          files sss

# PAM на Debian/Ubuntu настраивают не руками, а через профили
$ sudo pam-auth-update --enable mkhomedir

Порядок files sss важен: сначала локальные файлы, потом домен.

5. Запуск и след в журнале:

$ sudo systemctl enable --now sssd
$ systemctl status sssd | head -5

Проверка: что должно получиться

Проверять надо с самого нижнего уровня вверх — тогда сразу видно, где обрыв.

# 1. Домен виден и отвечает
$ realm discover example.com

# 2. Учётные данные приходят
$ getent passwd user@example.com
$ id user@example.com

# 3. Билет Kerberos (для AD)
$ kinit user@EXAMPLE.COM
$ klist

# 4. Вход через PAM
$ su - user@example.com

Если getent пусто, а realm discover отвечает — смотреть журнал SSSD, а не гадать:

$ sudo journalctl -u sssd -n 50 --no-pager
$ sudo tail -n 50 /var/log/sssd/sssd_example.com.log

Кэш и работа без сети

Кэш — главное, зачем SSSD ставят на ноутбук. Пока пользователь хоть раз вошёл, его данные лежат в /var/lib/sss/db/ и вход работает без домена. Если пароль в домене сменили с другой машины, старый кэшированный пароль продолжит работать, пока ноутбук снова не увидит домен.

Полезно при отладке (и опасно на рабочей машине — стирает кэш):

$ sudo sss_cache -E          # сбросить кэш целиком
$ sudo sssctl user-checks user@example.com

Служебные учётные записи Kerberos

В AD это две разные учётки, и путать их — обычное дело:

машинная учётка (hostname$) — создаётся при подключении к домену, пароль к ней лежит в keytab /etc/krb5.keytab, SSSD обновляет его сам;
пользовательская — та, которой входят люди, и пароль от неё SSSD никогда не хранит.

Атрибут ad_maximum_machine_account_password_age (по умолчанию 30 дней) задаёт, как часто SSSD меняет пароль машинной учётки. Если машинная учётка потеряет пароль, домен перестанет пускать машину — тогда помогает повторное подключение realm join --client-software=sssd.

Чего в этом разделе нет

Здесь описан вход в домен, а не защита машины вообще. Аутентификация локальных пользователей, модули и стеки PAM — отдельный блок: PAM. Изоляция, шифрование, аудит — соседние разделы «Безопасности».

Источники

man 5 sssd.conf, man 5 sssd-ad, man 5 sssd-ldap — пакет sssd-common 2.12.0-1ubuntu5.5 (проверено 18.10.2026). Имена опций и их значения по умолчанию — оттуда.
man 8 realm — пакет realmd 0.17.1-3build3.
man 1 adcli — пакет adcli 0.9.2-1ubuntu3.
Репозиторий проекта: https://github.com/SSSD/sssd

Что ещё не проверено

Команды и настройки сверены с man-страницами, но в нашем окружении не прогонялись: под рукой нет ни домена Active Directory, ни каталога LDAP. Проверка «в бою» — на рабочем домене.
Версии пакетов — из Ubuntu (resolute) на 18.10.2026. В Debian и в другом выпуске Ubuntu номера будут другими, а имена опций — те же.

Оценка статьи 0