Problems creating a Samba4 LDAP Backend

Andrew Morgan morgan at
Fri Mar 21 17:51:03 GMT 2008

On Fri, 21 Mar 2008, simo wrote:

> On Fri, 2008-03-21 at 05:40 -0700, Howard Chu wrote:
>> 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.
> Interesting.
> To be honest, if memberOf does not solve the nesting group problem, I
> find it rather useless, and that may explain your comments below.
>>> 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.
> My bad, I should have specified that this is the case I meet/care in my
> work. It is not, in general, the most common case, I agree.
>> 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.
> This is true only if you do member checking by looking at groups. But if
> you don't they won't, so I am not sure this really is a reason unless
> there is another reason groups are frequently checked. But given the
> fact that groups may have huge memberships, actually wasting a lot of
> cache memory to keep around the members could also be a reason not to do
> it that way. Of course this is just cheap talk of me, without numbers
> related to a particular use case (and the use case here is more identity
> management, not much MTAs or such, even if, in the end, the same
> Directory can be used for many applications, so groups can actually be
> really in cache already).

We run a medium sized directory here at Oregon State University which 
contains user objects for all students, staff, and faculty (approximately 
35,000 entries).  It also contains a few static groups (not nested) for 
categorizing users.  We are using Sun Directory Server 5.2.

The documentation for Sun Directory Server 6.2 says:

   The isMemberOf attribute is calculated and added to the user entry at
   the start of the search.  It is then removed again after the search has
   finished.  This functionality provides easy management of groups, and
   fast read access.

To me, this says that the directory does an internal group search to 
generate the isMemberOf attribute on the fly.  I believe this is the way 
Active Directory handles the memberOf attribute as well.

Most directory servers suggest tuning the caches so that the entire 
directory fits in RAM, which isn't too hard these days with the price of 
RAM.  Directory entries are typically only a few kilobytes each.

>From a performance standpoint, it may not matter which method of group 
enumeration you use.  Directory servers are optimized for reads, and a 
simple LDAP query like:


can be just as fast as:


I'm not familiar with the background of this whole discussion.  It sounds 
like the memberOf/isMemberOf implementations are relatively new.  Unless 
you want Samba to require the latest and greatest versions of these 
directory servers, you may need to avoid memberOf/isMemberOf and use the 
standard methods of querying group membership.


More information about the samba-technical mailing list