Browse Prior Art Database

Identifying nested group membership in distributed directory without additional support from backend

IP.com Disclosure Number: IPCOM000176669D
Original Publication Date: 2008-Nov-20
Included in the Prior Art Database: 2008-Nov-20
Document File: 2 page(s) / 87K

Publishing Venue

IBM

Abstract

This article provides a mechanism to do group processing involving nested group in a distributed directory setup by querying the backend servers and forming a in-memory nested group map and doing processing related to nested groups in memory.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 53% of the total text.

Page 1 of 2

Identifying nested group membership in distributed directory without additional support from backend

              Authors
Magesh Rajamani, Yogesh V Golwalkar, Kristin M Hazlewood.

IBM

In a distributed directory environment, determining the groups to which an entry belongs to is not straightforward. This becomes all the more complex if there are nested groups in the environment.

Nested groups are groups which have another group as its member. So if an entry

E1 is a member of group G and group G is a member of nested group NG1 - then entry E1 is a member of both G and NG1. Assuming E1, G and NG1 as discussed above as part of a distributed environment. Also assume that we have more nested groups like NG2 which has NG1 as its member and NG3 which has NG2 as member. Also assume that the distributed environment has a proxy server which manages 3

partitions having servers S1, S2, S3

corresponding to each partition and the entries discussed above are distributed as E1 and NG3 in server S1, G and NG2 in server S2 and NG1 in server S3. In this scenario, if a client requests for all the groups that E1 belong to -

proxy should first send a request to all servers to find the

groups that E1 belong to which will return only G1. With this information, it should again request all the servers for the list of groups that G1 is a member of which will return NG1. It needs to repeat this step to get NG2 and NG3. Hence this kind of all-groups search could become very costly.

In addition to this, cycles are not allowed in groups which mean, in our example - we cannot make NG3 as a member of G. Therefore during group addition a lot of processing will be required to identify cycles.

Access control processing is dependent on identifying the groups to which particular user belongs to. Therefore getting the full list of groups is vital for true distributed group processing (which involves nested group as well).

To determine all groups that a specific entry belongs to.

1) Proxy Server will send a group evaluation extended operation to all the backend partitions, as is done in IBM Tivoli Directory Proxy Server currently. This will give a list of static and dynamic groups of the entry.

2) Then the proxy server will send a search request to each of the back-end servers requesting all group entries that are nested group entries and only the attributes which has nesting information (for example ibm-MemberGroup in case of IBM Tivoli Directory Server). Let us assume that the nested group entry's objectclass is ibm-nestedGroup and nested group attribute name is memberGroup. With this assumption this step can be achieved by a search to all the backend servers with filter "objectclass=ibm-nestedGroup" and asking for only ib...