Re: (ITS#5195) ssf not available during sasl bind

[russell-openldap@stuart.id.au]

On Mon, 2007-10-29 at 18:07 +0100, Hallvard B Furuseth wrote:
> No, you've forced users who authenticate against userPassword
> to be encrypted.  Not all SASL methods, nor auth with rootpw.

Thats a worry.  Rootpw aside, the intended objective of
the ACL was to ensure passwords were never sent in the
clear.  Either a protocol like CRAM-MD5 was used, or the
entire link is encrypted.  Does it not do that?  (Actually
it doesn't.  It should have been sasl_ssf=71.  But bugs
aside ...)

Secondly, just out of curiosity, are there SASL methods 
that check a shared secret of some kind and don't use 
userPassword?  What are they?

The "security" option may produce better error messages
by it appears to apply to all connections, including
lookups done by SASL to dn="" to discover what mechanisms
are allowed.  It wasn't at all obvious to a newbie like me
that this sentence from "man 1 ldapsearch" only applies
if you don't use the "security" option:

  "-Y mech .... If it's not  specified, the program will 
  choose the best mechanism the server knows."