ldaps Разрешение SRV не работает

У меня есть среда 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.

Вот SRV LDAP для сравнения

$ 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]: Пожалуйста, не начинайте с лекций об использовании разных продуктов. У крупных предприятий есть проблемы с интеграцией, несмотря ни на что - попробуйте приказать больничным системам приобрести различное программное обеспечение на несколько миллионов долларов для их конкретных требований

1
задан 13 February 2020 в 07:21
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 (например, DN в стиле постоянного тока, как определено в RFC 2377 ]). Я не знаю никаких спецификаций для этого.

Можно утверждать, что DNSSEC - это решение для защиты поиска SRV, но тогда клиенту также потребуется локальный доверенный преобразователь, выполняющий проверку DNSSEC, а клиент TLS должен будет проверить, была ли проверка DNSSEC успешной (см. Также требования безопасности для DANE для SMTP).

3
ответ дан 25 February 2020 в 23:30

Теги

Похожие вопросы