I would like to construct an LDAP query to find all users that are part of the "Google Apps Users" group (short name: googleappsusers) on my OS X 10.9 Server. When I run the following query in Google Apps Directory Sync (GADS) it returns zero users despite the fact that I do indeed have a user in the googleappsusers group.


Apple Open Directory does not use the memberOf user attribute (OSX Server 10.7.5).

Instead it solely relies on the memberUid group attribute to enumerate the users which are members of a given group. Therefore one cannot determine a users group memberships by querying the user object, but must instead enumerate all groups for memberUid attributes corresponding to that user, if one wishes a complete list of user specific group memberships.

One can of course modify the schema to add the memberOf attribute, but must then also do the necessary legwork of keeping the group memberUid attribute values and the user memberOf attribute values in sync.

This is in contrast to ldap implementations which support the memberOf user attribute and which contain mechanisms for keeping the values of the attribute pair in sync (Microsoft Active Directory, OpenLDAP with the memberOf overlay).

The [Google Apps Directory Sync Administration Guide][1], page 28, states that:

There are three ways to mark your Google Apps users in LDAP:
• OU: Set up an organizational unit (OU) and move Google Apps users into that unit.
• Group: Create a new group in LDAP, and add Google Apps users as a member of that group.
• Custom Attribute: Create a custom attribute for your users, and set that attribute for new users.

My guess is you could solve the task through either one, but querying users for memberOf only works if you yourself add the memberOf attribute to your user objects. It is to be regarded as a Custom Attribute with Open Directory.

That some attributes are empty in an ldap object is not a great cause for concern, it just means they are included in the ldap schema but their values have not been set for the ldap object. You would see a similar state of things in any out-of-the-box ldap implementation.

[1] http://static.googleusercontent.com/external_content/untrusted_dlcp/www.google.com/en/us/support/enterprise/static/gapps/docs/admin/en/gads/admin/gads_admin.pdf


I usually use Softerras LDAP Browser to browse LDAP trees to find the right syntax/paths quicker. There are lots of free ldap browsers, it's just the one I picked up somewhere along the line and didn't bother exchanging.

Looks like there are a couple of alternatives for osx too if you have a mac client: http://en.m.wikipedia.org/wiki/List_of_LDAP_software

  • Thanks Erik. I have been using JXplorer and the interesting this is when I inspect any object, the "memberOf" property is empty. Only the most basic if properties contains any value. Thoroughly confused. – sardean Nov 18 '13 at 20:38
  • Hmm.. Rings bells that does. I do not have experience of the osx ldap implementation, but did run into openldap a few years back. A customer had trouble with the (non presence of the) member and memberOf attributes. I recall that under Linux, there was an add-on "helper" which was needed to synchronize member and memberOf attributes between objects - where one was a member of the other, the other needed to have memberOf with the value of the first. That said what you are seeing could for instance be permissions related. I have no idea if this was relevant to your case or not :-) – ErikE Nov 18 '13 at 20:49
  • Unless some real osx ldap expert turns up to give insight, I could try installing the open directory (if I recall the name correctly) on my own osx server(lion). Just to do a comparison together with you. Possibly open directory doesn't use so many attributes, I recall open ldap as being pretty bare bones in the default state compared to active directory which really litters the ldap tree (in a useful way). – ErikE Nov 18 '13 at 20:58
  • I installed Open Directory and gave it a spin, see second answer. – ErikE Nov 18 '13 at 22:30

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.