Как включить LDAPS: сертификаты, TLS и требования к серверу

Короткий ответ: как включить LDAPS

LDAPS включают настройкой TLS на LDAP-сервере и запуском отдельного защищенного listener на TCP-порту 636. Серверу нужен X.509-сертификат с корректным именем в SAN, закрытый ключ и полная цепочка промежуточных сертификатов. Клиенту нужен доверенный корневой CA, иначе TLS-подключение завершится ошибкой проверки сертификата.

Открытый порт 636 подтверждает доступность сетевого пути и службы, но не подтверждает корректность LDAPS. До передачи bind-учетных данных клиент должен успешно выполнить TLS-handshake, проверить цепочку доверия и сопоставить имя в адресе подключения с SAN сертификата.

1. Выберите постоянное DNS-имя LDAP-сервера, например ldap01.example.internal.
2. Выпустите серверный сертификат с этим именем в SAN.
3. Укажите сертификат, ключ и CA в конфигурации LDAP-сервера.
4. Включите listener ldaps:///, перезапустите службу и откройте TCP/636 в межсетевом экране.
5. Установите корневой CA на каждый клиент.
6. Проверьте TLS-сеанс через openssl s_client, затем выполните bind через ldapsearch или ldapwhoami.
7. Для Linux-клиентов настройте SSSD с обязательной проверкой сертификата.

При миграции полезно заранее проверить старые приложения, скрипты и устройства: часть из них поддерживает только LDAP на 389 или требует отдельной настройки доверенного CA. Полный сценарий перехода описан в руководстве по переходу с LDAP на LDAPS.

Требования к сертификатам для LDAPS

Для LDAPS подготовьте сертификат сервера в формате X.509, соответствующий ему закрытый ключ и цепочку удостоверяющего центра. Чаще всего OpenLDAP использует PEM-файлы. Формат DER можно преобразовать в PEM:

openssl x509 -inform DER -in ldap01.cer -out /etc/ldap/tls/ldap01.pem

Сертификат должен содержать расширение Extended Key Usage со значением serverAuth. Для ключа обычно применяют RSA 3072 бит или ECDSA-ключ, разрешенный криптографической политикой организации. Закрытый ключ не должен быть доступен обычным пользователям и не должен требовать интерактивного ввода пароля при старте slapd.

При выпуске CSR внесите все реальные DNS-имена, по которым клиенты будут обращаться к каталогу. Common Name не заменяет SAN.

openssl req -new -newkey rsa:3072 -nodes -keyout /etc/ldap/tls/ldap01.key -out /etc/ldap/tls/ldap01.csr -subj '/CN=ldap01.example.internal' -addext 'subjectAltName = DNS:ldap01.example.internal,DNS:ldap.example.internal'

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

В каталоге сертификатов сервера обычно размещают три файла:

• ldap01-fullchain.pem, сертификат сервера, затем промежуточные сертификаты;
• ldap01.key, закрытый ключ сервера;
• company-root-ca.pem, корневой CA или набор доверенных CA.

Права на ключ должны ограничивать чтение учетной записью службы LDAP:

sudo chown openldap:openldap /etc/ldap/tls/ldap01.key
sudo chmod 600 /etc/ldap/tls/ldap01.key

Имя сервисной учетной записи зависит от дистрибутива. До перезапуска проверьте, что пользователь, под которым работает slapd, может прочитать ключ и сертификат.

Цепочка доверия и доверенный CA

Цепочка доверия связывает сертификат LDAP-сервера с корневым CA, которому доверяет клиент. Сервер отправляет свой сертификат и, как правило, промежуточные сертификаты. Клиент хранит корневой CA в системном доверенном хранилище или получает путь к нему в настройках приложения.

Проверьте цепочку до настройки службы. В примере файл issuing-ca.pem содержит промежуточный CA:

openssl verify -CAfile company-root-ca.pem -untrusted issuing-ca.pem ldap01.pem

Успешный результат содержит OK. Ошибка unable to get local issuer certificate означает, что отсутствует промежуточный или корневой сертификат. Ошибка certificate has expired требует перевыпуска сертификата или исправления системного времени.

Параметр olcTLSCACertificateFile на стороне OpenLDAP задает CA, которому доверяет сам сервер. Он нужен при проверке клиентских сертификатов и в конфигурациях с взаимной TLS-аутентификацией. Доверие клиента к сертификату LDAP-сервера настраивают отдельно, на каждом клиенте или в централизованном образе ОС.

Проверка SAN и имени сервера

Клиент сопоставляет DNS-имя из ldaps:// со значениями Subject Alternative Name. Если приложение подключается к ldaps://ldap01.example.internal, сертификат должен содержать DNS:ldap01.example.internal. При подключении по IP-адресу нужен соответствующий IP Address в SAN, но для LDAP лучше использовать DNS-имя.

openssl x509 -in /etc/ldap/tls/ldap01-fullchain.pem -noout -text | sed -n '/Subject Alternative Name/,+1p'

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

openssl s_client -connect ldap01.example.internal:636 -servername ldap01.example.internal -verify_hostname ldap01.example.internal -CAfile /etc/ssl/certs/company-root-ca.pem -verify_return_error < /dev/null

Используйте в SSSD, приложениях и командах диагностики то же имя, которое внесено в SAN. Подмена адреса на IP, короткое имя хоста или внутренний алиас без SAN часто вызывает ошибку проверки имени.

Настройка LDAPS на сервере

Пример ниже рассчитан на OpenLDAP со служебной конфигурацией cn=config. Перед изменениями сохраните текущую конфигурацию и убедитесь, что у вас остается доступ через локальный сокет ldapi:///. Выполняйте работы из консоли сервера или держите вторую административную сессию открытой.

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

Конфигурация OpenLDAP для LDAPS

Создайте LDIF-файл с путями к сертификату, ключу и CA. Значение 3.3 в olcTLSProtocolMin задает минимум TLS 1.2 в конфигурациях OpenLDAP, которые поддерживают этот параметр. Перед применением сверьте поддержку TLS-библиотеки и версии пакета в вашем дистрибутиве.

dn: cn=config
changetype: modify
replace: olcTLSCertificateFile
olcTLSCertificateFile: /etc/ldap/tls/ldap01-fullchain.pem
-
replace: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/ldap/tls/ldap01.key
-
replace: olcTLSCACertificateFile
olcTLSCACertificateFile: /etc/ldap/tls/company-root-ca.pem
-
replace: olcTLSProtocolMin
olcTLSProtocolMin: 3.3

Сохраните файл как tls.ldif и примените изменения через локальный сокет:

sudo ldapmodify -Y EXTERNAL -H ldapi:/// -f tls.ldif

В старых установках, где сервер запускается с slapd.conf, применяют эквивалентные директивы:

TLSCertificateFile /etc/ldap/tls/ldap01-fullchain.pem
TLSCertificateKeyFile /etc/ldap/tls/ldap01.key
TLSCACertificateFile /etc/ldap/tls/company-root-ca.pem
TLSProtocolMin 3.3

Не используйте одновременно активный slapd.conf и cn=config для одной службы. Проверьте параметры запуска slapd, чтобы понять, какой механизм читает сервер.

Сертификаты сами по себе не запускают LDAPS-listener. В Debian-подобных системах список URL часто задается в /etc/default/slapd, на системах семейства RHEL, в параметрах службы или systemd override. В список должен входить ldaps:///:

SLAPD_SERVICES='ldap:/// ldapi:/// ldaps:///'

После проверки конфигурации перезапустите службу:

sudo slaptest -u
sudo systemctl restart slapd
sudo systemctl status slapd

Открытие порта 636 и проверка доступности

Убедитесь, что процесс слушает TCP/636:

sudo ss -ltnp | grep ':636'

Разрешите входящий трафик из сетей клиентов. Для систем с firewalld подойдет правило:

sudo firewall-cmd --permanent --add-port=636/tcp
sudo firewall-cmd --reload

Проверьте TLS-handshake с другой машины, где установлен доверенный CA:

openssl s_client -connect ldap01.example.internal:636 -servername ldap01.example.internal -CAfile /etc/ssl/certs/company-root-ca.pem -verify_return_error -showcerts < /dev/null

В выводе должны присутствовать сертификаты сервера и промежуточных CA, а проверка должна завершиться кодом 0. Если соединение обрывается до показа сертификата, проверьте listener, межсетевой экран, балансировщик и сетевые ACL.

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

SSSD подходит для нового подключения Linux к LDAP. Служба запрашивает учетные записи через NSS и передает аутентификацию в PAM. NSS отвечает за поиск UID, GID, групп, shell и домашнего каталога. PAM проверяет пароль, ограничения учетной записи и создает пользовательский сеанс.

SSSD может хранить разрешенные записи и учетные данные в кэше для временной работы при недоступности каталога. Локальные root и аварийная учетная запись должны сохранять доступ независимо от LDAP и состояния SSSD.

Установите пакеты, подходящие для вашего дистрибутива:

sudo apt install sssd-ldap libnss-sss libpam-sss ldap-utils ca-certificates
sudo dnf install sssd-ldap openldap-clients ca-certificates

Полная схема интеграции SSSD с NSS, PAM и SSH разобрана в руководстве по LDAP-аутентификации в Linux.

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

Создайте /etc/sssd/sssd.conf с минимальной конфигурацией. Замените DNS-имя, базовый DN и имя домена на свои значения.

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

[nss]

[pam]

[domain/example.internal]
id_provider = ldap
auth_provider = ldap
ldap_uri = ldaps://ldap01.example.internal
ldap_search_base = dc=example,dc=internal
ldap_tls_reqcert = demand
ldap_tls_cacert = /etc/ssl/certs/company-root-ca.pem
ldap_id_use_start_tls = false
cache_credentials = true
enumerate = false

Параметр ldap_tls_reqcert = demand запрещает соединение при недоверенном сертификате или ошибке имени. Не ослабляйте проверку до allow или never в рабочей среде: это скрывает проблему с PKI и создает риск подключения к подмененному серверу.

Если каталог запрещает анонимный поиск, добавьте bind-учетную запись с минимальными правами чтения нужных объектов. Секрет хранится в sssd.conf, поэтому файл должен быть доступен только root:

ldap_default_bind_dn = uid=sssd-bind,ou=Service Accounts,dc=example,dc=internal
ldap_default_authtok_type = password
ldap_default_authtok = CHANGE_THIS_SECRET

sudo chown root:root /etc/sssd/sssd.conf
sudo chmod 600 /etc/sssd/sssd.conf
sudo systemctl enable --now sssd

Bind-учетной записи достаточно доступа на поиск пользователей и групп в нужных ветках каталога. Не выдавайте ей права изменения записей, сброса паролей или чтения атрибутов, которые клиенту не нужны.

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

В /etc/nsswitch.conf добавьте sss после локального источника:

passwd: files sss
group:  files sss
shadow: files sss

На системах семейства RHEL настройку PAM обычно выполняют через authselect. Перед сменой профиля проверьте локальные изменения PAM и сохраните консольный доступ администратора:

sudo authselect select sssd with-mkhomedir
sudo authselect apply-changes

В Debian-подобных системах используйте pam-auth-update и включите профиль SSSD. Создание домашнего каталога при первом входе настраивается модулем pam_mkhomedir.so через стандартный механизм PAM дистрибутива. После изменения конфигурации перезапустите SSSD:

sudo systemctl restart sssd
sudo sssctl config-check

Проверка LDAPS-подключения

Проверяйте соединение в три этапа: TLS-сеанс, LDAP bind и видимость пользователей через NSS. Это быстро отделяет ошибку сертификата от ошибки DN, пароля, ACL или PAM.

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

Сначала проверьте сертификат, цепочку и имя сервера:

openssl s_client -connect ldap01.example.internal:636 -servername ldap01.example.internal -verify_hostname ldap01.example.internal -CAfile /etc/ssl/certs/company-root-ca.pem -verify_return_error < /dev/null

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

ldapwhoami -x -H ldaps://ldap01.example.internal -D 'uid=ldap-reader,ou=Service Accounts,dc=example,dc=internal' -W
ldapsearch -x -H ldaps://ldap01.example.internal -D 'uid=ldap-reader,ou=Service Accounts,dc=example,dc=internal' -W -b 'dc=example,dc=internal' '(uid=alice)' uid cn

Для LDAPS указывают URL ldaps:// и не добавляют -ZZ. Ключ -ZZ требует StartTLS для соединения через ldap://, обычно на порту 389.

Успешный ldapwhoami возвращает DN аутентифицированной учетной записи. При успешном bind, но пустом результате поиска проверьте ldap_search_base, поисковый фильтр и ACL bind-учетной записи.

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

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

sudo sssctl domain-status example.internal
getent passwd alice
id alice

Команда getent passwd alice должна вернуть запись пользователя, а id alice, UID и группы. Для теста PAM откройте отдельную SSH-сессию или выполните:

su - alice

При первом тестировании не закрывайте текущую root-сессию. Если PAM или NSS настроены с ошибкой, локальный доступ позволит исправить конфигурацию без аварийной загрузки.

Типовые ошибки при включении LDAPS

Ошибка: сертификат не доверяет

На Debian и Ubuntu установите корневой сертификат CA в системное хранилище:

sudo install -m 0644 company-root-ca.crt /usr/local/share/ca-certificates/company-root-ca.crt
sudo update-ca-certificates

На RHEL, Rocky Linux, AlmaLinux и совместимых системах используйте каталог доверенных якорей:

sudo install -m 0644 company-root-ca.crt /etc/pki/ca-trust/source/anchors/company-root-ca.crt
sudo update-ca-trust

После установки повторите openssl s_client. В SSSD задайте путь к тому же CA через ldap_tls_cacert. Если сервер использует промежуточный CA, добавьте его в файл ldap01-fullchain.pem после сертификата сервера.

Ошибка: имя сервера не совпадает с SAN

Посмотрите SAN в фактически выданном сертификате:

openssl s_client -connect ldap01.example.internal:636 -servername ldap01.example.internal -showcerts < /dev/null
openssl x509 -in ldap01.pem -noout -ext subjectAltName

Частая причина ошибки: в конфигурации SSSD указан IP-адрес, короткое имя ldap01 или CNAME, которого нет в сертификате. Исправьте URL на имя из SAN либо перевыпустите сертификат. Не отключайте проверку имени на клиенте.

При сложных случаях проверьте системное время, DNS-ответы, Base DN, ACL и кэш SSSD. Готовая последовательность команд собрана в шпаргалке по диагностике LDAP-аутентификации.

LDAPS или StartTLS: что выбрать?

Для нового развертывания выбирайте LDAPS, если в сети доступен 636 и клиенты поддерживают схему ldaps://. Такой вариант проще отличить в конфигурации и правилах межсетевого экрана. StartTLS подходит, когда инфраструктура уже использует 389 или приложение ожидает upgrade соединения.

Оба варианта защищают учетные данные при корректной проверке CA, SAN и запрете небезопасного bind до TLS. Сравнение совместимости OpenLDAP, Active Directory, клиентских библиотек и команд диагностики приведено в разборе LDAPS и StartTLS.

Итоговый чек-лист настройки LDAPS

• Для LDAP-сервера выбран постоянный FQDN, который используют все клиенты.
• Сертификат содержит этот FQDN в SAN и имеет назначение serverAuth.
• Сервер хранит сертификат, закрытый ключ и промежуточные сертификаты в защищенном каталоге.
• Ключ доступен процессу slapd и недоступен обычным пользователям.
• В OpenLDAP заданы olcTLSCertificateFile, olcTLSCertificateKeyFile и olcTLSCACertificateFile.
• Служба запущена с URL ldaps:/// и слушает TCP/636.
• Межсетевой экран разрешает TCP/636 только нужным клиентским сетям.
• Корневой CA установлен в доверенное хранилище каждого клиента.
• openssl s_client подтверждает цепочку и имя сервера без ошибок.
• ldapwhoami и ldapsearch успешно выполняют bind по ldaps://.
• SSSD использует ldap_tls_reqcert = demand, а NSS и PAM подключены к sss.
• Проверены getent passwd, id и вход тестового пользователя по SSH.
• Локальные root и аварийная учетная запись остаются доступны при сбое LDAP.

После настройки добавьте контроль срока действия сертификата и повторяйте проверку TLS после смены CA, обновления OpenLDAP, изменения DNS или перевыпуска сертификата. Это позволяет обнаружить проблему до того, как она затронет вход пользователей в рабочие системы.