[turba] Re: turba ldap driver

[Edwin L. Culp]

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