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

[Joe Little]

I'll try to be a bit more concise...


On Wednesday, May 9, 2001, at 10:44  AM, Michael Ströder wrote:

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

Here's a spew of URLs discussing ActiveDirectory on UNIX and how it 
would be built:

http://openit.stanford.edu/access/article/_02/article.html (discuss item 
on old site)
http://openit.stanford.edu/access/article/_00/article.html (same, more 
on OpenLDAP issues)

http://kodama.open-it.org/pipermail/core-dev/2000-October/thread.html  
(this month was busy with lots-o-discussions)

Our big presentation is

http://kodama.open-it.org/roadmap/index.html

this probably has the most concrete aspect of what kodama is.

In the end, we had people in the OpenLDAP project, but there was a 
difference of opinion of what was "LDAP" the protocol and "LDAP" the 
server with the OpenLDAP folks. The solution to some issues would be a 
better backend for OpenLDAP than ldbm and perhaps increases features 
that may not be kosher for OpenLDAP now but could be directly used for 
our ActiveDirectory purposes through a straight API -- development use 
only and all that.


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

It has its own interface for users, access, and such, and so one can 
mask LDAP link up simple LDAP ACLs and access (groups, and such) and 
form different access rules in Zope of possibly finer grain via 
abstraction... It would be zope specific, but would allow use to make a 
secure conduit from Zope to OpenLDAP and provide the most access via the 
web only through Zope.

>
> 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
> http://www.openldap.org/doc/admin/slapdconfig.html#Access Control).
> Therefore I don't see how python-ldap could be involved at all.
>

Part of Open-IT, "shiido" is designed to seed a directory server. Luke 
Howard has already be working on ldapprofile support (sun draft) and a 
few other things that would allow one to create the slapd.conf file. 
Thus, we'd get into the business of generating slapd.conf file ACLs, 
likely out of some schema def.

> Anyway, for the upcoming I-D on LDAP ACLs it is interesting that
> http://www.ietf.org/internet-drafts/draft-ietf-ldapext-acl-model-07.txt
> 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.
>

It is a problem when the application you are making is supposed to 
manage LDAP (data, configs, etc,), Samba-TNG, cyrus, etc.. We'd be 
mucking with the auth and stuff, and the app would likely even need to 
"de-auth, test, and re-auth" to the LDAP after executing a change. Most 
of this is outside the scope of the ldap-python specific module, but 
full support will need to be there to not duplicate code unnecessarily.

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

when LDAP is used with configuration services, many implementations are 
v2 or v3, and the v3 are not necessarily SSL-enabled. I don't but the 
stunnel approach. It needs to use the protocol support path and not a 
wrapper. I can't easily get access to the firmware of a cisco 
DEN-enabled device to add stunnel to its LDAP queries :)

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

Server is not the issue.. its the client config file. Most clients refer 
to one config file and accept only the first LDAP port value listed 
there. We can't rewrite ALL the ldap enabled-apps :)

>> 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:
> http://marc.theaimsgroup.com/?l=openssl-users&m=97733852307779&w=2
>
> Ciao, Michael.
>
>