I have an AD environment and in ldapsearch, I am able to use SRV records in DNS to resolve the LDAP servers in the domain and in a site.
This works great on the usual ldap port on 389, with basic auth and STARTTLS.
However, some horrible clients won't do STARTTLS, or the vendor is unable to provide a method to configure it.[1] So we need to provide an option for LDAPS on 636.
In principle, I belive that creating ldaps SRV records and using the ldaps:/// URI should work. I've created 2 ldaps SRV records in the domain zone (there are 3 ldap hosts), but when I do ldapsearch and specify ldaps:///, all it's discovering are the ldap hosts.
Here's the ldapsearch command - here it's returning three DCs with _ldap SRVs on port 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)
However, the client machine can resolve the two SRVs for _ldaps, with port 636
$ dig -t SRV _ldaps._tcp.evl.example.com +short
0 100 636 EVLADC002vs.evl.example.com.
0 100 636 EVLADC001vs.evl.example.com.
Here's the LDAP SRV for comparision
$ 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.
If I query a specific server on ldaps, everything is fine
$ 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
...
I'd appreciate any advice on whether I'm missing some option or something else obvious re this issue.
[1]: Please don't start with lectures about using different products. Large enterprises have integration issues no matter what - try telling hospital systems to purchase different multimillion dollar software for their specific requirements
Probably not the answer you wanted to get:
RFC 2782 specifies the use of DNS SRV RRs for LDAP. At that time IETF's general recommendation was to enable TLS encrypted data transmission on the same port like clear-text transmission. Thus using DNS SRV RRs for LDAPS (TLS prior to LDAP) was never specified.
In general using DNS SRV RRs for locating TLS servers is IMO a bad thing to do.
To prevent MITM attacks the TLS client must check the TLS server's identity and public key against its configured connection information (see RFC 6125). For most TLS connections the TLS client checks whether the TLS server cert contains the DNS name used for establishing the connection. In this case the TLS server cert, signed by a trusted CA, contains a cryptographically secured binding between the server's DNS name used by the client and the server's public key.
If you first lookup the TLS server's hostname to be used to connect via SRV RRs then you would have to specify which information must be in the TLS server cert to have such a cryptographically secured binding for the DNS name used for SRV lookup (e.g. the dc-style DN as defined in RFC 2377). I don't know of any specification for that.
One could argue that DNSSEC is a solution for securing the SRV lookup but then the client would also need a local trusted resolver doing the DNSSEC validation and the TLS client would have to check whether DNSSEC validation was successful (see also the security requirements for DANE for SMTP).