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命令 - 它在埠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 $$: 請不要從使用不同產品的講座開始。大企業無論如何都有集成問題 - 嘗試告訴醫院系統購買不同的價值數百萬美元的軟體以滿足他們的特定需求
可能不是您想要得到的答案：
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）。