Problems creating a Samba4 LDAP Backend

[simo]

On Wed, 2008-03-19 at 17:33 -0700, Howard Chu wrote:
> Andrew Bartlett wrote:
> > On Wed, 2008-03-19 at 17:09 -0700, Howard Chu wrote:
> >> It strikes me that the best approach is to just dynamically generate the
> >> memberOf values instead of storing them statically. But that also depends on
> >> your usage patterns.
> >
> > Well, searches on member and memberOf are common, so it seems we would
> > quickly find ourselves downloading the whole backend DB and filtering
> > locally...
> 
> Searching on memberOf doesn't make a lot of sense to me, when you could simply 
> read the group object directly. When is this actually a useful thing to do? An 
> alternative would be to make the memberOf overlay intercept these filters and 
> rewrite them in terms of member.

Premise: here I am thinking beyond what AD is doing as I use the
memberOf concept in another project.

>From my usage memberOf makes it very simple to find all the groups a
member is part of even if that membership derives from nested grouping.

It's very clear that most of the time you have an identity and you want
to know what this Identity is part of, not the other way.

So you really want to do a single search on one entry, rather than a
huge search on the whole directory to find out (including local
calculation for nesting) what groups include that identity as member, by
parsing all groups one by one.

It is as simple as that.



Now for what concern the Samba4 problem, I think we should be more
creative and first understand in which cases we might hit a problem with
plugins like memberOf. I am sure some of these cases are just normal
possible inconsistencies that can happen even in a normal AD server if
you do many modifications at the same time. For these cases we just have
to try not to make them more probable or problematic than what they are
now.
In other cases we might think of doing aggressive caching/prediction in
our internal transactions. It might require some more work, but it could
be a viable option, and also drive some more performance as dealing with
an external LDAP is necessarily slower.
Finally, if caching/prediction is not possible, we can think of writing
overlays/slapi plugins directly for the LDAP server of choice be it
OpenLDAP or Fedora Directory Server or anything else. This third option
would require some more work and will be server specific, and perhaps
involve some creative thinking wrt licensing, but it is certainly a
viable option we should not discard. After all, these LDAP servers have
a plugin system with defined APIs exactly to solve those problems that
cannot be solved merely by external interaction.

Simo.

-- 
Simo Sorce
Samba Team GPL Compliance Officer <simo at samba.org>
Senior Software Engineer at Red Hat Inc. <ssorce at redhat.com>