[turba] Re: LDAP scope

[Craig White]

On Mon, 2005-02-21 at 10:04 +0100, Michael Eichenberger wrote:
> Hi Craig
> 
> >----
> >I would rather move my user address books to an entirely different
> >contain than do that as sub searching even with additional restrictions
> >on the filters is if nothing else a waste of time/resources and not
> >necessary.
> >
> >a quick search of horde/turba/lib/Driver/ldap.php doesn't reveal
> >anything like a scope option which confuses me - as scopes are one of
> >the basic elements of ldapsearch functions.
> >
> >I guess I'm missing something basic here.
> >
> >Craig
> >  
> >
> That's exactly what I've done. But instead of making very restricitive 
> searches, I created ACL's (OpenLDAP 2.2.x). Below I'll explain the setup 
> of the directory and then the configuration of turba.
> 
> The private SubTree (read, write):
> "ou=admin at oaktree.ch,ou=oaktree.ch,ou=default,ou=private,ou=contacts,ou=service,o=stepping-stone,c=ch"
> 
> Where ou=admin at oaktree.ch ist the user name and contains the password of 
> the user. The user always authenticats himself against this SubTree, 
> even if he wants to read the public (shared) address book.
> 
> The public SubTree (read only for all uses except admin at domain.tld):
> "ou=admin at oaktree.ch,ou=default,ou=shared,ou=contacts,ou=service,o=stepping-stone,c=ch"
> 
> See below for the two ACL's in slapd.conf
>  
> # It is possible to select parts of the matched string and keep the 
> matched parts for later
> # substitution. We do this by enclosing those parts in parentheses. 
> Later we will be able to
> # recall the first matched part as $1, the second matched part as $2, etc.
> # In our case this means:
> # - the first (.+) will be passed to $1 (the username, like 
> admin at oaktree.ch)
> # - the second (.+) well be passed to $2 (the domain, like oaktree.ch)
> # From the above example, this gives us:
> # 
> "ou=admin at oaktree.ch,ou=oaktree.ch,ou=default,ou=private,ou=contacts,ou=service,o=stepping-stone,c=ch"
> # Private SubTree:
> access to 
> dn.regex="ou=(.+),ou=(.+),ou=default,ou=private,ou=contacts,ou=service,o=stepping-stone,c=ch"
>   by 
> dn.regex="ou=$1,ou=$2,ou=default,ou=private,ou=contacts,ou=service,o=stepping-stone,c=ch" 
> write
>   by anonymous auth
>   by * none
> 
> # Public SubTree:
> access to 
> dn.regex="ou=(.+),ou=default,ou=shared,ou=contacts,ou=service,o=stepping-stone,c=ch"
>   by 
> dn.regex="ou=admin@$1,ou=$1,ou=default,ou=private,ou=contacts,ou=service,o=stepping-stone,c=ch" 
> write
>   by 
> dn.regex="ou=.+@$1,ou=$1,ou=default,ou=private,ou=contacts,ou=service,o=stepping-stone,c=ch" 
> read
>   by anonymous auth
>   by * none
> 
> 
> Then the Turba configuration is fairly simple (sources.php):
> // First we need to get the uid.
> $uid = Auth::getAuth();
> $basednprivate = 
> 'ou=stepping-stone.ch,ou=default,ou=private,ou=contacts,ou=service,o=stepping-stone,c=ch';
> $cfgSources['private_ldap'] = array(
>     'title' => _("Private Addressbook"),
>     'type' => 'ldap',
>     'params' => array(
>         'server' => 'ldapm.stepping-stone.ch',
>         'root' => 'ou=' . $uid . ',' . $basednprivate,
>         'bind_dn' => 'ou=' . $uid . ',' . $basednprivate,
>         'bind_password' => Auth::getCredential('password'),
>         'dn' => array('cn', 'uid'),
>         'objectclass' => array('top',
>                                'person',
>                                'inetOrgPerson',
>                                'organizationalPerson',
>                                'mozillaOrgPerson'),
>         'charset' => 'utf-8',
>         'version' => 3
>     ),
> ...
> 
> 
> // First we need to get the uid.
> $uid = Auth::getAuth();
> $basednshared = 
> 'ou=stepping-stone.ch,ou=default,ou=shared,ou=contacts,ou=service,o=stepping-stone,c=ch';
> $cfgSources['shared_ldap'] = array(
>     'title' => _("Shared Addressbook"),
>     'type' => 'ldap',
>     'params' => array(
>         'server' => 'ldapm.stepping-stone.ch',
>         'root' => $basednshared,
>         'bind_dn' => 'ou=' . $uid . ',' . $basednprivate,
>         'bind_password' => Auth::getCredential('password'),
>         'dn' => array('cn', 'uid'),
>         'objectclass' => array('top',
>                                'person',
>                                'inetOrgPerson',
>                                'organizationalPerson',
>                                'mozillaOrgPerson'),
>         'charset' => 'utf-8',
>         'version' => 3
> 
>     ),
> ...
> 
> Hope that helps.
----
I hope you don't mind, I've moved this back on list

Actually that doesn't help

I already have 3 turba sources for the same LDAP server.

1 - Shared/common LDAP address book. Depending upon uid of user,
controlled by openldap ACL, most users are read only and only certain
users have read/write privileges. That works fine

2 - System Users LDAP address book - which is all of the users in LDAP
system. This would have their posix attributes, samba attributes, etc.
and restriction to things like userPassword is controlled by openldap
ACL's but this builds a dynamic list of users as they are added/removed
to and from system so it doesn't get maintained except by Administrator
who adds/edits/deletes users. Within each system user is where the
calFBURL attribute is stored.

3 - Personal LDAP address book. This is in an ou inside each of the
system users as listed in #2 above.

The problem is that due to an automatic 'sub' scope for each search -
i.e. when listing db, all of the entries not only in System Users but
also each individual users Address Book are listed. This behavior
wouldn't occur if search were of a scope of 'onelevel' instead of sub.

While I can filter (and I have), the search still is made and thus is
now simply about 'cost' - the amount of resources consumed by an
unnecessary search and as individual users add more entries to their
personal LDAP served Address Books, this cost will grow even though by
filter, they won't show up.

The obvious solutions are:

- move the users personal ldap Address Book containers to another
location ;-(

- implement a 'scope' parameter that is a rather typical parameter for
ldap searching.

This of course, presumes that the 'scope' parameter isn't already
available and I am too stupid to figure out how to make it work.

Looking at the code in horde/kronolith/lib/Driver/ldap.php suggests to
me that Chuck knows the answer.

Craig