Can we get attributes of all referenced DNs in LDAP with a single query?

Question

For example, the following is ldapquery and it's output:

# ldapsearch -LLL -h myldaphost -D uid=myname,ou=People,ou=MyBranch,o=MyOrg -x -w mypasswd -b cn=TEST_USERS,ou=Groups,ou=MyBranch,o=MyOrg uniqueMember
dn: cn=TEST_USERS,ou=Groups,ou=MyBranch,o=MyOrg
uniqueMember: uid=user1,ou=People,ou=MyBranch,o=MyOrg
uniqueMember: uid=user2,ou=People,ou=MyBranch,o=MyOrg
uniqueMember: uid=user3,ou=People,ou=MyBranch,o=MyOrg
uniqueMember: uid=user4,ou=People,ou=MyBranch,o=MyOrg

Let's say each uniqueMember dn has Employee number attribute too.

ldapsearch -LLL -h myldaphost -D uid=myname,ou=People,ou=MyBranch,o=MyOrg -x -w mypasswd -b uid=user1,ou=People,ou=MyBranch,o=MyOrg  employeeNumber
dn: uid=user1,ou=People,ou=MyBranch,o=MyOrg
employeeNumber: 5282345

How can we get employee numbers of all the employees of the group with a single query?

Answer 1

You can't, at least not without an overlay. LDAP is not SQL and doesn't natively support join operations.

If you want that information you're going to have to do 1+n queries.

Except it is possible to do the equivalent of follow a single dn valued attribute with with memberOf overlay. In this case the filter string is memberOf=cn=groupname,ou=groups,dc=example,dc=com.

Answer 2

There is a I-D for the LDAP Dereference Control which can be used with search operations to dereference DNs one level deep.

Two obstacles using it:

• It's only supported by OpenLDAP (with overlay slapo-deref) and IIRC also by 389-DS.
• You're using group member attribute uniqueMember which is not Dinstiguished Name syntax (Syntax-OID 1.3.6.1.4.1.1466.115.121.1.12) but Name And Optional UID (Syntax-OID 1.3.6.1.4.1.1466.115.121.1.34). But draft-masarati-ldap-deref explicitly requires DN syntax.

When using deref control you should take care to not retrieve data multiple times. For example if a user is member of many groups you would retrieve the same data that many times which can be a real performance penalty.

So maybe a client-side join is the better solution anyway.