ANNC and query: ldapmodule-1.10a3-patched RPMs available

Michael Ströder michael at
Wed May 9 19:44:10 CEST 2001

Joe Little wrote:
> 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.

Can you give us an URL of "kodama"?
Can you describe how they wanted to solve thread safety? (one of my
urgent requirements!)
Why to "fix issues with OpenLDAP" in a separate project and not as
direct contributions to OpenLDAP? (No offense, just curiousity.)

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

I'm not sure about which ACLs and authentication you're talking.
Authorization schemes at your client/gateway side or at the LDAP
server side? I don't understand how Zope is involved at that level.

As I understand you specify ACLs on some LDAP servers by setting
operational attributes (e.g. attribute aci on Netscape server). Most
times this is done by a vendor-specific directory managing software.

Do you plan to write an ACL managing software for OpenLDAP? AFAIK in
OpenLDAP ACLs are solely defined in the configuration file (see Control).
Therefore I don't see how python-ldap could be involved at all.

Anyway, for the upcoming I-D on LDAP ACLs it is interesting that
states in section ABSTRACT: "The current LDAP APIs are sufficient
for the access control operations."

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

Sorry, I can't figure out what exactly you're talking about.

Most of us simply need the following: Authenticate a user by binding
with the user entry's DN and a credential against an arbitrary LDAP
server. How the LDAP server performs authentication (external or
internal or whatever) is not of interest for your application
(except having to provide the necessary credential data). E.g.
strong authentication with client certs is handled via SASL. But
again that's a special bind call.

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


If you really take care of security I doubt that you want to leave
use of SSL/TLS as option. Simply use a SSL wrapper (e.g. stunnel)
running on that port you can
mandate the use of LDAP over SSL even on non-SSL LDAP servers.

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

Run the server on both ports...

> 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
> files, etc.

Well, we're really getting off-topic.

> In the end, StartTLS and port 389 is the way to go...

See also for a discussion about RFC 2817:

Ciao, Michael.

More information about the python-ldap mailing list