Dan White wrote: > On 24/06/10 22:13 +0200, Emmanuel Dreyfus wrote: >> Dan White <dwh...@olp.net> wrote: >> >>> You could do SASL EXTERNAL over both, with ldapi:/// using Unix >>> peercred, >>> i.e.: >>> >>> authz-regexp >>> ".*uidNumber=([^,]+),cn=peercred,cn=external,cn=auth" >>> ldap:///ou=People,dc=example,dc=net??one?(uidNumber=$1) >> >> That sounds nice, but will it works with the "TLS_REQCERT demand" I have >> for ldaps:// ? > > Try: > > 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. Ciao, Michael.