Grouper Users - Open Discussion List

["Bee-Lindgren, Bert" <>]

I'm going to answer this for Groups PSPNG. If there are reasons you have to use PSP (old), then we can readdress that.

1) Regardless of whether you use a bushy or flat OU, you should name your groups uniquely. At Georgia Tech, we reverse the group's native name, so the most interesting part of the name is first... In other words, name your group webserveradmins:wiki:services:uiuc because AD users will be typing webserveradmins or will be looking at a truncated name of the group in some UI somewhere. You can either truncate the cn/samaccountname to the 64 allowed characters, or add a hash to the end.

2) There should not be any performance problems in maintaining a bushy hierarchy. Obviously, OUs need to be created, but that's a small fraction of the ldap changes and they're pretty quick.

3) Maintaining multiple base OUs for the groups is good, particularly if they have different permissions. If at all possible, I would put the permissions on those base OUs and not on the groups themselves.

4) Configuring multiple Base OUs would appear in PSPNGs config as different provisioners, sharing connectivity information, but with different group-selection criteria/grouper properties.

5) FWIW, at Georgia Tech, we have thousands of AD groups populated in a flat OU. It's hell to browse with Windows tools, but otherwise is great.

Hoping this helps,

  Bert

---

From: <> on behalf of Coleman, Erik C <>
Sent: Monday, January 9, 2017 2:05 PM
To:
Subject: [grouper-users] PSP sync: The "bushy" vs. "flat" debate

 

Our in-progress Grouper implementation project will become a major source of group membership info for our Active Directory instance (not so much the other way around).  We plan to have a PSP configured to synchronize certain categories of groups into various OUs within the AD tree.  Given that we already have a well-established and mature AD implementation, it would seem to make sense to lean toward a “bushy” model, whereas those that are used to organizing groups into sub-OUs in AD can continue to do so using Grouper.  This also seems to open up some granularity in terms of leveraging AD access controls (assuming PSP has the necessary write rights) on certain sensitive groups/OUs.  Our presumption is that these OUs (and descendants) will have Grouper be solely authoritative for the data and the ACLs of concern would be read-only or no access.  One area of concern would be group naming and the potential for duplicates in different OUs, as the derived sAMAccountName has to be unique across the entire domain.

 

On the other hand, I have heard stories of slow sync times and that following a “flat” model would be far more efficient. And a concatenation of the path naming i.e., “uiuc:services:wiki:webserveradmins” would translate into the AD side group naming, providing uniqueness, even if all jammed into a single OU. As far as assigning ACLs, I recall Eric Kool-Brown and others going as far as having a post-sync script assigning it on a per-group basis, though that seems like more moving parts to me.

 

I’m curious what others may have done both with the bushy vs. flat sync topology, as well as their naming taxonomy and approach to granular access control in order to accommodate it.  Have you tried both?  A hybrid model with multiple syncs doing things differently? Do you see a major advantage over doing it one way vs. the other?

 

Thanks for sharing your experiences!

 

--

Erik Coleman

Technology Services

University of Illinois at Urbana-Champaign