☰

ldaps SRV 解析不起作用

tag-icon • tag-icon ldap openldap ldapsearch
ldaps SRV 解析不起作用

我有一个 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命令 - 它正在返回三端口上有 _ldap SRV 的 DC389

$ 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]：请不要一开始就说教如何使用不同的产品。大型企业无论如何都会有集成问题 - 尝试告诉医院系统根据其特定需求购买不同的价值数百万美元的软件

答案1

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

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

总体而言，使用 DNS SRV RR 来定位 TLS 服务器在我看来是一件坏事。

为了防止 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 for SMTP 的安全要求）。

相关内容