ANNC and query: ldapmodule-1.10a3-patched RPMs available
jlittle at open-it.org
Wed May 9 18:52:13 CEST 2001
regarding LDAP thread safety, etc.. Luke Howard and other people
associated with Open-IT have had ideas about this, and thus the project
"kodama" was born to fix issues with OpenLDAP, including referrals.
Kodama has stagnated since the various qualified people are too busy and
I'm not up to par to handle that bit.
Some things can/will need to be done in python instead of the c-level
api. As to vendor specific ACL's, etc., that is a decision that will be
hard to make. One proposal would be ideal for Zope, bad for Python:
Using zope-based ACL primitives (dare I call it that) to handle ACLs and
then simple use SSL-certs (client and server) to authenticate. Kurt and
others keep on saying that OpenLDAP should not be the authentication
server, and we should rely upon 3rd party auth (Krb5, etc). The end
result is have OpenLDAP use some external auth and some external
ACL-mapping to layer upon basic ACL mapping on OpenLDAP. I don't like
the sound of this approach as an engineered solution. Instead, work is
still progressing on OpenLDAP's ACL, and again it may be a backend issue
(thats were ACLs/transactions are implemented in OpenLDAP). A true
solution could be in kodama, in that kodama-specific API calls could be
used by a python-ldap to systems that can use kodama (more and more
development here). Alternatively, native ACL support would be used on
others. All of this decided from some config key in the LDAP server
itself. Yes, its one big hairy #ifdef. I'm babbling here simply on some
of that ideas thrown out about this. Suffice it to say that it won't be
easily solved, but that creating mature python-objects that contain the
solution will sufficiently hide these details from a higher level app
environment like Zope. And at the end of the day, that is all that
As to StartTLS vs ldaps: in pam_ldap and nss_ldap, there is an issue
with configuration and compiled versions. Basically, you have
configuration files that point to an LDAP server with port, hostname,
etc. Pointing to port 636 for all traffic fails for LDAP v2
configurations. You will generally find that for large deployed
environments, you must support StartTLS and a configuration of port 389
since multiple apps will key off the same "ldap seed" info and only a
percentage will be SSL-aware. Also, its always ugly when you have
distros/OSes (like Solaris!) that support LDAP v3 but have the SSL
libraries as optional installs that are configured at run-time by config
In the end, StartTLS and port 389 is the way to go...
On Wednesday, May 9, 2001, at 09:25 AM, Michael Ströder wrote:
> Joe Little wrote:
>> I'm not complaining..
> Joe, since you are really contributing code be assured that I did
> not point to you.
>> we need specifically to support v3 schema,
> Could be done in higher-level Python modules. (Not trivial though.)
> Not sure if you won't have to fiddle with BER-encoded data
> (implementing syntax matching).
>> OpenLDAP v2 ACLs,
> Currently this whole ACL thing is vendor-specific => you would have
> to write a specific module for each LDAP server. Finding a good
> abstraction level would be required. See also "Access Control Model
> for LDAP" on http://www.ietf.org/html.charters/ldapext-charter.html
> for an attempt to define a standard. There's no need for a modified
> C extension module. You could also implement this in Python.
> Or LDAP over SSL (ldaps://..). IMHO STARTTLS is not widely
> implemented up to now.
> Let me add two things.
> Thread-safety/reentrant: Would require to go with the Mozilla SDK or
> use ldap_r of OpenLDAP 2.0.x (experimental, see my other posting
> with Kurt's not about it).
> Proper handling of referrals / search continuations: Konstantin's
> patch already provides this but there are sometimes strange LDAP
> referral URLs returned. Might be a bug of the OpenLDAP 2.0.x libs.
> Ciao, Michael.
More information about the python-ldap