Grouper Users - Open Discussion List

[Chris Phillips <>]

Hi Mike,
While we don't use Grouper (yet), we can provide some answers on how we deployed our AD tree  and what we are considering to adjust.  See answers inline.
If you want to more detail, feel free to contact me directly, I would be interested in talking to you about the Forefront activity you guys have on the go.

Hope this helps...

Chris.

On 27/04/2010 4:34 AM, Ward, Mike wrote:

Other questions that have come out of this discussion are:

1)      What are other universities doing regarding AD design using grouper?

 We don't have grouper, but do synchronize groups through custom _javascript_s.  Here is our model:

* We created an OU off the root called 'Groups' and under there have ou=Class Enrollments, ou=Course Concentrations and also ou=HR Departments that hang off that.
* Class Enrollments are a deeply nested tree (e.g. Computing 101 section A Fall Winter term is: "cn=CISC101-A-FW,ou=CISC101, ou=CISC, ou=Class Enrollments,dc=queensu,dc=ca")
** The theory was that we could apply or grant access to subtrees for various courses (some have 20+ sections), but I do not think we have utilized this feature much. If anything, it helps keep the 8-10,000 groups organized.
* HR Departements are flat and all ~300 or so are present in that one OU
* Course Concentrations are groups  like 'cn=ARTH-2' which would be all ART History, 2nd year.  We do this for all concentrations.

Visibility policy for the group info is based on revealing the group memberships to OU Admins who can see All groups and All people objects.

2)      GPO’s – We would likely need to use group policy security filtering to apply the user GPO.  We would create a GPO for each department, give access to departmental administrators to modify the GPO for only their departments, then filter the GPO to only run for a specific group.  Questions about performance where raised.  Maybe this should be done through a third-party utility?

I'm not the AD admin, but GPO's are created by the AD Admins for global elements, and the OU Admins can create any policy they want in their OU.
OU Admins have the ability to create computers and printers and groups within the scope of their OU.  I cannot remember if we permit them to create people objects not under control of the identity management system (Sun IDM) or not.  The reason not to is to prevent collisions on the DN for the id.

What we *DO* find though is that OU admins most times shadow the mainstream groups for HR to do the discrete adds and 'adjustments'.  This is commonly done with the regular AD tools.

Yes, this is a great use case for Grouper where the group adjustments are done outside the AD tree and then published back in and therefore more universally available.  Given all the other things on the go, we are not ready for an across the board 'how to manage groups a better way' overhaul. (althought I would like to do it :) )

3)      Remote administrators user accounts access - It would simplify administration for departmental administrator to have accounts and groups in a departmental OU, instead searching through all names.   A possible workaround of having user in one OU are creating custom LDAP searches for departmental administrators.  Other solutions or thoughts on managing a large amount of user in one container vs. departmental OU’s?

We have all our people in an OU=People tree for the very same reason you talk about...people move around, but their people record remains the same and their group memberships change.
OU admins can see all people in order them to create policies and actually be able to perform permission managment.

The one thing we contemplated is that it would be very handy to split Students from Employees into separate people trees.  We explored that for a bit, but now that we have PeopleSoft and a single Person model (one id can be both student and staff) this is likely to not change from a single OU.  There is a notion of a 'home department', but it is yet to be seen if we will create your person record in that OU.
Of course this means that if your home department changes, we will have to do a mod RDN on you, if we go down this path (ugh).
The theory was that if we can split off students, we can grant all employees the ability to see the ou=employee,ou=people subtree.  Right now OU Admins are the only ones that can see the OU=people tree and it 'works' for now.

I'll cautiously mention the 'What does this mean to Exchange?' question.  If you ever plan to use Exchange or Sharepoint, or if anyone in you AD tree wants to, take a look at what it favours for design for a people tree.  I believe it strongly desires people in the leaf OU's so that Exchange can delegate out access.  My understanding is that a gigantic OU=people will cause severe performance havoc with Exchange.  

Like I had mentioned above, the Home departement is where I would place people, but I don't know what to do with people who are cross appointments.  I'm keeping my fingers crossed that Peoplesoft will help improve things along these lines.

4)      Do we want to apply permissions on the object level or the container level?  What is MS best practices to control by OU vs. scripting?

Not sure about this one, but container level with recursive assignment to all objects within container would be my bet.  Scripting the action would be interesting, but sounds like more work.

5)      Is it a security breach for all departmental admins to see all user account information?  I believe that all authenticated users have read access anyway.

See answer to #3.  I believe it to be possible to revoke the ability to navigate the ou=people subtree for the regular users.  Limits functionality in some senses, but protects the private info.  You can still type in a name as a user and validate it as existing to grant specific access.

I would really like to talk to any university that is doing a similar setup with grouper, particularly in regards to how active directory was setup.

Sure, just email me :)

 

Thank you for any information you have regarding this.

Mike

 

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature