[Date Prev][Date Next]
Re: (ITS#5195) ssf not available during sasl bind
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
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."