Subject: Grouper Users - Open Discussion List
Re: [grouper-users] Active Directory Organizational Unit Design
- From: Chris Phillips <>
- Subject: Re: [grouper-users] Active Directory Organizational Unit Design
- Date: Tue, 27 Apr 2010 09:29:49 -0400
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...
On 27/04/2010 4:34 AM, Ward, Mike wrote:
* 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.
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 :) )
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.
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.
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.
Sure, just email me :)
Description: S/MIME Cryptographic Signature
- Active Directory Organizational Unit Design, Ward, Mike, 04/27/2010
- Re: [grouper-users] Active Directory Organizational Unit Design, Chris Phillips, 04/27/2010
- Re: [grouper-users] Active Directory Organizational Unit Design, Tom Zeller, 04/27/2010
- Re: [grouper-users] Active Directory Organizational Unit Design, Tom Barton, 04/29/2010
Archive powered by MHonArc 2.6.16.