SSSD и Active Directory

SSSD

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

Провайдер ad — это способ подключить SSSD к домену Active Directory. Он не требует от вас знать структуру каталога: SSSD сам находит контроллеры домена через DNS, сам работает с LDAP и Kerberos, сам сопоставляет SID домена с локальными UID и GID.

Проще говоря: id_provider = ad означает «здесь домен AD, разбирайся сам». Ручной вариант того же — SSSD и LDAP, где всё указывается явно.

Минимальный конфиг

Именно такую секцию пишет realm join, и этого достаточно, чтобы начать работать:

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

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

Дальше — про то, что добавляют, когда «работает» уже мало.

Обязательные условия, без которых не заработает

DNS домена. SSSD ищет контроллеры по SRV-записям _ldap._tcp.example.com и _kerberos._tcp.example.com. Если в resolvectl status доменного DNS нет, ничего не поможет:

$ resolvectl status | head -20
$ dig +short SRV _ldap._tcp.example.com

Время. Kerberos не пускает при расхождении часов больше нескольких минут. Ноутбук после долгого сна — первый подозреваемый:

$ timedatectl

keytab. Машинная учётная запись должна быть в /etc/krb5.keytab:

$ sudo klist -k /etc/krb5.keytab | head

Если файла нет — машина в домене не заведена, и это делается не настройкой SSSD, а подключением: «Вход в домен».

Опции провайдера AD

Значения по умолчанию — из man 5 sssd-ad (пакет sssd-common 2.12.0-1ubuntu5.5).

Опция	По умолчанию	Зачем
ad_domain	—	Имя домена, обычно совпадает с именем секции
ad_server	—	Конкретный контроллер домена, если DNS не находит
ad_hostname	имя машины	Переопределить имя компьютера для домена
ad_enabled_domains	не задано	Ограничить, в каких доменах дерева искать пользователей
ad_enable_dns_sites	true	Учитывать сайты AD при выборе контроллера
ad_site	не задано	Задать сайт AD вручную
ad_enable_gc	true	Использовать Global Catalog для поиска
ad_use_ldaps	false	Ходить в LDAP только по TLS (LDAPS)
ad_maximum_machine_account_password_age	30 days	Как часто менять пароль машинной учётки
ad_machine_account_password_renewal_opts	86400:750:300:realm	Через сколько (сек) начать обновлять пароль
ad_update_samba_machine_account_password	false	Обновлять пароль и в базах Samba

Полезное на практике: ad_use_ldaps = true ставят там, где политика домена запрещает открытый LDAP, а ad_server — когда DNS в сети медленный или ненадёжный, и ждать обнаружения каждый раз не хочется.

Общие опции, важные для AD

Это не про домен, а про то, как SSSD отдаёт данные системе. Значения — из man 5 sssd.conf.

Опция	По умолчанию	Что меняет
use_fully_qualified_names	false	Требовать user@example.com вместо короткого имени. true — меньше путаницы, если локальные и доменные имена совпадают
cache_credentials	false	Для ноутбука ставить true: иначе без сети домена входа нет
enumerate	false	Выгружать всех пользователей домена (getent passwd покажет их всех). При десятках тысяч записей это дорого — оставлять false
fallback_homedir	не задано	Шаблон домашнего каталога, например /home/%u@%d
default_shell	не задано	Оболочка доменных пользователей, например /bin/bash

Секция для ноутбука, который бывает в дороге, выглядит так:

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

cache_credentials = true
use_fully_qualified_names = true
fallback_homedir = /home/%u@%d
default_shell = /bin/bash

Доступ: кому пускать вход

access_provider = ad включает проверку доступа. Чтобы пускать не всех, у кого есть учётка в домене, а конкретную группу, задают фильтр:

access_provider = ad
ad_access_filter = (memberOf=cn=linux-admins,ou=groups,dc=example,dc=com)

Проверять после правки — глазами SSSD, а не догадками:

$ sudo sssctl user-checks user@example.com

Команда показывает по шагам: нашёл ли пользователя, пустил ли по доступу, что с паролем.

Групповые политики домена (GPO)

Начиная с 2.x SSSD умеет применять к доступу правила из GPO. По умолчанию:

• ad_gpo_access_control = enforcing — правила применяются;
• ad_gpo_implicit_deny = false — если ни одно правило не совпало, вход разрешается;
• ad_gpo_default_right = deny — по умолчанию прав нет;
• ad_gpo_cache_timeout = 5 секунд — как часто перечитывать правила.

При отладке прав удобно поставить ad_gpo_access_control = permissive: тогда SSSD пишет в журнал, как поступил бы, но никого не блокирует. На рабочей машине с доменными политиками это состояние оставлять нельзя.

Sudo по доменным правилам

SSSD умеет брать правила sudo из AD — тогда права на команды задаются в домене, а не в /etc/sudoers на каждом ноутбуке. Настройка описана в man 5 sssd-sudo, там же порядок правил: сначала доменные, потом локальные.

Диагностика

$ sudo sssctl domain-status example.com        # видит ли домен, онлайн или офлайн
$ sudo sssctl user-checks user@example.com     # пошаговая проверка учётной записи
$ sudo sss_cache -E                            # сбросить кэш
$ sudo journalctl -u sssd -n 50 --no-pager
$ sudo tail -n 50 /var/log/sssd/sssd_example.com.log

Источники

• man 5 sssd-ad — перечень опций ad_* и значения по умолчанию; man 5 sssd.conf — общие опции и их значения по умолчанию. Пакет sssd-common 2.12.0-1ubuntu5.5 (проверено 18.10.2026).
• man 5 sssd-sudo — правила sudo из домена.
• Репозиторий проекта: https://github.com/SSSD/sssd

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

• Конфиги и значения по умолчанию сверены с man-страницами пакета, но на домене не запускались — своего AD у нас нет. Это описание настроек, а не отчёт о прогоне.
• Поведение GPO зависит от схемы домена и прав на чтение политик: у нас это не с чем сверить.