How to setup rights to administer Group Membership

What rights are required to change Group Membership for a User?

To set up Users, Groups, or Organizational Role objects with sufficient rights to administer Group Membership for other User objects:

Make the User, Group, or Organizational Role object a trustee of the target Group objects, either directly or via inheritance, such that they have Compare/Read/Write effective rights to the MEMBER and EQUIVALENT_TO_ME attributes. This can be done with a direct assignment of rights to the Group object, or via inherited rights from a parent container object. The User will also require Browse effective rights to the target User objects to be managed (this is present by default).

If the goal is to manage group membership from the perspective of the user object, you need to go to the container that you would like your Organizational Role to administer and make it a trustee of that container. You then need to give it the following rights:
    GROUP MEMBERSHIP with Compare, Read, Write, and INHERITABLE
    SECURITY EQUALS with Compare, Read, Write, and INHERITABLE

The reason that this works is a feature called "Write Managed" rights to the objects being modified. Group membership is one of the few sets of attributes where this little understood feature is used.

Why it works is that DS checks only the Group object for rights to determine if the operation should be allowed to proceed or not. If the modifying object has sufficient rights to the Group object to change its MEMBER and EQUIVALENT TO ME attributes, then the modifying object is also allowed to modify the User object that is being added. The modifying object's rights to the User object being modified are not used, other than the modifying object must be able to see (Browse) the object to be modified.

"Write Managed" attributes are described further, with an example, on pages 144 and 145 of Novell's Logic Source for NDS document.

Note that some utilities may not correctly handle Write Managed attributes.