Dan White wrote:
On 24/06/10 22:13 +0200, Emmanuel Dreyfus wrote:
Dan White dwhite@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.