On Thu, 2007-10-25 at 05:18 -0700, Howard Chu wrote:
Using ACLs to enforce this requirement is the wrong approach though. You should just use the "security" directive instead. With your approach you're missing the fact that SASL may not have sent any password at all to slapd (e.g., when using DIGEST-MD5 or an OTP mechanism). As such, you're imposing a constraint that makes no sense.
So you are saying:
security sasl=128 simple_bind=128
would achieve that? I guess it would.
However, with the patch applied this would have the same effect, with the addition that if some other authorisation mechanism were introduced (eg pam), it would fail unless it was encrypted or I explicitly allowed it.
acl <password-stuff> by tls_ssf=128 ... read by sasl_ssf=128 ... read by * none
This may look icky to you, but to someone who is just trying to deploy slapd it means there is one less slapd.conf option I have to get my head around.
<rant>
Perhaps ease of configuration doesn't seem so important. But I was at a talk given by Andrew Tridgell about why he wrote tdb instead of using just using openldap. Answer: because it took him 3 days to get slapd configured and working. 3 days is an impressively short time going on my experiences with it. He actually said it wasn't because slapd had bugs, or slapd was too slow, or slapd didn't have a feature. It was just because in the final analysis, he could not see the typical samba user being able to make the thing work.
When something is hard to configure typically the doco is blamed. But that is often wrong and is wrong in the case of openldap. The blame lies with the design of the system. The programmers fail to see the configuration of the system as another interface. They will put hours of work into designing an API, and devote 100's of lines of code to making sure that API is easy to use, that it hides the complexities of its implementation. Yet they ignore configuration, which in effect another API - it is the interface between the users and the program.
Like most projects openldap uses many libraries to do its thing. But makes no attempt to hide that from the user. In order to configure openldap you have to understand ldap, sasl, tls, berkley db, but whats worse you have to understand how they interact with each other within openldap. For example, ssf is a sasl concept. simple_bind is an ldap concept. But the "security" option has "simple_bind=<ssf_factor>", so suddenly you have to know both, even if you have no intention of using one of them. Ick, ick, ick.
If it had of been an API presented to other programmers, I bet the original designer who of thought "how can I hide all this behind a simple, clean, easy to understand interface". But he didn't, and so now openldap deservedly has the reputation as one of the harder pieces of open source software to get up and going. As a consequence it is deployed a lot less than it should be.
</rant>