Examples of querying group membership

Figure 1. Group hierarchy and membership for the examples

The entries below are used in the following examples:

dn: o=ibm
objectclass: organization
aclEntry: group:CN=ANYBODY:normal:rsc:system:rsc
aclPropagate: TRUE
o: ibm

dn: cn=g1,o=ibm
objectclass: container
objectclass: ibm-nestedGroup
cn: g1
ibm-memberGroup: cn=g2,o=ibm
ibm-memberGroup: cn=g3,o=ibm
aclEntry: group:CN=ANYBODY:normal:rsc:system:rsc

dn: cn=g2,o=ibm
objectclass: accessGroup
cn: g2
member: cn=u1,o=ibm
member: cn=u2,o=ibm
aclEntry: group:CN=ANYBODY:normal:rsc:system:rsc
aclEntry: access-id:cn=u1,o=ibm:normal:rsc:system:rsc
aclEntry: access-id:cn=u2,o=ibm:normal:rsc:system:rsc:at.member:deny:rsc

dn: cn=g3,o=ibm
objectclass: container
objectclass: ibm-nestedGroup
cn: g3
ibm-memberGroup: cn=g4,o=ibm
ibm-memberGroup: cn=g5,o=ibm
ibm-memberGroup: cn=g6,o=ibm

dn: cn=g4,o=ibm
objectclass: accessGroup
cn: g4
aclEntry: group:CN=ANYBODY:normal:rsc:system:rsc
aclEntry: access-id:cn=u4,o=ibm:normal:rsc:system:rsc:at.member:deny:c
member: cn=u5,o=ibm

dn: cn=g5,o=ibm
objectclass: container
objectclass: ibm-dynamicGroup
cn: g5
memberURL: ldap:///o=ibm??sub?(|(cn=u3)(cn=u4))
aclEntry: group:cn=ANYBODY:normal:rsc:system:rsc
aclEntry: access-id:cn=u3,o=ibm:normal:rsc:system:rsc:at.ibm-allMembers:deny:rs:
 at.ibm-allMembers:grant:c

dn: cn=g6,o=ibm
objectclass: container
objectclass: ibm-dynamicGroup
cn: g6
memberURL: ldap:///o=ibm??sub?(cn=*3)

dn: cn=u1,o=ibm
objectclass: person
cn: u1
sn: user
userpassword: secret1

dn: cn=u2,o=ibm
objectclass: person
cn: u2
sn: user
userpassword: secret2

dn: cn=u3,o=ibm
objectclass: person
aclEntry: access-id:cn=u1,o=ibm:normal:rsc:system:rsc:at.cn:deny:s
aclEntry: access-id:cn=u2,o=ibm:normal:rsc:system:rsc:at.ibm-allGroups:deny:r
aclEntry: group:cn=ANYBODY:normal:rsc:system:rsc
cn: u3
sn: user
userpassword: secret3

dn: cn=u4,o=ibm
objectclass: person
aclentry: group:cn=ANYBODY:normal:rsc:system:rsc
aclentry: access-id:cn=u3,o=ibm:normal:rsc:system:rsc:at.ibm-allGroups:deny:r
cn: u4
sn: user
userpassword: secret4

dn: cn=u5,o=ibm
objectclass: person
cn: u5
sn: user
userpassword: secret5

dn: cn=u6,o=ibm
objectclass: person
cn: u6
sn: user
userpassword: secret6

Note: The ibm-allMembers and ibm-allGroups attributes are system class attributes. The member and cn attributes are normal class attributes.

ibm-allGroups and ibm-allMembers search and comparison examples:

Example 1: This example shows an ibm-allMembers attribute search on a static group entry.

ldapsearch –L –D "cn=u6,o=ibm" –w secret6 –b "cn=g4,o=ibm" "objectclass=*" ibm-allMembers

dn: cn=g4,o=ibm
ibm-allmembers: cn=u5,o=ibm

Access checking done for cn=u6,o=ibm:

Read access to the ibm-allMembers attribute in cn=g4,o=ibm.
Read access to the member attribute in cn=g4,o=ibm.

Example 2: This example shows an ibm-allMembers attribute search on a dynamic group entry.

ldapsearch –L –D "cn=u6,o=ibm" –w secret6 –b "cn=g5,o=ibm" "objectclass=*" ibm-allMembers

dn: cn=g5,o=ibm
ibm-allmembers: cn=u3,o=ibm
ibm-allmembers: cn=u4,o=ibm

Access checking done for cn=u6,o=ibm:

Read access to the ibm-allMembers attribute in cn=g5,o=ibm.
Search access to the cn attribute in the returned entries, cn=u3,o=ibm and cn=u4,o=ibm, from the search filter specified in the memberURL attribute.

Note: memberURL attribute access rights do not matter.

Example 3: This example shows an ibm-allMembers attribute search on a nested group entry.

ldapsearch –L –D "cn=u6,o=ibm" –w secret6 –b "cn=g3,o=ibm" "objectclass=*" ibm-allMembers

dn: cn=g3,o=ibm
ibm-allmembers: cn=g3,o=ibm
ibm-allmembers: cn=u3,o=ibm
ibm-allmembers: cn=u4,o=ibm
ibm-allmembers: cn=u5,o=ibm

Access checking done for cn=u6,o=ibm:

Read access to the ibm-allMembers attribute in cn=g3,o=ibm.
Read access to the member attribute in cn=g4,o=ibm.
Search access to the cn attribute in the returned entries, cn=u3,o=ibm and cn=u4,o=ibm, from the search filter specified in the memberURL attribute of cn=g5,o=ibm.
Search access to the cn attribute in the returned entries, cn=u3,o=ibm and cn=g3,o=ibm, from the search filter specified in the memberURL attribute of cn=g6,o=ibm.
Note: Since cn=u3,o=ibm has already been added as an ibm-allMembers attribute value, a duplicate value will not be added.

Note: ibm-memberGroup access rights do not matter.

Example 4: This example shows an ibm-allMembers attribute search on a dynamic group entry when the bound user is not granted read access to the ibm-allMembers attribute.

ldapsearch -L -D "cn=u3,o=ibm" -w secret3 -b "cn=g5,o=ibm" "objectclass=*" ibm-allmembers 

dn: cn=g5,o=ibm

Access checking done for cn=u3,o=ibm:

Read access to the ibm-allMembers attribute in cn=g5,o=ibm has been denied. Therefore, no ibm-allMembers attribute values will be added.

Example 5: This example shows an ibm-allMembers attribute search on a static group entry when the bound user does not have read authority on the member attribute.

ldapsearch -L -D "cn=u2,o=ibm" -w secret2 -b "cn=g2,o=ibm" "objectclass=*" ibm-allmembers

dn: cn=g2,o=ibm

Access checking done for cn=u2,o=ibm:

Read access to the ibm-allMembers attribute in cn=g2,o=ibm.
Read access to the member attribute in cn=g2,o=ibm has been denied. Therefore, the member attribute value will not be added as an ibm-allMembers attribute value.

Example 6: This example shows an ibm-allMembers attribute search on a dynamic group entry when the bound user does not have search authority in the entries that are to be returned for the attributes that are specified in the dynamic group filter.

ldapsearch -L -D "cn=u1,o=ibm" -w secret1 -b "cn=g5,o=ibm" "objectclass=*" ibm-allmembers

dn: cn=g5,o=ibm
ibm-allmembers: cn=u4,o=ibm

Access checking done for cn=u1,o=ibm:

Read access to the ibm-allMembers attribute in cn=g5,o=ibm.
Search access to the cn attribute in the returned entries, cn=u3,o=ibm and cn=u4,o=ibm, from the search filter specified in the memberURL attribute. However, search access has been denied on the cn attribute of cn=u3,o=ibm therefore it is not added as an ibm-allMembers attribute value.

Example 7: This example shows an ibm-allMembers comparison operation on a dynamic group entry.

ldapcompare -D "cn=u3,o=ibm" -w secret3 "cn=g5,o=ibm" "ibm-allmembers=cn=u3,o=ibm"
ldap_compare: Compare true

Access checking done for cn=u3,o=ibm:

Compare access to the ibm-allMembers attribute in cn=g5,o=ibm.
Search access to the cn attribute on the returned entries, cn=u3,o=ibm and cn=u4,o=ibm, from the search filter specified in the memberURL attribute.

Example 8: This example shows an ibm-allGroups attribute search where the user belongs to dynamic and nested group entries.

ldapsearch -L -D "cn=u6,o=ibm" -w secret6 -b "cn=u4,o=ibm" "objectclass=*" ibm-allGroups

dn: cn=u4,o=ibm
ibm-allgroups: cn=g5,o=ibm
ibm-allgroups: cn=g3,o=ibm
ibm-allgroups: cn=g1,o=ibm

Access checking done for cn=u6,o=ibm:

Read access to the ibm-allGroups attribute in cn=u4,o=ibm.
Search access on the cn attribute in cn=u4,o=ibm from the search filter specified in the memberURL attribute in cn=g5,o=ibm.

Since cn=g3,o=ibm has cn=g5,o=ibm as an ibm-memberGroup attribute value, cn=g3,o=ibm is added as an ibm-allGroups attribute also. cn=g1,o=ibm has cn=g3,o=ibm as an ibm-memberGroup value, therefore cn=g1,o=ibm is also added as an ibm-allGroups attribute value.

Example 9: This example shows an ibm-allGroups attribute search where the user belongs to static and nested group entries.

ldapsearch -L -D "cn=u1,o=ibm" -w secret1 -b "cn=u2,o=ibm" "objectclass=*" ibm-allGroups

dn: cn=u2,o=ibm
ibm-allgroups: cn=g2,o=ibm
ibm-allgroups: cn=g1,o=ibm

Access checking done for cn=u1,o=ibm:

Read access to the ibm-allGroups attribute in cn=u2,o=ibm.
Read access to the member attribute in cn=g2,o=ibm.

Since cn=g1,o=ibm has an ibm-memberGroup attribute value of cn=g2,o=ibm, cn=g1,o=ibm is added as an ibm-allGroups attribute value.

Example 10: This example shows an ibm-allGroups attribute search where the user being searched belongs to static and nested group entries. The bound user has read authority to the ibm-allGroups attribute of the user being searched, but does not have read authority on the member attribute in the static group entry.

ldapsearch -L -D "cn=u2,o=ibm" -w secret2 -b "cn=u2,o=ibm" "objectclass=*" ibm-allGroups

dn: cn=u2,o=ibm

Access checking done for cn=u2,o=ibm:

Read access to the ibm-allGroups attribute in cn=u2,o=ibm.
Read access to the member attribute of cn=g2,o=ibm is denied. Therefore, cn=g2,o=ibm is not added as an ibm-allGroups attribute value.

Example 11: This example shows an ibm-allGroups search where the bound user does not have read authority on the ibm-allGroups attribute.

ldapsearch -L -D "cn=u3,o=ibm" -w secret3 -b "cn=u4,o=ibm" "objectclass=*" ibm-allGroups

dn: cn=u4,o=ibm

Access checking done for cn=u3,o=ibm:

Read access to the ibm-allGroups attribute in cn=u4,o=ibm is denied. Therefore, no ibm-allGroups attribute values are added.

Example 12: This example shows an ibm-allGroups comparison operation where the bound user is allowed to determine that a user belongs to a nested group entry.

ldapcompare -D "cn=u2,o=ibm" -w secret2 "cn=u3,o=ibm" "ibm-allGroups=cn=g1,o=ibm"

ldap_compare: Compare true

Access checking done for cn=u2,o=ibm:

Compare access to the ibm-allGroups attribute in cn=u3,o=ibm.
Search access to the cn attribute of cn=u3,o=ibm is granted from the search filter specified in the memberURL attribute in cn=g5,o=ibm.

Since cn=g3,o=ibm has cn=g5,o=ibm as an ibm-memberGroup attribute value, cn=g3,o=ibm is added as an ibm-allGroups attribute as well. cn=g1,o=group has cn=g3,o=ibm as an ibm-memberGroup value, therefore cn=g1,o=group is also added as an ibm-allGroups attribute value. Therefore, the compare operation will return an LDAP_COMPARE_TRUE to the client application.