[turba] Re: turba ldap driver
Ben Sommer
Ben.Sommer at enc.edu
Mon Apr 18 12:59:38 PDT 2005
This is a multi-part message in MIME format.
--------------060202080207060801030301
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Edwin L. Culp wrote:
>Quoting Ben Sommer <Ben.Sommer at enc.edu>:
>
>>Hi All. My question is in reference to ldap configuration in turba.
>>Chuck asked me to post my question for ldap-experienced folks to comment on:
>>
>>
>Ben, thanks for taking time to do this. I don't consider myself
>ldap-experienced but use ldap for most all my authentication needs in
>general. In addition to the fact that ldap just makes sense, another
>of the reasons is that I've never had a major problem utilizing any
>application's preconceived idea of my ldap structure or what it should
>be even though they all seem to be a bit different. With
>horde/imp/gollem I use ldap to authenticate in horde
>auth/courier/proftp. All have a slightly different view of what my
>ldap structure is or might be but are really quite easy to configure
>and use with all the very different ldap structures that I'm testing
>right now.
>
>
>
>>Problem: the schema for my LDAP addressbook does not match the
>>assumptions built into turba. The man previously in my position hacked
>>turba 1.2 to make it work with the schema. I'd like to now address the
>>shortcoming in turba directly.
>>
>>
>If I'm understanding you correctly, neither does mine. IMO, the
>configuration in horde is especially flexible. In fact I am trying a
>new ldap structure to seperate virtual domains a bit more to keep
>admins of the different domains from being able to access the users of
>the other domains while sharing horde and it seems to work, so far
>anyway, without affecting authentication with other apps. I'm a big
>fan of one login and password configuration for multiple apps.
>
>
>>Our addressbook schema uses an object class called 'uniqueEntryObject',
>>describing objects with a "Unique Entry ID" (ueid) as RDN naming
>>attribute. The reason should be obvious - a long list of peer LDAP
>>entries (i.e. entries sharing a common immediate parent) such as an
>>addressbook can't have clashing RDNs, something that would inevitably
>>happen with turba, since the default configuration seems to simply use
>>the 'cn' attribute (or some other user-defined attribute) as the RDN.
>>
>>
>
>Again with all my ldap authentication, I've always found it easy to use
>mail as an unsophisticated, po'boy's equivalent to your ueid, and
>without having to modify any code, but I would have no problem such an
>atribute, if fact with time I might even like it ;) although I would
>appreciate your helping me understand what additional benefit I might
>derive. Especially, if I will a unique generated id in each of my
>address books. In sql I have an easier time understanding this because
>of the structural differences. That is one of the major reasons that I
>use ldap.
>
>
>
>>Also, my confusion about whether turba could be configured to work with
>>this schema was compounded by the param 'dn', which is misnamed. It
>>should be 'rdn', and its value should not be an array - since an RDN is
>>by definition _one_ attribute. All the code in lib/Driver/ldap.php that
>>munges this array (i.e. _makeKey, _save) should be refactored
>>accordingly. I can do this, but I want to sound it out to you all first.
>>
>>
>
>Refactoring and improvemente are always good.
>
>
>
>>Second, the capability to make the RDN attribute non-user defined should
>>be added to the driver and the config/sources.php examples. Reasoning is
>>the same here too - the RDN must be unique, and therefore
>>system-generated - just like an auto-incremented ID in an SQL database.
>>We kinda have the right idea in lib/Driver.php with '__uid', but this
>>should be configurable from within an LDAP turba data source. (The use
>>of the name 'uid' here was another confuser!)
>>
>>
>
>I'm sure that this is a dumb question but I'm sure missing something in
>your RDN reasoning. If our RDN's were not already unique, how are we
>managing to authenticate? As I said before I see no problem with a
>"non-user defined attribute" but again I would appreciate some ideas on
>what I might be able tu use it for. Neither I nor my users forget
>their valid email address that is unique in itself.
>
>Ben, again I would like to thank you for having made this proposal and
>submitted it to the list and even more for offering to refactor
>ldap.php. I apologize for my ignorance with my only justification
>being that the small amount of ldap knowledge that I have been able to
>acquire has been from trial and error. ed
>
Thanks for your response, Ed. I didn't include all the details at first
- I'm kinda thinking as I go. And please - I'm not super experienced
either! :)
Yep - turba is pretty flexible. But I think my schema design represents
perhaps one edge case that isn't handled well by turba, or most
applications for that matter.
We split 'ou=people' from other sub areas, and relate them by a key field:
dc=enc,dc=edu
| |
/ \
/ \
ou=people ou=addressbook
| \
"ueid=8aj28as,etc" ---> "ou=8aj28as,etc"
ueid=20051238791238,etc
ueid=20053242311239,etc
This jury-rigs the directory to kinda act like a tabular database, for
similar reasons, mainly performance: OpenLDAP read-locks a given LDAP
tree when updating. This can cause problems when multiple apps are
trying to read from LDAP (we configure fat-client email programs, as
well as turba, to use the addressbook). Its also why we do subgroupings
within 'ou=people'. This may be overdesign for most people. Indeed, I am
simply inheriting the design, and might not even choose to do it this
way now - but its a valid design, and turba doesn't support it.
Now, I got around my first challenge by sticking some code in
config/sources.php to retrieve the correct DN for $params_['root']. For
instance, my person entry looks like this:
ueid=2u23aaw4,ou=2,ou=people,dc=enc,dc=edu
My addressbook entry container looks like this:
ou=2u23aaw4,ou=personal_addressbook,dc=enc,dc=edu
So I fetched my entry to get the 'ueid=2u23aaw4' to use as the RDN of my
addressbook. But now I want new entries in the addressbook containter to
look like this:
ueid=20051238791238,ou=2u23aaw4,ou=personal_addressbook,dc=enc,dc=edu
ueid=20053242311239,ou=2u23aaw4,ou=personal_addressbook,dc=enc,dc=edu
etc...
So in this case, my RDN - 'ueid' - needs to be auto-generated, and
ldap.php needs to know how to do this. Your 'po-boy' method to use the
'mail' attribute as RDN is actually a fine idea (wish I'd thought of
it). But...you can imagine if someone was importing a huge CSV file with
several entries that (oddly enough) didn't have an email address! Then
we'd be up a creek. This might seem odd, but maybe not if you remember
that some folks (like us here at the college) want to use our
addressbooks in several apps, not just turba, and we want to be able to
include enties with just a name and phone number, no email address.
I've attached the two patches here, and submitted them here:
http://bugs.horde.org/ticket/?id=1814
Let me know what you think!
Best,
--
Ben Sommer
Senior Technology Officer
Eastern Nazarene College
23 East Elm Ave
Quincy, MA 02170
(617) 745-3817
--------------060202080207060801030301
Content-Disposition: inline;
filename="ldap.php.diff"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
An embedded and charset-unspecified text was scrubbed...
Name: ldap.php.diff
Url: http://lists.horde.org/archives/turba/attachments/20050418/b6751433/ldap.php.ksh
--------------060202080207060801030301
Content-Disposition: inline;
filename="sources.php.dist.diff"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
An embedded and charset-unspecified text was scrubbed...
Name: sources.php.dist.diff
Url: http://lists.horde.org/archives/turba/attachments/20050418/b6751433/sources.php.dist.ksh
--------------060202080207060801030301--
More information about the turba
mailing list