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

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

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

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

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

Что разберём в руководстве:

• сравнение LDAP, StartTLS и LDAPS - почему StartTLS уязвим к downgrade-атакам;
• настройка порта 636 на OpenLDAP 2.6: сертификат, slapd, правила файрвола и проверка;
• включение LDAPS в Active Directory - через AD CS или ручной импорт PFX;
• клиенты sssd и ldap.conf, разбор типичных ошибок и чек-лист аудита из 8 пунктов.

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

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

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

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

Ключевой вывод: LDAPS vs StartTLS. LDAPS поднимает TLS до первого LDAP-сообщения, поэтому downgrade-атака структурно невозможна - соединение либо зашифровано, либо не устанавливается. StartTLS стартует с открытого текста на порту 389 и безопасен только при жёсткой настройке клиента (ldap_id_use_start_tls = false и ldap_tls_reqcert = demand), которая запрещает откат. Для новых развёртываний выбирайте LDAPS на порту 636.

Если мигрируете существующую инфраструктуру и не можете сразу переключить всех клиентов на порт 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. Разбор offline-аутентификации и работа с логами через sssctl подробно описаны в материале по настройке sssd и LDAP на Linux: offline cache и диагностика через sssctl.

Настройка 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. Проверьте длину ключа сертификата. Команда: openssl x509 -in ldap-server.crt -text -noout | grep "Public-Key". Ожидаемый результат - RSA-ключ не менее 2048 бит; для 2026 года минимальная рекомендованная длина - 3072 бита.
3. Убедитесь, что клиенты требуют проверку сертификата. Проверьте sssd.conf, ldap.conf и параметры подключения в приложениях: должно быть TLS_REQCERT demand и ldap_tls_reqcert = demand. Значений allow или never не должно остаться нигде.
4. Отключите устаревшие протоколы TLS 1.0 и 1.1. Для OpenLDAP добавьте в slapd.conf: TLSCipherSuite HIGH:!SSLv2:!SSLv3:!TLSv1:!TLSv1.1, для Active Directory - через реестр Windows. Ожидаемый результат - openssl s_client -connect ldap.example.com:636 согласует только TLS 1.2 или 1.3.
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-сервер. URI репликации между серверами каталога должны использовать схему ldaps://. Ожидаемый результат - реплика отвечает на порту 636 и отказывает в соединении без TLS.

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

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