Hello Philip,
Monday, September 16, 2002, 3:51:21 PM, you wrote:
PH> On 16 Sep 2002, Adam Cassar wrote:
>> I remember seeing that someone had a patch for exim enabling the use of
>> ldapi:// for ldap connections, however I cannot find the post on the
>> list.
>>
>> Could the responsible party please foward me the patch as I am
>> interested in testing it in a high volume site.
PH> This has already been integrated into the next Exim release. You can
PH> find a snapshot that contains it in
PH> ftp://ftp.csx.cam.ac.uk/pub/software/email/exim/Testing/exim-snapshot.tar.gz
Philip, I guess I found an issue.
It's ldapauth function again. As I can see, Exim could not re-bind
over existing cached LDAP connection. Function ldapauth() is the only
one that behave in this way. According to OpenLDAP specs, actual
connect occurs only after bind() call. I don't know exactly, but I
think so (this could depend on LDAPv2/v3).
So, there seems to be no reason to cache "opened, but not yet
binded" connections since they are not actual connections, just
allocated structures.
If You could ever rebind with the new credentials, without closing the
current connection, You should then rebind back with the previous
credentials, since normally administrators dedicate some privileged
LDAP pseudo-account for MTA (I do so ;-).
Well, summarizing the above, I don't find reasonable to use cached
connections for ldapauth. I've made an experiment: a master+slave LDAP
installation and a 4.10.8 Exim mail system with moderate traffic.
When I took down the master, I observed several error messages like
"Unable to connect to <backup server name>". When I take the master
up, everything was fine. Looks like the first lookup goes to the
master, and subsequent lookups spawned by ldapauth go to the slave.
When no master available, all lookups go to the slave and collide.
Then I removed ldapauth from my configuration completely, and it looks
better now. I advertise both CRAM-MD5 and LOGIN. The latter one uses
ldapauth, but most of my 10k users prefer CRAM-MD5. That's why I could
not catch the bug quickly...
The simpliest thing is to fetch userPassword attribute and compare
it. No problem, I use it since I have only remote TLS and local UNIX
sockets (enabling LDAP TLS in Exim is a separate question. It's a hack
currently).
Another approach could be the use of ldap_compare() API. That's
uncommon to many known DBs, but LDAP-native and requires less
permissions than reading. But the BUGS section of man says that "there
is no way to compare binary values, but there should be". Interesting,
since userPassword is binary.
Well, it could be implemented like this (Exim notation):
ldapcomp{<dn-style lookup>}{<attribute>}{<value>}
-- perform ldap_compare() call against the given DN, comparing
attribute <attribute> with the value <value>.
-- lookup must have the same style as with ldapdn function.
-- function ldap_compare could return LDAP_COMPARE_TRUE and
LDAP_COMPARE_FALSE (among error codes). Error codes should lead
to cycling through the servers or DEFER, as usual.
Example:
${if ldapcomp{USER="cn=Manager,o=ORG,c=UK" PASS="secret" \
ldaps:///cn=Manager,o=org,c=UK}{userPassword}{secret} {yes}{no}}
Please wish-list it, if You find reasonable.
Under some circumstances it's better than ldapauth:
-- LDAP-native
-- requires less permissions than read, but more than auth
-- use of cached connections
-- no need for re-binding.
Other things look good in 4.10.8. If i find something, I'll post it.
Thanks.
--
Best regards,
Peter mailto:spam4octan@highway.ru
