SSSD и LDAP

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

Провайдер ldap — это ручной способ: вы сами говорите SSSD, где каталог, в каком дереве искать людей и чем к нему подключаться. Он же спасает, когда каталог есть, а домена Active Directory нет — или когда в AD нет прав заводить компьютеры.

Разница с провайдером ad принципиальная: машинной учётной записи здесь нет. Машина не «входит в домен», она всего лишь читает каталог служебной записью. Значит, и единого входа через Kerberos не будет — пароль проверяется в каталоге.

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

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

[domain/ldap.example.com]
id_provider = ldap
auth_provider = ldap
ldap_uri = ldaps://ldap.example.com
ldap_search_base = dc=example,dc=com

ldap_default_bind_dn = cn=sssd-reader,ou=services,dc=example,dc=com
ldap_default_authtok = <пароль служебной учётки>

Что здесь что:

Опция	Смысл
`ldap_uri`	Адрес каталога: `ldaps://` (TLS сразу) или `ldap://` + `ldap_id_use_start_tls = true`
`ldap_search_base`	Корень поиска пользователей и групп
`ldap_default_bind_dn`	Служебная учётная запись для чтения каталога
`ldap_default_authtok`	Её пароль. Файл `sssd.conf` из-за этого обязан быть `600`
`ldap_default_authtok_type`	Тип пароля, если нужен не обычный: `password` или `obfuscated_password`
`ldap_id_use_start_tls`	Шифровать соединение через StartTLS вместо `ldaps://`

Схема каталога: что искать

Каталоги описывают учётные записи по-разному, и SSSD нужно сказать, по какой схеме читать:

`ldap_schema`	Когда
`rfc2307`	Классический LDAP (OpenLDAP) с `posixAccount` / `posixGroup`, UID и GID есть прямо в каталоге
`rfc2307bis`	То же, но группы — через `groupOfNames`
`ad`	Каталог Active Directory, к которой обращаются по LDAP, а не провайдером `ad`

Если признаков POSIX нет (в AD UID/GID в каталоге не хранятся, там SID), включают сопоставление идентификаторов:

ldap_id_mapping = true

Тогда SSSD сам вычисляет UID и GID из SID — так же, как это делает провайдер ad. Значение по умолчанию зависит от схемы: при ad — включено, при rfc2307 — выключено, и его надо ставить явно, если UID в каталоге нет.

Соответствие «атрибут каталога → поле системы» настраивается отдельно; полный список — в man 5 sssd-ldap-attributes (uid, uidNumber, gidNumber, homeDirectory, loginShell и прочие).

Группы и их корни

Пользователей и группы часто ищут в разных местах:

ldap_search_base = dc=example,dc=com
ldap_group_search_base = ou=groups,dc=example,dc=com
ldap_user_search_base = ou=people,dc=example,dc=com

ldap_group_nesting_level задаёт, на сколько уровней вложенности разворачивать группы. Значение по умолчанию — 2: этого мало, если группы вложены глубже, и тогда «пользователь не в группе», хотя в каталоге он в ней.

Доступ: фильтр вместо «все, кто есть в каталоге»

По умолчанию пускают любого, кого нашли. Чтобы ограничить:

access_provider = ldap
ldap_access_filter = (memberOf=cn=linux-admins,ou=groups,dc=example,dc=com)

Проверка доступа (ldap_access_order) умеет и другие правила — срок действия учётной записи (ldap_account_expire_policy), блокировку, выход за пределы кэша. Но начинать всегда стоит с одного фильтра: предсказуемо и видно, что происходит.

TLS и сертификаты

Открытый LDAP в сети — это пароль учётной записи, уходящий по сети. Поэтому:

ldaps:// (порт 636) — TLS устанавливается сразу;
ldap:// + ldap_id_use_start_tls = true (порт 389) — соединение начинается открытым и шифруется командой StartTLS.

Если сертификат выдан своим удостоверяющим центром, его надо предъявить SSSD, иначе проверка не пройдёт:

ldap_tls_cacert = /etc/ssl/certs/ca-certificates.crt

Полный список опций TLS (ldap_tls_cert, ldap_tls_key, ldap_tls_reqcert, ldap_tls_cipher_suite) — в man 5 sssd-ldap.

Порядок проверки

Идти надо снизу вверх: сначала «видит ли каталог обычный инструмент», потом «видит ли SSSD», и только потом «пускает ли вход».

# 1. Каталог отвечает и служебная учётка читает дерево
$ ldapsearch -x -H ldaps://ldap.example.com \
    -D 'cn=sssd-reader,ou=services,dc=example,dc=com' -W \
    -b 'dc=example,dc=com' '(uid=user)' uid uidNumber gidNumber

# 2. SSSD нашёл того же пользователя
$ getent passwd user@ldap.example.com
$ id user@ldap.example.com

# 3. Вход и доступ
$ sudo sssctl user-checks user@ldap.example.com

# 4. Кэш и журнал, если что-то не сходится
$ sudo sss_cache -E
$ sudo tail -n 50 /var/log/sssd/sssd_ldap.example.com.log

Если ldapsearch находит пользователя, а getent — нет, дело почти всегда в трёх вещах: не тот ldap_search_base, отсутствует uidNumber без ldap_id_mapping, или каталог не пускает служебную учётную запись по фильтру поиска.

Каталог есть, а пароль меняют в нём

Смена пароля через SSSD (passwd для доменного пользователя) требует, чтобы каталог разрешал запись. Опции ldap_chpass_uri, ldap_chpass_dns_service_name и ldap_chpass_update_last_change — в man 5 sssd-ldap. Если запись запрещена, пароль меняют инструментами каталога, а SSSD только читает.

Источники

man 5 sssd-ldap — перечень опций ldap_* и их значения по умолчанию; man 5 sssd-ldap-attributes — сопоставление атрибутов; man 5 sssd.conf — общие опции. Пакет sssd-common 2.12.0-1ubuntu5.5 (проверено 18.10.2026).
man 1 ldapsearch — пакет ldap-utils.

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

Конфиг сверен с man-страницами пакета, но не запускался: каталога LDAP у нас нет. Это описание настроек, а не отчёт о прогоне.
Сопоставление атрибутов (sssd-ldap-attributes) зависит от того, как заведён конкретный каталог: без доступа к нему правильный набор атрибутов не подобрать.

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