IBM Tivoli Directory Server, Version 6.3

Determining group membership

Two operational attributes can be used to query aggregate group membership. For a given group entry, the ibm-allMembers operational attribute enumerates the aggregate set of group membership, including static, dynamic, and nested members, as described by the nested group hierarchy. For a given user entry, the ibm-allGroups operational attribute enumerates the aggregate set of groups, including ancestor groups, to which that user has membership.

Note:

A requester may only receive a subset of the total data requested, depending on how the ACLs have been set on the data. Anyone can request the ibm-allMembers and ibm-allGroups operational attributes, but the data set returned only contains data for the LDAP entries and attributes that the requester has access rights to. The user requesting the ibm-allMembers or ibm-allGroups attribute must have access to the member or uniquemember attribute values for the group and nested groups in order to see static members, and must be able to perform the searches specified in the memberURL attribute values in order to see dynamic members. For examples:

Hierarchy examples

Example of a nested group hierarchy

For this example, assume that the directory contains the following entries:

dn: cn=g1,cn=groups,o=sample 
objectclass: groupOfNames 
objectclass: ibm-nestedGroup 
cn: g1
ibm-memberGroup: cn=g2,cn=groups,o=sample
ibm-memberGroup: cn=g4,cn=groups,o=sample
ibm-memberGroup: cn=g5,cn=groups,o=sample

dn: cn=m1, cn=users,o=sample 
objectclass:person 
cn: m1 
sn: one 
aclentry: access-id:cn=user1,cn=users,o=sample:normal:rsc 
aclentry: access-id:cn=user2,cn=users,o=sample:normal:rsc 

dn: cn=m2, cn=users,o=sample objectclass:person 
cn: m2 
sn: two
aclentry: access-id:cn=user1,cn=users,o=sample:normal:rsc 
aclentry: access-id:cn=user2,cn=users,o=sample

Assume that m1 and m2 are in the member attribute of g2. The ACL for g2 allows user1 to read the member attribute, but user 2 does not have access to the member attribute. The entry LDIF for the g2 entry is as follows:

dn: cn=g2,cn=groups,o=sample
objectclass: accessGroup
cn: g2
member: cn=m1,cn=users,o=sample
member: cn=m2,cn=users,o=sample
aclentry: access-id:cn=user1,cn=users,o=sample:normal:rsc
aclentry: access-id:cn=user2,cn=users,o=sample:normal:rsc:at.member:deny:rsc

The g4 entry uses the default aclentry, which allows both user1 and user2 to read its member attribute. The LDIF for the g4 entry is as follows:

dn: cn=g4, cn=groups,o=sample
objectclass: accessGroup
cn: g4
member: cn=m5, cn=users,o=sample

The g5 entry is a dynamic group, which gets its two members from the memberURL attribute. The LDIF for the g5 entry is as follows:

dn: cn=g5, cn=groups,o=sample
objectclass: container
objectclass: ibm-dynamicGroup
cn: g5
memberURL: ldap:///cn=users,o=sample??sub?(|(cn=m3)(cn=m4))

The entries m3 and m4 are members of group g5 because they match the memberURL. The ACL for the m3 entry allows both user1 and user2 to search for it. The ACL for the m4 entries doesn't allow user2 to search for it. The LDIF for m4 is as follows:

dn: cn=m3, cn=users,o=sample
objectclass:person
cn: m3
sn: three
aclentry: access-id:cn=user1,cn=users,o=sample:normal:rsc
aclentry: access-id:cn=user2,cn=users,o=sample:normal:rsc

dn: cn=m4, cn=users,o=sample
objectclass:person
cn: m4
sn: four
aclentry: access-id:cn=user1,cn=users,o=sample:normal:rsc
aclentry: access-id:cn=user2,cn=users,o=sample
Example 1:
User 1 does a search to get all the members of group g1. User 1 has access to all members, so they are all returned.
idsldapsearch -D cn=user1,cn=users,o=sample -w user1pwd -s base -b cn=g1,
           cn=groups,o=sample objectclass=* ibm-allmembers


cn=g1,cn=groups,o=sample
ibm-allmembers: CN=M1,CN=USERS,o=sample
ibm-allmembers: CN=M2,CN=USERS,o=sample
ibm-allmembers: CN=M3,CN=USERS,o=sample
ibm-allmembers: CN=M4,CN=USERS,o=sample
ibm-allmembers: CN=M5,CN=USERS,o=sample
Example 2:
User 2 does a search to get all the members of group g1. User 2 does not have access to members m1 or m2 because they do not have access to the member attribute for group g2. User 2 has access to the member attribute for g4 and therefore has access to member m5. User 2 can perform the search in the group g5 memberURL for entry m3, so that member are listed, but cannot perform the search for m4.
idsldapsearch -D cn=user2,cn=users,o=sample -w user2pwd -s base -b cn=g1,
           cn=groups,o=sample objectclass=* ibm-allmembers


cn=g1,cn=groups,o=sample
ibm-allmembers: CN=M3,CN=USERS,o=sample
ibm-allmembers: CN=M5,CN=USERS,o=sample
Example 3:
User 2 does a search to see if m3 is a member of group g1. User 2 has access to do this search, so the search shows that m3 is a member of group g1.
idsldapsearch -D cn=user2,cn=users,o=sample -w user2pwd -s base -b cn=m3,
           cn=users,o=sample objectclass=* ibm-allgroups


cn=m3,cn=users,o=sample
ibm-allgroups: CN=G1,CN=GROUPS,o=sample
Example 4:
User 2 does a search to see if m1 is a member of group g1. User 2 does not have access to the member attribute, so the search does not show that m1 is a member of group g1.
idsldapsearch -D cn=user2,cn=users,o=sample -w user2pwd -s base -b 
           cn=m1,cn=users,o=sample objectclass=* ibm-allgroups


cn=m1,cn=users,o=sample
Example 5:
Depending on the ACLs associated with an user, the evaluation of the search consisting of the ibm-allMembers operational attribute for dynamic groups might give varied results. This example illustrates how access control can affect evaluation of the ibm-allMembers operational attributes for dynamic groups.

Consider the entries for two groups in LDIF defined as follows:

dn: cn=claims,cn=groups,o=sample
objectclass: top
objectclass: groupOfURLs
memberURL: ldap:///cn=users,o=sample??sub?(ibm-group=claims)
cn: claims

dn: cn=departmentNum, cn=groups, o=sample
objectclass: top
objectclass: groupOfURLs
memberURL: ldap:///cn=users,o=sample??one?(|(departmentnumber=2001) 
				 (departmentnumber=2002))

Consider the entries for users in LDIF defined as follows:

dn: uid=adavid, cn=users, o=sample
objectclass: top
objectclass: organizationalPerson
objectclass: inetOrgPerson
objectclass: ibm-dynamicMember
cn: Al
sn: David
departmentnumber: 2001
ibm-group: claims

dn: uid=jchevy, cn=users, o=sample
objectclass: top
objectclass: organizationalPerson
objectclass: inetOrgPerson
objectclass: ibm-dynamicMember
cn: Jerry
sn: Chevy
departmentnumber: 2002
ibm-group: claims

Here, the default access control, cn=anybody, is used, which has read, search, and compare access. This DN has access-class defined as "normal".

An user with required administrative privileges runs a search returning ibm-allMembers for these groups, the search returns:

idsldapsearch -D cn=root -w ? -b "cn=groups, o=sample" -s one objectclass=* 
               ibm-allMembers

cn=departmentNum,cn=groups,o=sample
ibm-allMembers=uid=adavid,cn=users,o=sample
ibm-allMembers=uid=jchevy,cn=users,o=sample

cn=claims,cn=groups,o=sample
ibm-allMembers=uid=adavid,cn=users,o=sample
ibm-allMembers=uid=jchevy,cn=users,o=sample

The result displays the entries that satisfy the search criteria departmentnumber=2001 or departmentnumber=2002 and ibm-group=claims.

If the same search is performed anonymously, the search returns:

idsldapsearch -b "cn=groups, o=sample" -s one objectclass=* ibm-allMembers

cn=departmentNum,cn=groups,o=sample
ibm-allMembers=uid=adavid,cn=users,o=sample
ibm-allMembers=uid=jchevy,cn=users,o=sample

cn=claims,cn=groups,o=sample

In the displayed result, entries that are members of the departmentNum group are returned that satisfy the search criteria departmentnumber=2001 or departmentnumber=2002, and no entries are returned as a member of the claims group. This is because the ibm-group attribute has access-class defined as "critical", while the departmentnumber attribute has access-class defined as "normal". Moreover, anonymous users do not have search access to attributes of access-class "critical".

In a dynamic group, the members are defined using an LDAP search. Therefore, the search for dynamic members and determination of group membership is internal to the directory server and therefore no access control applies.

However, if a client application retrieves ibm-allGroups to manage authority within some other application, then you need to be sure that the application does these searches using an identity that has the necessary authority.


[ Top of Page | Previous Page | Next Page ]