russell-openldap@stuart.id.au wrote:

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.

By the way, CRAM-MD5 has a few known weaknesses. Should use DIGEST-MD5 instead. http://www.ietf.org/rfc/rfc2831.txt (For what that's worth. Given that methods exist to create MD5 collisions, it's not clear how much longer DIGEST-MD5 will be useful.)

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."

Perhaps we should add a security option to separately specify the SSF for anonymous sessions.