У меня есть среда AD, и в ldapsearch я могу использовать записи SRV в DNS для разрешения серверов LDAP в домене и на сайте.
Это отлично работает с обычным портом ldap на 389, с базовой аутентификацией и STARTTLS.
Однако некоторые ужасные клиенты не будут выполнять STARTTLS, или поставщик не может предоставить метод для его настройки. [1] Поэтому нам нужно предоставить возможность LDAPS на 636.
В принципе, я считаю, что создание SRV-записей ldaps и использование ldaps:/// URI должен работать. Я создал 2 записи SRV ldaps в зоне домена (есть 3 хоста ldap), но когда я это сделаю ldapsearch и указать ldaps:///, все, что он обнаруживает, - это хосты ldap.
Вот ldapsearch команда - вот она возвращается три Контроллеры домена с _ldap SRV на порте 389
$ ldapsearch -v -H "ldaps:///dc%3Devl%2Cdc%3Dexample%2Cdc%3Dcom" -D "user" -W -b "DC=evl,DC=example,DC=com" -b "" -s base "(objectclass=*)" -d 1
ldap_url_parse_ext(ldaps:///dc%3Devl%2Cdc%3Dexample%2Cdc%3Dcom)
ldap_initialize( ldaps://EVLADC002vs.evl.example.com:389 ldaps://EVLADC001vs.evl.example.com:389 ldaps://EVLADC006vs.evl.example.com:389 )
ldap_create
ldap_url_parse_ext(ldaps://EVLADC006vs.evl.example.com:389)
ldap_url_parse_ext(ldaps://EVLADC001vs.evl.example.com:389)
ldap_url_parse_ext(ldaps://EVLADC002vs.evl.example.com:389)
Однако клиентский компьютер может разрешить два SRV для _ldaps, с портом 636
$ dig -t SRV _ldaps._tcp.evl.example.com +short
0 100 636 EVLADC002vs.evl.example.com.
0 100 636 EVLADC001vs.evl.example.com.
Вот LDAP SRV для сравнения
$ dig -t SRV _ldap._tcp.evl.example.com +short
0 100 389 EVLADC001vs.evl.example.com.
0 100 389 EVLADC006vs.evl.example.com.
0 100 389 EVLADC002vs.evl.example.com.
Если я запрашиваю конкретный сервер по ldaps, все в порядке
$ ldapsearch -H ldaps://evladc001vs.evl.example.com -D "user" -W -b "" -s base "(objectclass=*)"
# extended LDIF
#
# LDAPv3
# base <> with scope baseObject
# filter: (objectclass=*)
# requesting: ALL
#
#
dn:
currentTime: 20200213045340.0Z
subschemaSubentry: CN=Aggregate,CN=Schema,CN=Configuration,DC=evl,DC=example,DC=com
dsServiceName: CN=NTDS Settings,CN=EVLADC001VS,CN=Servers,CN=Server,CN=Sites,CN=Configuration,DC=evl,DC=example,DC=com
...
Буду признателен за любой совет о том, не хватает ли мне какой-либо опции или чего-то еще очевидного по этой проблеме.
[1]: Пожалуйста, не начинайте с лекций об использовании разных продуктов. У крупных предприятий есть проблемы с интеграцией, несмотря ни на что - попробуйте посоветовать больничным системам приобрести различное многомиллионное программное обеспечение для своих конкретных требований
Наверное, не тот ответ, который вы хотели получить:
RFC 2782 определяет использование DNS SRV RR для LDAP. В то время общая рекомендация IETF заключалась в том, чтобы разрешить передачу данных с шифрованием TLS через один и тот же порт, как передачу открытого текста. Таким образом, использование DNS SRV RR для LDAPS (TLS до LDAP) никогда не указывалось.
В общем, использование DNS SRV RR для обнаружения серверов TLS - это плохое решение IMO.
Чтобы предотвратить атаки MITM, клиент TLS должен проверить идентичность и открытый ключ сервера TLS по его настроенной информации о подключении (см. RFC 6125). Для большинства соединений TLS клиент TLS проверяет, содержит ли сертификат сервера TLS имя DNS, используемое для установления соединения. В этом случае сертификат сервера TLS, подписанный доверенным центром сертификации, содержит криптографически защищенную привязку между DNS-именем сервера, используемым клиентом, и открытым ключом сервера.
Если вы сначала ищите имя хоста TLS-сервера, которое будет использоваться для подключения через SRV RR, тогда вам нужно будет указать, какая информация должна быть в сертификате сервера TLS, чтобы иметь такую криптографически защищенную привязку для DNS-имени, используемого для поиска SRV (например, dc -стилем DN, как определено в RFC 2377). Я не знаю никаких спецификаций для этого.
Можно утверждать, что DNSSEC - это решение для защиты поиска SRV, но тогда клиенту также потребуется локальный доверенный преобразователь, выполняющий проверку DNSSEC, а клиент TLS должен будет проверить, была ли проверка DNSSEC успешной (см. Также требования безопасности для DANE для SMTP).