[Date Prev][Date Next]
Re: ldaprc with ldaps:// and ldap:// fallback
Dan White wrote:
> On 24/06/10 22:13 +0200, Emmanuel Dreyfus wrote:
>> Dan White <firstname.lastname@example.org> wrote:
>>> You could do SASL EXTERNAL over both, with ldapi:/// using Unix
>> That sounds nice, but will it works with the "TLS_REQCERT demand" I have
>> for ldaps:// ?
> TLS_REQCERT: try
> In this case, EXTERNAL should only be offered after successful TLS
> negotiation, or over a unix domain socket.
Why should this have effect for ldapi:/// at all?
> If TLS negotiation fails, then a SASL bind won't work without selecting
> another mechanism.
There is no TLS negotiation on a Unix domain socket at all.
IMO many statements in this thread cause confusion: EXTERNAL acts differently
depending on the connection type used. AFAIK you can query whether it's
available for a certain connection by reading attribute
supportedSASLMechanisms in the rootDSE.
Emmanuel should simply set up a test environment where all the relevant
clients always use SASL/EXTERNAL and have a SASL authc-to-authz-DN mapping in
place for ldaps:// with client certs and ldapi:/// with peer credentials. The
TLS options only affect ldaps:// or ldap:// with StartTLS ext.op.