I've seen similar questions related to configuring Apache to authenticate via LDAP, but this basic question still has me confused.

In my setup, I created users who all have the same primary GID, then I added users to various (supplementary/secondary) groups. I have tested these user accounts, and in most situations everything works fine - my permissions based on supplementary group membership is working. I used the smbldap-tools package to configure my users and groups, and specifically I used smbldap-usermod -G +NEW_GROUP user to add users to the supplementary groups.

If I do getent group I see those supplementary groups and their members. Good.

If I look at the LDAP entry for one of the supplementary groups, I see all the users listed just as expected.

However, when I look at each user's LDAP entry, only a gidNumber corresponding to the primary group is listed. That is, the LDAP entries for each user only list the primary group, and have no mention of secondary groups.

How does Samba/LDAP (using smbldap-tools) handle supplementary/secondary groups?

Further, how could I form a search filter to identify members of a supplementary group?


LDAP is just a directory of information. How that information gets stored and retrieved is up to the application. In this case, posix users and groups are modeled after the /etc/passwd and /etc/group files. Each user entry lists the gid for its primary group. Each group lists all of its members(usually less the ones listing it as their primary group).

Samba and the various nss plugins to store user and group info in LDAP all do a search to find the groups a user is a member of at log in. The memberUid attribute should be indexed to make group membership searches fast. For a given user account, the search filter is something like:


If you wanted to see the users in a particular group, you could search with:


This assumes that all of your groups are of the posixGroup objectClass.

  • 1
    The problem with posixGroup is, unfortunately, that it is not possible to get, with a single filter/query, every group of which a user is part. You can ask for the user's primary group (which is stored in the user object itself) and you can ask a group for all its users, but everything else needs to be done at a higher (or lower?) level, e.g. the scripting language used (Bash, Python, Perl, ...). Ideally there would be a memberOf overlay that supports posixGroup and memberUid, but there doesn't seem to be one.
    – daff
    Nov 22 '11 at 22:22
  • That wasn't the original question. However, if you are writing a program, what is the harm in making two queries? Nov 23 '11 at 4:34
  • 1
    See serverfault.com/questions/224750/… for instructions on setting up groups so memberof works. Nov 23 '11 at 4:39
  • 1
    I know it wasn't the original question, but there is a close relation, that's why I commented. Often you want or need to define a single filter that matches all users of a given group, e.g. for access control, because the application that interfaces with LDAP isn't flexible enough to allow for two queries (to mind come Dokuwiki or SSSD). Thanks for the pointer to 224750, I was never able to find useful information about that, will have a look at it.
    – daff
    Nov 23 '11 at 13:13
  • So, what does one do? Ditch posixGroup? What does one use in its place?
    – Pyperdown
    Feb 20 '13 at 17:21

I'm not a big OpenLDAP user, but if this were an Active Directory environment I'd use the "memberOf" attribute present in each user account object. In the OpenLDAP world, it looks like the memberOf overlay will do what you're looking for. I suspect this question will tell you what you need to know to get this going.

  • The OP is apparently using POSIX groups (such groups have a gidNUmber and are of objectClass posixGroup), which can not be used with the memberOf overlay.
    – daff
    Nov 22 '11 at 22:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.