LDAP-аутентификация в Linux: настройка клиента, PAM, NSS и SSSD

LDAP-аутентификация в Linux обычно строится вокруг SSSD. Этот демон получает записи пользователей и групп из LDAP-каталога, кэширует разрешенные данные и связывает каталог с системными механизмами NSS и PAM.

NSS отвечает за поиск учетных записей: команды getent и id получают через него UID, GID, группы, shell и домашний каталог. PAM обрабатывает проверку пароля, ограничения учетной записи и создание сеанса. SSSD передает эти запросы LDAP-серверу по LDAPS или через StartTLS.

После настройки LDAP-пользователь должен находиться командами getent passwd имя и id имя, проходить проверку пароля при входе по SSH, получать корректные группы и домашний каталог. Локальный root и аварийная учетная запись должны сохранять доступ независимо от состояния LDAP.

Короткий ответ: как работает LDAP-аутентификация в Linux

Рекомендуемый путь: SSSD как клиент LDAP

Для нового подключения Linux к LDAP используйте SSSD. Он выполняет несколько задач в одном согласованном стеке:

• получает идентичности пользователей и групп из каталога;
• проверяет пароль через LDAP bind;
• передает данные в NSS через библиотеку libnss-sss;
• обрабатывает вход и этапы сеанса через pam_sss.so;
• кэширует разрешенные записи и учетные данные для временной работы без LDAP;
• поддерживает несколько серверов и переключение при отказе одного endpoint.

Для OpenLDAP с POSIX-атрибутами обычно задают id_provider = ldap и auth_provider = ldap. Для Active Directory чаще выбирают провайдер ad, поскольку ему нужны DNS, Kerberos, realm и особенности схемы AD. Универсальная LDAP-конфигурация для AD может дать неполные группы, ошибки поиска или неправильную обработку входа.

Практическая конфигурация SSSD с failover и кэшированием разобрана в отдельном руководстве по централизованной аутентификации Linux.

Что должно заработать в результате

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

• getent passwd alice возвращает запись LDAP-пользователя;
• getent group linux-admins показывает LDAP-группу;
• id alice выводит UID, первичную и дополнительные группы;
• пароль пользователя проходит через PAM при входе по SSH;
• политика доступа разрешает вход только нужным пользователям или группам;
• домашний каталог создается автоматически либо уже существует;
• shell из атрибута loginShell присутствует в /etc/shells;
• TLS проверяет сертификат сервера и имя в поле SAN;
• локальный root может войти при недоступном LDAP.

Роли LDAP, SSSD, NSS и PAM в одной схеме

Как проходит запрос на вход

При входе через SSH запрос проходит через несколько уровней:

sshd или login
  -> PAM
  -> pam_sss.so
  -> SSSD
  -> TLS-соединение
  -> LDAP-сервер

sshd или системная команда
  -> NSS
  -> libnss-sss
  -> SSSD
  -> запись пользователя или группы в LDAP

Сначала sshd вызывает PAM. Модуль pam_sss.so передает имя и пароль SSSD. Демон устанавливает защищенное соединение, находит запись пользователя и выполняет bind от имени этого пользователя или через предусмотренный LDAP-механизм. PAM получает результат проверки, а NSS в процессе создания сеанса предоставляет UID, GID, группы, домашний каталог и shell.

Один и тот же вход может обратиться к NSS несколько раз. Например, SSH проверяет имя пользователя, система получает группы, а shell ищет домашний каталог. Поэтому успешный LDAP bind сам по себе не гарантирует успешный вход.

Поиск пользователя, проверка пароля и контроль доступа

У этих операций разные ответственные компоненты:

Пользователь может находиться через id, но получать отказ при входе. Причина часто связана с access_provider, правилом AllowGroups, запрещенным shell, сроком действия записи или PAM-модулем account.

Успешный TLS-сеанс подтверждает доверие к серверу и шифрование канала. Он не выдает пользователю право на вход и не добавляет его в sudo-группу.

Кэш SSSD и локальные учетные записи

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

Локальные пользователи и LDAP-пользователи обрабатываются через порядок источников в /etc/nsswitch.conf. Если локальная запись и LDAP-запись имеют одинаковое имя, система может использовать локальный UID, а группы получать из другого источника. Такие совпадения нужно запрещать правилами каталога.

Для локального аварийного доступа оставьте root или отдельную локальную учетную запись администратора. Проверьте вход в отдельной SSH-сессии до изменения PAM и не закрывайте текущую root-сессию, пока тест не завершен.

Подготовка клиента Linux перед подключением

Какие параметры каталога нужно получить заранее

До установки PAM и NSS запросите у администратора каталога точные значения. Подбор параметров методом проб увеличивает риск неверного поиска и блокировки bind-учетной записи.

• LDAP URI, например ldaps://ldap.example.test:636 или ldap://ldap.example.test:389 с StartTLS;
• Base DN, например dc=example,dc=test;
• ветку пользователей, например ou=people,dc=example,dc=test;
• ветку групп, например ou=groups,dc=example,dc=test;
• bind DN технической учетной записи и способ хранения секрета;
• схему каталога, обычно RFC 2307 или RFC 2307bis;
• атрибуты имени, UID, GID, домашнего каталога и shell;
• формат членства в группах: memberUid или member;
• требования к именам пользователей и формат fully qualified names;
• корневой или промежуточный сертификат CA.

DNS, сеть и время до настройки аутентификации

Проверьте имя LDAP-сервера с самого клиента:

getent hosts ldap.example.test
resolvectl query ldap.example.test
ip route get 192.0.2.10

Откройте только нужный порт на сетевых экранах. Для LDAPS нужен TCP 636, для LDAP с StartTLS обычно TCP 389. Имя в ldap_uri должно совпадать с DNS-именем в SAN сертификата. Подключение по IP при сертификате на DNS-имя вызовет ошибку проверки имени.

Синхронизируйте время через настроенный NTP-клиент. Неверная дата ломает проверку срока действия сертификата, а для Active Directory дополнительно нарушает Kerberos-аутентификацию. Проверьте:

timedatectl status
chronyc tracking

Для временного тестового клиента можно использовать облачный VPS, например сервер Timeweb Cloud. Разместите его в сети с теми же DNS-маршрутами и правилами firewall, которые получит рабочий Linux-клиент.

Debian, Ubuntu, RHEL и совместимые системы

Названия пакетов и управление PAM зависят от семейства дистрибутива:

Пакеты и имена служб могут меняться между версиями. Перед изменением PAM сохраните текущую конфигурацию и проверьте документацию конкретного выпуска.

OpenLDAP и Active Directory: что меняется

OpenLDAP часто отдает POSIX-поля напрямую. Для такой схемы SSSD получает uidNumber, gidNumber, homeDirectory и loginShell. Группы RFC 2307 обычно хранят участников через memberUid, а RFC 2307bis использует DN в атрибуте member.

Active Directory хранит пользователей и группы в другой схеме. Для него часто нужны DNS-записи контроллеров, корректный realm, Kerberos и провайдер SSSD ad. Если AD используется как LDAP-каталог без Kerberos, заранее проверьте формат POSIX-атрибутов и правила поиска групп. Успешный запрос по LDAP не подтверждает корректность доменной аутентификации.

Настройка LDAP клиента Linux через SSSD

Установка SSSD и вспомогательных пакетов

На Debian и Ubuntu установите минимальный стек:

sudo apt update
sudo apt install sssd sssd-ldap libnss-sss libpam-sss ldap-utils libpam-mkhomedir

На RHEL и Rocky Linux используйте соответствующие пакеты:

sudo dnf install sssd sssd-ldap libnss_sss libpam_sss openldap-clients authselect oddjob oddjob-mkhomedir

sssd-ldap содержит LDAP-провайдер, libnss-sss связывает NSS с SSSD, а libpam-sss подключает PAM. ldap-utils или openldap-clients нужны для проверки каталога через ldapsearch. Пакет создания домашнего каталога можно добавить после успешной проверки идентичности.

Базовая конфигурация /etc/sssd/sssd.conf

Создайте файл /etc/sssd/sssd.conf с правами 600. Ниже приведен пример для OpenLDAP с LDAPS и схемой RFC 2307bis:

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

[domain/LDAP]
id_provider = ldap
auth_provider = ldap
chpass_provider = ldap

ldap_uri = ldaps://ldap.example.test:636
ldap_search_base = dc=example,dc=test
ldap_user_search_base = ou=people,dc=example,dc=test
ldap_group_search_base = ou=groups,dc=example,dc=test
ldap_schema = rfc2307bis

ldap_default_bind_dn = uid=svc_linux,ou=service,dc=example,dc=test
ldap_default_authtok_type = password
ldap_default_authtok = CHANGE_ME

ldap_tls_reqcert = demand
ldap_tls_cacert = /etc/ssl/certs/ca-certificates.crt
cache_credentials = true
enumerate = false
fallback_homedir = /home/%u
default_shell = /bin/bash
access_provider = ldap

В RHEL-подобной системе путь к общему хранилищу CA часто выглядит как /etc/pki/tls/certs/ca-bundle.crt. Уточните путь в конкретной системе.

Параметр ldap_default_authtok показан для полноты примера. Техническая учетная запись должна иметь минимальные права чтения, а секрет нельзя хранить в открытом репозитории, командной истории или общем скрипте. Файл SSSD должен принадлежать root:

sudo chown root:root /etc/sssd/sssd.conf
sudo chmod 600 /etc/sssd/sssd.conf
sudo sssctl config-check

Если каталог разрешает анонимное чтение нужных веток, bind DN можно не задавать. Такой режим подходит только при осознанной политике доступа: пароль пользователя все равно нужно передавать по TLS.

Сопоставление LDAP-атрибутов с Linux-учетной записью

SSSD должен получить уникальный UID и GID. Если пользователь находится через LDAP-поиск, но id завершается ошибкой, проверьте наличие и числовой формат uidNumber и gidNumber.

Поля homeDirectory и loginShell определяют параметры сеанса. Если каталог не хранит их для каждого пользователя, задайте значения по умолчанию:

fallback_homedir = /home/%u
default_shell = /bin/bash

Для RFC 2307 SSSD обычно использует memberUid. Для RFC 2307bis укажите вложенность групп и DN-ориентированный атрибут:

ldap_schema = rfc2307bis
ldap_group_member = member
ldap_group_nesting_level = 3

Глубина вложенных групп увеличивает число запросов. Значение 3 подходит для типовой структуры, но его нужно сопоставить с реальной моделью доступа.

Проверяйте уникальность UID и GID во всем каталоге. Совпадение uidNumber у двух пользователей может привести к одинаковым правам на файлы, даже если их имена различаются. Коллизии имен с локальными пользователями требуют отдельного запрета или четкого порядка NSS.

Подключение SSSD к NSS и PAM

Добавьте источник sss в существующие строки passwd и group файла /etc/nsswitch.conf. Не заменяйте всю строку без проверки текущих источников:

passwd:         compat systemd sss
group:          compat systemd sss
shadow:         compat

В некоторых системах строки выглядят иначе. Сохраните локальные источники и добавьте sss в конец, если локальные записи должны проверяться первыми.

В Debian и Ubuntu запустите:

sudo pam-auth-update

Включите профиль SSSD и создание домашнего каталога, если такая опция доступна. Не отключайте локальные PAM-модули без проверки порядка.

В RHEL и Rocky Linux сначала посмотрите активный профиль:

authselect current

Для стандартного профиля SSSD с автоматическим созданием home используют:

sudo authselect select sssd with-mkhomedir

Команда может заменить управляемые файлы PAM. Перед запуском сохраните текущую конфигурацию и убедитесь, что выбран правильный профиль.

После изменения конфигурации запустите SSSD:

sudo systemctl enable --now sssd
sudo systemctl status sssd --no-pager

Порядок PAM влияет на локального root, смену пароля, account-проверки и обработку ошибок. Первую проверку выполняйте в отдельной SSH-сессии, оставляя рабочий административный канал открытым.

SSSD или nslcd: выбор для нового подключения

Для нового подключения выберите один стек. Одновременное включение SSSD и nslcd усложняет порядок NSS, создает лишние запросы и затрудняет поиск причины отказа. При миграции меняйте источник поэтапно и проверяйте локальный вход после каждого изменения.

Защищенное подключение: LDAPS или StartTLS

LDAPS через порт 636

При LDAPS клиент устанавливает TLS-соединение сразу после подключения к TCP 636. LDAP bind выполняется внутри уже зашифрованного канала.

ldap_uri = ldaps://ldap.example.test:636
ldap_tls_reqcert = demand
ldap_tls_cacert = /etc/ssl/certs/ca-certificates.crt

Сертификат сервера должен содержать имя ldap.example.test в SAN. Клиент должен доверять корневому или промежуточному CA, а сервер должен отправлять полную цепочку, если этого требует конфигурация клиента.

StartTLS на порту 389

При StartTLS клиент сначала подключается к обычному LDAP endpoint, отправляет команду StartTLS и продолжает сессию только после успешного перехода в TLS. Bind должен выполняться после этой команды.

ldap_uri = ldap://ldap.example.test:389
ldap_id_use_start_tls = true
ldap_tls_reqcert = demand
ldap_tls_cacert = /etc/ssl/certs/ca-certificates.crt

Для ручной проверки используйте режим -ZZ у ldapsearch. Он завершает команду при ошибке StartTLS и не продолжает запрос в открытом виде. Слабый режим, который разрешает продолжить соединение без TLS, создает риск downgrade.

Когда выбрать LDAPS, а когда StartTLS

Выбирайте режим, который поддерживают LDAP-сервер и все клиенты. Для обоих вариантов требуются проверка CA, контроль SAN и запрет передачи паролей через обычный незашифрованный канал.

CA, цепочка сертификатов и проверка SAN

Установите CA в системное хранилище доверия. На Debian и Ubuntu после добавления сертификата обычно обновляют индекс командой:

sudo update-ca-certificates

На RHEL и Rocky Linux используют хранилище anchors и обновляют его:

sudo update-ca-trust extract

Путь к CA в SSSD должен указывать на актуальное системное хранилище или на конкретный файл доверенного центра. Проверьте срок действия, цепочку, имя сервера и доступность промежуточного сертификата.

Параметры вроде ldap_tls_reqcert = never или ослабленной проверки подходят только для короткой диагностики в изолированной среде. В рабочей системе они позволяют принять подмененный сервер и раскрыть пароль bind или пользовательский пароль.

Проверка TLS-сеанса и bind

Для LDAPS сначала проверьте сам TLS-сеанс:

openssl s_client -connect ldap.example.test:636 -servername ldap.example.test -CAfile /etc/ssl/certs/ca-certificates.crt -verify_return_error </dev/null

Для StartTLS используйте режим LDAP:

openssl s_client -connect ldap.example.test:389 -starttls ldap -servername ldap.example.test -CAfile /etc/ssl/certs/ca-certificates.crt -verify_return_error </dev/null

В выводе проверьте выбранную версию TLS, цепочку сертификатов, результат проверки и имя endpoint. Затем отдельно проверьте bind и поиск:

ldapsearch -H ldaps://ldap.example.test:636 -x -D 'uid=svc_linux,ou=service,dc=example,dc=test' -W -b 'dc=example,dc=test' '(uid=alice)' uid uidNumber gidNumber homeDirectory loginShell

Ключ -W запрашивает пароль интерактивно. Не передавайте секрет после -w, чтобы он не попал в историю shell и список процессов.

PAM, NSS и права LDAP-пользователей после подключения

Проверка пользователя через NSS

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

getent passwd alice
getent group linux-admins
id alice

В записи должны присутствовать UID, первичная группа, домашний каталог и shell. Команда id должна показать дополнительные группы, которые используются правилами SSH или sudo.

Если getent ничего не возвращает, проблема находится в NSS, SSSD, LDAP search base, фильтре или схеме атрибутов. На этом этапе неправильный пароль не имеет значения, поскольку PAM еще не проверял учетные данные.

Проверка пароля через PAM

Проверяйте вход на тестовом пользователе через отдельное SSH-соединение:

ssh alice@linux-client.example.test

Не закрывайте текущую административную сессию. После входа проверьте пользователя и группы:

whoami
id
printf '%s\n' "$SHELL"
pwd

Если пароль принимается, но вход завершается сразу после аутентификации, проверяйте PAM account, shell, домашний каталог и правила sshd. Если пароль отклоняется, сопоставьте журналы PAM и SSSD с результатом пользовательского bind.

Домашний каталог, shell и окружение

Linux не всегда создает home автоматически. Для Debian и Ubuntu это можно включить через pam_mkhomedir.so. В RHEL-подобных системах применяют профиль authselect с with-mkhomedir и службу oddjob.

Проверьте shell:

getent passwd alice
cat /etc/shells
ls -ld /home/alice

Значение loginShell должно существовать в /etc/shells. Домашний каталог должен принадлежать правильному UID и иметь ожидаемые права. Если LDAP отдает путь на общий NFS-ресурс, отдельно проверьте DNS, mount и права файловой системы.

Доступ по LDAP-группам и принцип default deny

Не разрешайте SSH всем пользователям каталога без явной причины. Ограничьте доступ группой через SSSD или sshd.

Пример ограничения в SSSD:

access_provider = simple
simple_allow_groups = linux-login

Другой вариант, если правила доступа уже задаются LDAP-провайдером:

access_provider = ldap
ldap_access_filter = memberOf=cn=linux-login,ou=groups,dc=example,dc=test

Синтаксис фильтра зависит от схемы каталога. Для групп RFC 2307 с memberUid фильтр по memberOf может не сработать, потому что каталог не хранит обратное членство.

На уровне SSH можно использовать:

AllowGroups linux-login local-admins

После изменения sshd_config сначала проверьте синтаксис:

sudo sshd -t

Сохраните локальную административную группу в разрешенном списке либо убедитесь, что локальный root может использовать консольный вход. Правила доступа проверяйте на пользователе из разрешенной и запрещенной групп.

Практика настройки LDAP-групп, фильтров и ролей подробно разобрана в руководстве по группам LDAP и разграничению прав.

Связь групп LDAP с sudo

Членство в LDAP-группе не выдает sudo-права автоматически. Для административных команд нужно отдельное правило sudoers и проверка состава группы.

Пример правила для группы с полным административным доступом:

%linux-admins ALL=(ALL:ALL) ALL

Размещайте такие правила в отдельном файле через visudo, например в каталоге /etc/sudoers.d. После входа пользователя проверьте:

id alice
sudo -l -U alice

Сокращайте набор команд, если группе не нужен полный root-доступ. Разделяйте группу, которая может входить на сервер, и группу, которая может выполнять административные команды.

Проверка подключения Linux к LDAP в правильном порядке

Сеть и TLS endpoint

1. Проверьте DNS-имя LDAP-сервера через getent hosts или resolvectl.
2. Проверьте маршрут и доступность TCP 389 или 636.
3. Проверьте TLS через openssl s_client.
4. Сверьте имя в URI с SAN сертификата.
5. Убедитесь, что клиент доверяет CA и сервер отдает полную цепочку.

Если TLS не проходит, переходить к PAM и проверке пароля рано. Исправьте транспорт и доверие к сертификату.

Bind и LDAP-поиск через ldapsearch

Сначала проверьте техническую учетную запись:

ldapwhoami -H ldaps://ldap.example.test:636 -x -D 'uid=svc_linux,ou=service,dc=example,dc=test' -W

Затем выполните поиск пользователя:

ldapsearch -H ldaps://ldap.example.test:636 -x -D 'uid=svc_linux,ou=service,dc=example,dc=test' -W -b 'ou=people,dc=example,dc=test' '(uid=alice)' uid uidNumber gidNumber gid homeDirectory loginShell

Проверьте Base DN, фильтр, objectClass и обязательные POSIX-атрибуты. Отдельно проверьте поиск группы и атрибут членства. Пароль пользователя тестируйте через интерактивный bind или SSH, не записывая его в историю.

NSS-проверка через getent и id

После успешного LDAP-поиска перезапустите или обновите SSSD и выполните:

sudo systemctl restart sssd
getent passwd alice
getent group linux-login
id alice

Сопоставьте вывод с ldapsearch. UID и GID должны совпадать, shell должен существовать, домашний каталог должен иметь ожидаемый путь. Если ldapsearch видит запись, а getent нет, проверяйте nsswitch.conf, домен SSSD и кэш.

PAM- и SSH-вход

Проверьте реальный пользовательский сценарий на отдельном тестовом клиенте или в отдельной сессии:

1. введите имя LDAP-пользователя;
2. проверьте пароль;
3. убедитесь, что account-проверка разрешает вход;
4. проверьте выдачу групп;
5. проверьте создание home и запуск shell;
6. проверьте правила доступа и sudo отдельно.

Успешный ldapsearch не заменяет этот тест. LDAP-поиск не проверяет полный PAM-стек, фильтр доступа, shell и создание сеанса.

sssctl, systemctl и журналы

Проверьте конфигурацию и состояние служб:

sudo sssctl config-check
sudo systemctl status sssd --no-pager
sudo journalctl -u sssd -b --no-pager

Для SSH и PAM используйте журналы конкретной системы:

sudo journalctl -u ssh -b --no-pager
sudo journalctl -u sshd -b --no-pager
sudo journalctl -b | grep -Ei 'sssd|pam|ldap|tls'

Названия службы SSH отличаются между дистрибутивами. По журналам разделяйте ошибки конфигурации, отказ bind, таймаут, недоверенный сертификат, отсутствие пользователя и отказ access provider.

Типовые ошибки LDAP-аутентификации в Linux

TLS handshake, SAN и недоверенный сертификат

Симптомы: SSSD не запускается, ldapsearch сообщает ошибку TLS, в журнале появляются unknown ca, certificate verify failed или ошибка имени.

• проверьте срок действия сертификата;
• сверьте SAN с именем в ldap_uri;
• проверьте всю цепочку сертификатов;
• убедитесь, что CA добавлен в системное хранилище;
• проверьте системное время;
• сопоставьте порт и режим: LDAPS либо StartTLS;
• проверьте поддерживаемую версию TLS.

Не исправляйте такую ошибку отключением проверки сертификата. Сначала установите правильный CA и исправьте имя endpoint.

Bind отклонен или каталог возвращает таймаут

При ошибке bind проверьте DN, секрет, срок действия и блокировку технической учетной записи. Убедитесь, что bind-пользователь имеет права чтения веток пользователей и групп.

При таймауте проверьте маршрут, firewall, балансировщик и доступность нужного LDAP-сервера. Если используется несколько endpoint, временно протестируйте каждый адрес отдельно. Пароль bind не должен находиться в истории shell, командной строке процесса или открытом файле журнала.

Пользователь не находится через getent

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

1. проверьте, что служба SSSD работает;
2. проверьте наличие sss в строках passwd и group;
3. сверьте ldap_search_base и отдельные базы пользователей и групп;
4. сопоставьте фильтр SSSD с objectClass записи;
5. проверьте uid, uidNumber, gidNumber;
6. сбросьте кэш только после подтверждения доступности LDAP.

Сначала сравните вывод ldapsearch и getent. Если запись видна в первом, но отсутствует во втором, причина находится между SSSD и NSS.

Пользователь найден, но вход запрещен

Проверьте access_provider, разрешенные группы, AllowGroups, PAM account, срок действия записи и shell. Убедитесь, что группа пришла через id, а SSSD не использует устаревший кэш.

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

Дублирование имен, UID/GID и устаревший кэш

Одинаковые UID и GID приводят к совпадению владельцев файлов. Одинаковое имя локального и LDAP-пользователя затрудняет диагностику: NSS может вернуть локальную запись, а дополнительные группы получить из LDAP.

Проверьте уникальность идентификаторов, формат имен и срок жизни кэша. Очищайте кэш только после проверки LDAP и сохранения локального доступа. Конкретные команды очистки зависят от версии SSSD, поэтому сначала используйте диагностические команды sssctl и журналы.

Пошаговый порядок поиска причин для ошибок LDAP, Active Directory, TLS, bind и групп собран в шпаргалке по диагностике LDAP-аутентификации.

Эксплуатация и итоговый чек-лист настройки

Отказоустойчивость и работа при недоступности каталога

Для нескольких LDAP-серверов задайте несколько URI в конфигурации SSSD или используйте штатный механизм обнаружения, если его поддерживает ваш каталог:

ldap_uri = ldaps://ldap-1.example.test:636, ldaps://ldap-2.example.test:636

Проверьте таймауты и порядок переключения на резервный сервер. Резервный endpoint должен иметь совместимую схему, сертификат с правильным SAN и одинаковые данные пользователей.

Кэш SSSD помогает пережить краткий сетевой сбой, но не отменяет контроль отключенных учетных записей. Задайте допустимый срок offline authentication и проверьте, что локальный аварийный вход работает при полном отказе каталога.

Ротация сертификатов и bind-учетных данных

Сертификаты и секреты технических учетных записей нужно менять до истечения срока действия. Подготовьте процедуру:

1. выпустите новый сертификат или получите новую цепочку CA;
2. проверьте SAN и срок действия на тестовом клиенте;
3. обновите CA на небольшой группе клиентов;
4. замените bind-секрет в защищенной конфигурации;
5. проверьте ldapsearch, getent, PAM и SSH;
6. распространите изменения на остальные системы;
7. удалите старый секрет и зафиксируйте результат в журнале изменений.

Не храните пароли в публичных репозиториях, открытых скриптах и параметрах командной строки. Доступ к sssd.conf ограничьте root, а резервные копии файла шифруйте.

Чек-лист перед вводом в эксплуатацию

• DNS разрешает имена всех LDAP-серверов;
• маршрут и firewall пропускают выбранный порт;
• TLS handshake проходит без ошибок;
• SAN сертификата совпадает с именем в LDAP URI;
• клиент доверяет CA и полной цепочке;
• технический bind выполняется с минимальными правами;
• ldapsearch находит тестового пользователя и его группы;
• /etc/sssd/sssd.conf имеет права 600;
• sssctl config-check не сообщает об ошибках;
• в /etc/nsswitch.conf подключен источник sss;
• getent и id возвращают правильные UID, GID, группы, shell и home;
• PAM принимает пароль тестового пользователя;
• access policy разрешает нужную группу и блокирует лишних пользователей;
• домашний каталог создается с правильным владельцем;
• sudo-группа настроена отдельным правилом;
• журналы SSSD, PAM и SSH не содержат ошибок;
• проверен второй LDAP endpoint или предусмотрен понятный rollback;
• локальный root и аварийная учетная запись сохраняют доступ;
• описаны ротация сертификата, смена bind-секрета и очистка кэша.

Рабочая настройка LDAP в Linux подтверждается последовательной проверкой: DNS, TCP, TLS, bind, поиск записи, NSS, PAM, группы, SSH и домашний каталог. Такой порядок быстро показывает слой сбоя и снижает риск менять PAM или очищать кэш без причины.