Problems creating a Samba4 LDAP Backend

Howard Chu hyc at
Fri Mar 21 12:40:33 GMT 2008

simo wrote:
> On Wed, 2008-03-19 at 17:33 -0700, Howard Chu wrote:
>> 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.

Ah, an interesting point, but probably a separate discussion. Note that the 
OpenLDAP memberOf overlay doesn't handle nested groups.

> 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.

No, not clear at all. A very common application of "groups" is for things like 
email lists. In that case, an MTA knows a specific group (the name of the 
email list), and needs to know all of the members.

Other times (e.g. access control) you know an identity (current user) and want 
to know if the identity belongs to a particular group (for an authorization 
check). In that case, it is an equal amount of work to look in the user's 
entry for a memberOf value as to look in the group entry for the particular 
member value. In practice, because groups may be referenced frequently for 
multiple users, the group entries will be hot in the server cache and so the 
member lookup is actually cheaper.

The frequency with which the question "what groups do I belong to" is asked is 
extremely low in most applications. The frequency with which the question "is 
XX a member of this group" is asked is very high in most applications. E.g., 
the libc initgroups() call needs to know what groups you belong to; that call 
typically occurs only once at the beginning of a login session. After that the 
result is essentially cached by the kernel. The result is cached in the kernel 
because the subsequent "is XX a member of group YY" questions happen so 
frequently as a process accesses system resources.

> 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.

No, not simple at all.

Yes, ideally you would like to be able to look in a single place and get the 
answer to "what privileges does user X have" but that doesn't actually mean 
what you're implying. In particular, the "single place" you're looking isn't 
necessarily that user's own entry. In most cases, that's the worst place to 
use because users generally have full write privileges to their own data, and 
the data comprising their set of privileges really belongs to the sysadmin, 
not to the individual user.

Ideally, you write to the privilege set and read from the privilege set in the 
same way, in the same place. As an administrator, this simple consistency 
makes life easier. The memberOf concept is fundamentally broken if you 
actually rely on it for privilege determination because it is one step removed 
from how privileges are actually assigned by the sysadmin. (I.e., the sysadmin 
doesn't assign membership privileges to a user by writing to the memberOf 
attribute, therefore memberOf is not authoritative.)

> 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.

Agreed. And frankly, there's already an existence proof that this approach is 
   -- Howard Chu
   Chief Architect, Symas Corp.
   Director, Highland Sun
   Chief Architect, OpenLDAP

More information about the samba-technical mailing list