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

[Joe L. <jl...@op...>]

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


On Wednesday, May 9, 2001, at 10:44  AM, Michael Str=F6der 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=20
would be built:

http://openit.stanford.edu/access/article/_02/article.html (discuss item=20=

on old site)
http://openit.stanford.edu/access/article/_00/article.html (same, more=20=

on OpenLDAP issues)

http://kodama.open-it.org/pipermail/core-dev/2000-October/thread.html =20=

(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=20
difference of opinion of what was "LDAP" the protocol and "LDAP" the=20
server with the OpenLDAP folks. The solution to some issues would be a=20=

better backend for OpenLDAP than ldbm and perhaps increases features=20
that may not be kosher for OpenLDAP now but could be directly used for=20=

our ActiveDirectory purposes through a straight API -- development use=20=

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=20=

>> 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=20
mask LDAP link up simple LDAP ACLs and access (groups, and such) and=20
form different access rules in Zope of possibly finer grain via=20
abstraction... It would be zope specific, but would allow use to make a=20=

secure conduit from Zope to OpenLDAP and provide the most access via the=20=

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=20=

Howard has already be working on ldapprofile support (sun draft) and a=20=

few other things that would allow one to create the slapd.conf file.=20
Thus, we'd get into the business of generating slapd.conf file ACLs,=20
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=20
>> 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=20
manage LDAP (data, configs, etc,), Samba-TNG, cyrus, etc.. We'd be=20
mucking with the auth and stuff, and the app would likely even need to=20=

"de-auth, test, and re-auth" to the LDAP after executing a change. Most=20=

of this is outside the scope of the ldap-python specific module, but=20
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=20=

v2 or v3, and the v3 are not necessarily SSL-enabled. I don't but the=20
stunnel approach. It needs to use the protocol support path and not a=20
wrapper. I can't easily get access to the firmware of a cisco=20
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=20=

to one config file and accept only the first LDAP port value listed=20
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=20
>> 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=3Dopenssl-users&m=3D97733852307779&w=3D2=

>
> Ciao, Michael.
>
> _______________________________________________
> Python-LDAP-dev mailing list
> Pyt...@li...
> http://lists.sourceforge.net/lists/listinfo/python-ldap-dev
>