主页 / server / 问题 / 1002895
Accepted
LeeM
Asked: 2020-02-13 21:21:12 +0800 CST

ldaps SRV 解析不起作用

  • 772

我有一个 AD 环境，在 ldapsearch 中，我能够使用 DNS 中的 SRV 记录来解析域和站点中的 LDAP 服务器。

这适用于 389 上的常用 ldap 端口，具有基本身份验证和 STARTTLS。

但是，一些可怕的客户端不会执行 STARTTLS，或者供应商无法提供配置它的方法。[1] 所以我们需要在 636 上为 LDAPS 提供一个选项。

原则上，我相信创建 ldaps SRV 记录和使用ldaps:///URI 应该可以工作。我在域区域中创建了 2 个 ldaps SRV 记录（有 3 个 ldap 主机），但是当我这样做ldapsearch并指定时ldaps:///，它发现的只是 ldap 主机。

这是ldapsearch命令 - 它在端口389上返回三个带有 _ldap SRV 的 DC

$ 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)

但是，客户端机器可以解析_ldaps的两个SRV，端口为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]：请不要从使用不同产品的讲座开始。大企业无论如何都有集成问题 - 尝试告诉医院系统购买不同的价值数百万美元的软件以满足他们的特定需求

ldap openldap ldapsearch

1 个回答

  1. Best Answer

    可能不是您想要得到的答案：

    RFC 2782指定对 LDAP 使用 DNS SRV RR。当时 IETF 的一般建议是启用 TLS 加密数据在同一端口上传输，就像明文传输一样。因此，从未指定将 DNS SRV RR 用于 LDAPS（LDAP 之前的 TLS）。

    一般来说，使用 DNS SRV RR 来定位 TLS 服务器是 IMO 的一件坏事。

    为了防止 MITM 攻击，TLS 客户端必须根据其配置的连接信息检查 TLS 服务器的身份和公钥（请参阅RFC 6125）。对于大多数 TLS 连接，TLS 客户端会检查 TLS 服务器证书是否包含用于建立连接的 DNS 名称。在这种情况下，由可信 CA 签名的 TLS 服务器证书包含客户端使用的服务器 DNS 名称和服务器公钥之间的加密安全绑定。

    如果您首先查找要用于通过 SRV RR 进行连接的 TLS 服务器的主机名，那么您必须指定哪些信息必须在 TLS 服务器证书中才能为用于 SRV 查找的 DNS 名称（例如 dc -style DN 定义在RFC 2377中）。我不知道有任何规范。

    有人可能会争辩说，DNSSEC 是一种保护 SRV 查找的解决方案，但是客户端还需要一个本地受信任的解析器来执行 DNSSEC 验证，并且 TLS 客户端必须检查 DNSSEC 验证是否成功（另请参阅 DANE 的安全要求SMTP）。

    • 3

相关问题