Сертификат VPN не защищает участок LDAP

Вход через VPN, который проверяет учётные данные по каталогу, включает два отдельных сетевых подключения. Подключение пользователя к шлюзу защищено собственным сертификатом VPN и настройками протокола. Подключение шлюза к каталогу — это другая сессия с собственными настройками TLS, собственным хранилищем доверия и собственными режимами отказа. Ничто в первом не гарантирует ничего во втором.

Именно эта асимметрия стоит за входом, который выглядит зашифрованным и всё же отправляет пароль привязки открытым текстом.

Два подключения, два решения о доверии

Внешняя сессия — это то, что видит пользователь: сертификат, привязанный к имени хоста VPN, проверенный клиентом и несущий обмен аутентификации. Внутренняя сессия принадлежит клиенту каталога внутри шлюза, который открывает собственное подключение и либо согласует TLS, либо нет. Каждая сторона проверяет собеседника, с которым говорит, используя материал из другого файла конфигурации. Неправильно настроенный внутренний участок остаётся невидимым со стороны пользователя, потому что внешний участок работает ровно так, как задумано.

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

StartTLS и LDAPS, выбранные осознанно

StartTLS открывается как обычный LDAP и повышается на месте, обычно на порту 389. LDAPS запускает TLS вместе с подключением, обычно на 636. Оба варианта законны, и адаптер должен соответствовать тому, что предлагает каталог. Требовать StartTLS — не то же самое, что попробовать его и продолжить при неудачном повышении, и именно в этом различии пароль привязки может утечь. Настройте строгий режим и не допускайте незащищённого запасного пути для привязки с паролем.

ldapsearch -H ldap://dc1.corp.example -ZZ -x -D "CN=VPN Bind,OU=Service Accounts,DC=corp,DC=example" -W -b "DC=corp,DC=example" "(sAMAccountName=example-user)" dn

Флаг -ZZ — в этом весь смысл: запрос завершается ошибкой, а не продолжается молча без повышения. Имена и учётные записи в этой строке — примеры. Документация OpenLDAP по TLS описывает настройки доверия, стоящие за этим.

Какое хранилище доверия читает клиент LDAP?

Клиентская библиотека OpenLDAP читает собственную конфигурацию доверия — из системного файла или из настройки конкретного плагина. Директива CA в VPN относится к партнёрам VPN и не доказывает, что библиотека LDAP читает тот же файл. Используйте имя хоста каталога, которое сертификат действительно покрывает, плюс цепочку издателя, которой доверяет библиотека. В Active Directory разверните сертификат службы каталога с правильным применением для аутентификации сервера, а не делайте выводы по отображаемому имени.

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

Учётная запись привязки остаётся отдельной проблемой

Защита транспорта не уменьшает того, что может делать учётная запись привязки. Область поиска в каталоге, групповая авторизация и привилегии служебной учётной записи — отдельные решения, и широкая учётная запись привязки остаётся широкой после включения TLS. Используйте самую узкую служебную учётную запись и базу поиска, которые нужны интеграции, и записывайте конечную точку, режим TLS, владельца доверия и процесс продления вместе с конфигурацией VPN.

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

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