Re: ldaprc with ldaps:// and ldap:// fallback

[Michael Ströder <michael@stroeder.com>]

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.