Problems creating a Samba4 LDAP Backend

simo idra at
Fri Mar 21 22:19:32 GMT 2008

On Fri, 2008-03-21 at 10:51 -0700, Andrew Morgan wrote:
> 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.

Hmm this seem just a description of a virtual attribute.

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

IIRC in AD memberOf is a linked attribute, stored permanently.

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

Yes it is a good idea to do so.

> 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:
>    (&(objectclass=groupofuniquenames)(uniquemember=uid=doej))
> can be just as fast as:
>    (&(objectclass=posixaccount)(uid=doej))

It matters if you start thinking of nested groups as in that case the
number of searches may increase considerably, although, if all the data
is in cache it may not have such a big impact depending on the frequency
of such searches.

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

Samba4 has very peculiar needs as the aim is to provide an AD compatible
interface to the clients. This is because MS clients are tightly coupled
and expect certain behaviors that are AD specific. We can't just run a
generic directory in this case, we either proxy and translate to a
generic directory or we heavily modify one.

So far we have basically worked on 2 fronts. One was to make our own
LDAP implementation based on our LDB database so that we could freely
experiment and discover exactly what the clients need/want. At the same
side we developed LDB to be a proxy to a backend directory and created a
module called ldb_map that could do translation on the fly.
This second approach is showing the inherent limits it was clear we
would have met since we started. The point is to decide to what degree
of compatibility we need to get to.

Personally I am ok with just Windows clients being able to join using
Kerberos and our Directory, even if some Windows admin tools don't work.

We have reached this point some time ago already, it is just a matter of
deciding when we are compatible enough to be satisfied, and start
stabilizing the code.


Simo Sorce
Samba Team GPL Compliance Officer <simo at>
Senior Software Engineer at Red Hat Inc. <ssorce at>

More information about the samba-technical mailing list