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 конфигурацията.

Когато се появи несъответствие на сертификат, внедрете правилния сертификат или верига. Изключването на валидацията превръща видимо несъответствие в невидимо и оставя втората връзка на доверие непроверена.

Две връзки, двама собственици, две дати за подновяване. Разделното им документиране е това, което държи влизането честно.