Here's a long description of how the rights are established for the software groups in OIT's portion of the WolfTech active directory.  It's long and in narrative style, in hopes it will illustrate the thought processes that yielded this configuration.

Two facts one should know

• Computers objects can be members of AD groups
• Group objects can be members of AD groups

In WolfTech, to assign an application to be installed on a machine, you just add that machine to a specially named group. 

Normally in a directory service like eDir or AD, one must have administrative access to both the object to go into a group (to update the "groups_I'm_in" attribute(s)) and the group object (to update the "members" attrbute).   In such a model, one must grant permissions to everyone who could possibly share apps with you.  This is unmanagable in a distributed environment like WolfTech.

So, to identify those admins whom you trust, you create a group (call it the resource group) and assign it the rights needed.  In your resource group, you add groups owned and controlled by the other trusted admin.   Since these groups are owned by the other admin, they can add or remove members themselves, and control access to the apps or other services you're sharing with them.  You're only giving rights to the members of your resource group, so you can control access to the stuff you're sharing, and revoke it if you choose.

For OIT, the groups that control access to campus software is located in the container OU=Software Packages,OU=OIT .  To control who can associate software to windows machines, I've created a group, named OIT-Software-Admins, that has rights over this container and everything in it.  This new group is located in OU=Access Groups, OU=Management Objects, OU=OIT. 

The members of this group happen to all be "role" groups, by which I mean there are absolutely no rights assigned to the role group,it simply represents a job function.  One member is a role group named "OIT-Application-Packagers" which happens to be used by TSS to identify those folks who package applications.  If a new person is expected to package windows apps is identified, then adding them to this role group will automatically get the rights they need to do their new job function.  Auditing is easier, 'cause you know both what a person has access to (from the resource group), and for what purpose (from the role group).

As with most identity management schemes, this one is slightly harder to grasp than just assigning rights directly to individuals and groups, but the benefits are disproportionate to the extra effort.  Also like most other IAM schemes, success depends on identifying the right roles that represent what people's job functions are.