Subject: Grouper Users - Open Discussion List
[grouper-users] replicating to AD, questions about managing permissions
- From: Steven Carmody <>
- To: "" <>
- Subject: [grouper-users] replicating to AD, questions about managing permissions
- Date: Thu, 25 Sep 2014 15:33:51 -0400
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.
- [grouper-users] replicating to AD, questions about managing permissions, Steven Carmody, 09/25/2014
Archive powered by MHonArc 2.6.16.