The probable reason that the memberOf
attribute does not contain all the nested group information is that the value is computed when the attribute is loaded, as noted in this link:
Be aware that this attribute lists the groups that contain the user in their member attribute—it does not contain the recursive list of nested predecessors. For example, if user O is a member of group C and group B and group B were nested in group A, the memberOf attribute of user O would list group C and group B, but not group A.
This attribute is not stored—it is a computed back-link attribute.
Hence, to support this, your DC would be forced to load all nested groups every time a LDAP query returned the memberOf
attribute, which could be a lot of excess work.
Depending on the technology you are using, there are almost certainly better ways to check group membership than loading all groups and listing them all. For example, ADSI has a pre-built function to check if a user is a member of the group.
However, for a pure LDAP solution, you could use the LDAP_MATCHING_RULE_IN_CHAIN
as shown in this answer (assuming you have the DN for the user), e.g.,
(member:1.2.840.113556.1.4.1941:=CN=Administrator,OU=Users,DC=fabrikam,DC=com)
Which will get all the groups which Administrator is a member of. Note, however, that this query can be extremely slow. To speed up performance, consider paging results or restricting the search base to only the group you are interested in checking.