On Sat, Feb 2, 2019 at 10:34 PM Graham Leggett <minfrin@sharp.fm> wrote:
> On 02 Feb 2019, at 01:57, Thomas Munro <thomas.munro@enterprisedb.com> wrote:
> > On Sat, Feb 2, 2019 at 9:25 AM Graham Leggett <minfrin@sharp.fm> wrote:
> >> Does this support SSL/TLS?
> > I didn't try it myself but I found several claims that it works. I
> > see complaints that it always looks for _ldap._tcp and not _ldaps._tcp
> > as you might expect when using ldascheme=ldaps, but that doesn't seem
> > to be a big problem. As for ldaptls=1, that must work because it
> > doesn't even negotiate that until after the connection is made.
>
> If the LDAP server was bound to port 636, how would the client know to use a direct SSL/TLS connection and not
STARTTLS?
SRV records don't control that, so it looks like the person
configuring pg_hba.conf would simply have to know which of the
following formats to use:
ldapurl=ldap:///dc=example,dc=net
ldapurl=ldap:///dc=example,dc=net ldaptls=1
ldapurl=ldaps:///dc=example,dc=net
Only the port and host are obtained from the SRV record, not those
protocol details. Nothing in RFC 2782 prevents you from setting up
separate "_ldaps._tcp" SRV records (and I can find discussions of that
idea on the net) and then writing custom resolver code that knows to
look for that, but the OpenLDAP code we're using (for compatibility
with the command line tools) is hard coded to use "_ldap._tcp"
always[1]. Active Directory apparently automatically creates only
"_ldap._tcp" SRV records according to its documentation and that's the
user base I was aiming for with this patch, so I think it makes sense
to just use the routines they provide, despite this weakness.
[1] https://github.com/openldap/openldap/blob/b06f5b0493937fc28f2cc86df1d7f464aa4504d8/libraries/libldap/dnssrv.c#L276
--
Thomas Munro
http://www.enterprisedb.com