Grouper Users - Open Discussion List

[Steven Carmody <>]

Hi,

We're about to start replicating Group memberships from Grouper to AD 
(we use Active MQ, and already have several listeners in PROD). We're 
planning to replicate several different "kinds" of groups, tho, and I'm 
discovering that AD's ACL model is a little different from what I'm used 
to. I'm writing to ask others who are already down this road, or others 
with more AD expertise than I ever hope to have, how we might address 
some of the situations that we don't have (good) solutions for.

I've listed four different kinds of groups; they have varying 
requirements. Here's hoping we have a lively community discussion about 
possible approaches !

Thanks in advance !

We plan to replicate:

1) Dept people groups (eg history-faculty-all, history-staff-all, etc). 
We will allow any authenticated user to see that these groups exist, and 
see their membership. After all, this list of names already appears on 
the Dept's web site.  ;-) The base membership of these groups is fed 
form various business systems, and then "fine-tuned" in Grouper by the dept.

We already delegate to the Dept the authority in AD to manage groups 
within their OU. The current thinking is that we would replicate the 
Grouper group to a target OU and name it grouper-history-faculty-all; 
the responsible people in the history dept could then decide to include 
grouper-history-faculty-all in their AD-based history-faculty-all group.

This use case actually seems straightforward and doable.

2) Course groups (eg history-101-students) and Dept groups that should 
not be public (eg history-student-employees). In these cases, we would 
like to restrict the ability to see the membership to some set of people 
in the Dept. They could use the groups as they need and desire.

3) Project groups. We delegate to Depts the authority to create and 
manage new groups within their Dept:Projects STEM. They could choose to 
replicate these to a number of different target environments, including 
AD. They're likely to want to control some properties and ACLs in those 
targets, including who can see the membership of the group. They may 
want to limit viewing to the Dept, or to just the members.

4) Community groups. We have a large number of demographic groups that 
represent various ways to slice and dice the community. Their membership 
is usually maintained using data that comes from various business 
systems. We need to be able to specify the set of people who can view 
the membership of these groups, or even include these groups in other 
groups.