LDAP vs LDAPS: Пошаговая настройка безопасного подключения к каталогу в 2026

Почему LDAP без шифрования - это рискованно

LDAP-трафик на порту 389 передаёт учётные данные и содержимое каталога в открытом виде. Любой, кто получил доступ к сегменту сети между клиентом и сервером, может перехватить пароли, имена пользователей и структуру каталога с помощью сниффера вроде tcpdump или Wireshark. Это не теоретическая угроза: атака man-in-the-middle на открытый LDAP-канал позволяет злоумышленнику не только читать данные, но и подменять ответы сервера, перенаправляя аутентификацию на подконтрольный хост.

LDAPS решает эту проблему на корневом уровне. Протокол оборачивает весь обмен данными в TLS/SSL-туннель с момента установки соединения на порту 636. Даже если трафик будет перехвачен, злоумышленник получит зашифрованный набор байтов, не поддающийся расшифровке без закрытого ключа сервера. В 2026 году эксплуатация открытого LDAP в production-среде - прямое нарушение базовых требований безопасности. Стандарты вроде PCI DSS и внутренние политики компаний требуют обязательного шифрования каталогов. Если ваша инфраструктура до сих пор полагается на порт 389 без TLS, вы оставляете критический вектор атаки открытым.

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

LDAP и LDAPS: в чем разница и когда что использовать

Три варианта подключения к LDAP-каталогу отличаются принципиально: открытый LDAP, LDAP с StartTLS и LDAPS. Открытый LDAP на порту 389 не использует шифрования. StartTLS начинает соединение на том же порту 389, а затем пытается повысить его до TLS командой STARTTLS. LDAPS устанавливает зашифрованный TLS-канал сразу на выделенном порту 636.

Главная проблема StartTLS - уязвимость к downgrade-атакам. Злоумышленник, контролирующий сетевой канал, может перехватить команду STARTTLS и заставить клиента продолжить работу без шифрования. Клиент, настроенный на StartTLS, может молча переключиться на открытый текст, если сервер не поддержит команду. LDAPS исключает этот сценарий: соединение либо устанавливается зашифрованным, либо разрывается. Никакого промежуточного состояния нет.

Сравнительная таблица вариантов подключения:

Для новых развёртываний выбирайте LDAPS. Если мигрируете существующую инфраструктуру и не можете сразу переключить всех клиентов на порт 636, настройте StartTLS с обязательным требованием шифрования и отключите возможность отката к открытому тексту.

Порты 389 и 636: что нужно знать администратору

Порт 389 обслуживает два режима: открытый LDAP и StartTLS. Если вы полностью перешли на LDAPS, закройте порт 389 на файрволе для всех клиентов. Это исключит случайные подключения без шифрования и предотвратит downgrade-атаки на клиентах, которые по ошибке пытаются использовать StartTLS.

Порт 636 предназначен исключительно для LDAPS. На файрволах откройте его только для доверенных подсетей клиентов. Правило для iptables выглядит так:

iptables -A INPUT -p tcp -s 10.0.1.0/24 --dport 636 -j ACCEPT
iptables -A INPUT -p tcp --dport 636 -j DROP

Для nftables используйте:

nft add rule inet filter input ip saddr 10.0.1.0/24 tcp dport 636 accept
nft add rule inet filter input tcp dport 636 drop

Проверьте, что порт 389 не слушается извне. На сервере выполните ss -tlnp | grep 389 и убедитесь, что процесс slapd или контроллер домена слушает только localhost или внутренний интерфейс.

Пошаговая настройка LDAPS на сервере OpenLDAP

Включение LDAPS на OpenLDAP состоит из трёх этапов: генерация сертификата, конфигурация slapd для его использования и проверка результата. Инструкция проверена на OpenLDAP 2.6, но применима к версиям 2.4 и 2.5 с минимальными отличиями в путях.

Генерация сертификата для OpenLDAP с помощью OpenSSL

Создайте корневой CA и серверный сертификат одной командной последовательностью. Параметр -days 3650 задаёт срок действия 10 лет - этого достаточно для внутреннего CA, но для публичных сертификатов сократите до 1-2 лет. Параметр -nodes создаёт ключ без парольной фразы, что необходимо для автоматического запуска slapd без ручного ввода пароля.

# Создание корневого CA
openssl genrsa -out ca.key 4096
openssl req -new -x509 -days 3650 -key ca.key -out ca.crt \
  -subj "/C=RU/ST=Moscow/L=Moscow/O=Admin-Wiki/CN=Internal CA"

# Создание ключа и CSR сервера
openssl genrsa -out ldap-server.key 4096
openssl req -new -key ldap-server.key -out ldap-server.csr \
  -subj "/C=RU/ST=Moscow/L=Moscow/O=Admin-Wiki/CN=ldap.example.com"

# Подпись серверного сертификата
openssl x509 -req -days 3650 -in ldap-server.csr -CA ca.crt -CAkey ca.key \
  -set_serial 01 -out ldap-server.crt

Критически важно: значение CN в серверном сертификате должно точно совпадать с FQDN LDAP-сервера, который клиенты указывают в URI. Если клиент подключается на ldaps://ldap.example.com:636, а сертификат выдан на CN=localhost, проверка сертификата завершится ошибкой certificate verify failed.

После генерации скопируйте файлы в системные директории и установите права, исключающие чтение закрытого ключа посторонними:

cp ca.crt /etc/ssl/certs/
cp ldap-server.crt /etc/ssl/certs/
cp ldap-server.key /etc/ssl/private/
chmod 640 /etc/ssl/private/ldap-server.key
chown root:ssl-cert /etc/ssl/private/ldap-server.key

Конфигурация slapd для поддержки LDAPS

Для статической конфигурации через slapd.conf добавьте директивы TLS в файл:

TLSCertificateFile /etc/ssl/certs/ldap-server.crt
TLSCertificateKeyFile /etc/ssl/private/ldap-server.key
TLSCACertificateFile /etc/ssl/certs/ca.crt

Для динамической конфигурации через cn=config (стандарт в современных дистрибутивах) создайте LDIF-файл и примените его:

dn: cn=config
changetype: modify
add: olcTLSCertificateFile
olcTLSCertificateFile: /etc/ssl/certs/ldap-server.crt
-
add: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/ssl/private/ldap-server.key
-
add: olcTLSCACertificateFile
olcTLSCACertificateFile: /etc/ssl/certs/ca.crt

# Применение
ldapmodify -Y EXTERNAL -H ldapi:/// -f tls-config.ldif

Убедитесь, что slapd слушает порт 636. В файле /etc/default/slapd (Debian/Ubuntu) или /etc/sysconfig/slapd (RHEL/CentOS) укажите:

SLAPD_URLS="ldapi:/// ldap:/// ldaps:///"

Перезапустите службу и проверьте прослушивание порта:

systemctl restart slapd
ss -tlnp | grep 636

Тестирование подключения выполните командой ldapsearch с флагом принудительного TLS:

ldapsearch -x -H ldaps://ldap.example.com:636 -b "dc=example,dc=com" -D "cn=admin,dc=example,dc=com" -W

Если сертификат самоподписанный, добавьте флаг LDAPTLS_REQCERT=never только для теста. В production всегда используйте demand.

Включение LDAPS в Active Directory: установка сертификата

Контроллер домена Active Directory автоматически начинает обслуживать LDAPS на порту 636, как только в хранилище «Личное» учётной записи компьютера появляется валидный сертификат с закрытым ключом. Никаких дополнительных действий по настройке службы каталогов не требуется. Сертификат должен соответствовать двум требованиям: CN совпадает с FQDN контроллера домена, в расширенном использовании ключа (EKU) присутствует Server Authentication (OID 1.3.6.1.5.5.7.3.1).

Автоматическая регистрация сертификата через AD CS

В доменной среде с развёрнутым Active Directory Certificate Services настройте автоматическую выдачу сертификатов контроллерам домена через шаблон Kerberos Authentication. Откройте оснастку Certification Authority, создайте дубликат шаблона Kerberos Authentication, на вкладке Security добавьте группу Domain Controllers с правами Read, Enroll и Autoenroll. Настройте групповую политику для OU Domain Controllers: Computer Configuration → Policies → Windows Settings → Security Settings → Public Key Policies → Certificate Services Client - Auto-Enrollment. Включите обновление сертификатов и создание новых.

После обновления политики контроллеры домена получат сертификаты автоматически. Проверьте результат через PowerShell на контроллере:

Test-LdapConnection -Port 636

Ручная установка сертификата для LDAPS

Если AD CS не развёрнут, установите сертификат вручную. Получите PFX-файл, содержащий сертификат и закрытый ключ. Откройте mmc.exe, добавьте оснастку Certificates для Computer account. Импортируйте PFX в хранилище Personal. Убедитесь, что сертификат появился в списке и содержит закрытый ключ (иконка с ключом).

Для проверки используйте ldp.exe: подключитесь к порту 636 с флагом SSL. Или выполните PowerShell-команду:

Get-ChildItem Cert:\LocalMachine\My | Where-Object { $_.EnhancedKeyUsageList -match "Server Authentication" }

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

Настройка клиентов для принудительного использования LDAPS

Главный принцип безопасности клиента: соединение должно разрываться, а не переключаться на открытый текст. Это достигается настройкой параметров проверки сертификата в значение demand и явным указанием схемы ldaps:// в URI.

Настройка sssd для LDAPS

SSSD - основной клиент LDAP в современных Linux-дистрибутивах. Конфигурация для принудительного LDAPS в файле /etc/sssd/sssd.conf:

[domain/example.com]
auth_provider = ldap
ldap_uri = ldaps://ldap.example.com:636
ldap_search_base = dc=example,dc=com
ldap_id_use_start_tls = false
ldap_tls_reqcert = demand
ldap_tls_cacert = /etc/ssl/certs/ca.crt
cache_credentials = true
enumerate = false

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

Ключевые параметры: ldap_id_use_start_tls = false запрещает попытки StartTLS, ldap_tls_reqcert = demand требует валидный сертификат сервера, подписанный доверенным CA. Файл ldap_tls_cacert должен указывать на корневой сертификат вашего CA.

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

systemctl restart sssd
getent passwd username

Если getent возвращает данные пользователя из LDAP - соединение работает. Для детальной диагностики временно повысьте уровень логирования SSSD: debug_level = 9 в секции [domain] и смотрите /var/log/sssd/sssd_example.com.log.

Настройка ldap.conf для OpenLDAP-клиентов

Для систем, использующих libldap напрямую (некоторые приложения, утилиты командной строки), конфигурация задаётся в /etc/openldap/ldap.conf или /etc/ldap/ldap.conf:

URI ldaps://ldap.example.com:636
BASE dc=example,dc=com
TLS_CACERT /etc/ssl/certs/ca.crt
TLS_REQCERT demand

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

ldapsearch -x -H ldaps://ldap.example.com:636 -b "dc=example,dc=com" -D "uid=user,ou=people,dc=example,dc=com" -W

Если сертификат сервера не проходит проверку, команда завершится ошибкой. Это правильное поведение - клиент отказывается от незащищённого соединения.

Решение типичных проблем при переходе на LDAPS

Большинство ошибок при миграции на LDAPS связаны с сертификатами: несовпадение имени хоста, недоверенный CA, истёкший срок действия или отсутствие закрытого ключа. Разберём диагностику и решения.

Ошибка 'certificate verify failed'

Эта ошибка означает, что клиент не может проверить цепочку сертификатов сервера. Причины три: корневой сертификат CA не добавлен в доверенные на клиенте, сертификат сервера подписан неизвестным CA, или CN сертификата не совпадает с именем хоста в URI.

Диагностика выполняется командой openssl s_client:

openssl s_client -connect ldap.example.com:636 -showcerts

Вывод покажет всю цепочку сертификатов и ошибку верификации на последней строке. Если ошибка в недоверенном CA, добавьте корневой сертификат в систему:

# Debian/Ubuntu
cp ca.crt /usr/local/share/ca-certificates/
update-ca-certificates

# RHEL/CentOS/Fedora
cp ca.crt /etc/pki/ca-trust/source/anchors/
update-ca-trust

Если проблема в несовпадении CN, перевыпустите сертификат с правильным именем хоста. Использование TLS_REQCERT allow или ldap_tls_reqcert = allow в production недопустимо - это отключает проверку и сводит безопасность LDAPS к нулю.

Проблемы с производительностью LDAPS

Накладные расходы TLS на современных процессорах с аппаратным ускорением AES-NI составляют менее 5% от времени обработки LDAP-запроса. Основная задержка приходится на установление соединения - TLS handshake требует нескольких round-trip. SSSD минимизирует этот эффект через пул соединений: параметр ldap_connection_expire_timeout управляет временем жизни соединения, по умолчанию 900 секунд. Увеличьте его до 3600, если наблюдаете частые переподключения:

ldap_connection_expire_timeout = 3600

Включать кэширование запросов обязательно. SSSD кэширует учётные данные и групповые членства, что снижает нагрузку на LDAP-сервер на порядок. Параметр cache_credentials = true в sssd.conf активирует кэширование и позволяет аутентификацию даже при временной недоступности сервера.

Чек-лист аудита безопасности LDAP-инфраструктуры на 2026 год

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

1. Закрыт порт 389 для внешних подключений. Выполните nmap -p 389 ldap.example.com с внешнего хоста. Порт должен быть отфильтрован или закрыт. Внутренние клиенты должны использовать исключительно порт 636.
2. Сертификаты используют RSA-ключи не менее 2048 бит. Проверьте командой openssl x509 -in ldap-server.crt -text -noout | grep "Public-Key". Для 2026 года минимальная рекомендованная длина - 3072 бит.
3. Клиенты настроены с TLS_REQCERT demand. Проверьте конфигурации sssd.conf, ldap.conf и параметры подключения в приложениях. Нигде не должно быть allow или never.
4. Отключены устаревшие протоколы TLS 1.0 и 1.1. В конфигурации slapd или через реестр Windows для Active Directory. Для OpenLDAP добавьте в slapd.conf: TLSCipherSuite HIGH:!SSLv2:!SSLv3:!TLSv1:!TLSv1.1.
5. Настроено логирование попыток подключения. В OpenLDAP включите olcLogLevel: stats. В Active Directory аудит событий входа включён по умолчанию, проверьте, что логи собираются в централизованную SIEM-систему.
6. Сертификаты обновляются до истечения срока. Настройте мониторинг срока действия сертификатов. Скрипт проверки: openssl s_client -connect ldap.example.com:636 2>/dev/null | openssl x509 -noout -enddate. Добавьте алерт за 30 дней до истечения.
7. Проверка на LDAP injection. Все приложения, формирующие LDAP-фильтры из пользовательского ввода, должны экранировать специальные символы: * ( ) \ NUL. Проведите пентест или ручную проверку форм аутентификации.
8. Резервный LDAP-сервер также использует LDAPS. Репликация между серверами каталога должна быть зашифрована. Проверьте URI репликации - они должны использовать схему ldaps://.

Результаты аудита зафиксируйте в документе с датой и списком исправлений. Повторяйте проверку каждые полгода. Для углублённой диагностики ошибок LDAP-подключений используйте шпаргалку по диагностике LDAP: готовые команды ldapwhoami, tcpdump и сброс кэша SSSD помогут восстановить аутентификацию за 15 минут.

Если ваша инфраструктура включает TrueNAS, изучите руководство по настройке защищённого подключения TrueNAS к Active Directory через SSL/TLS. Для комплексной защиты Linux-серверов воспользуйтесь материалом по практическому hardening и аудиту Linux-сервера в 2026 с готовыми конфигами для firewalld и nftables.