Grouper Users - Open Discussion List

["Black, Carey M." <>]

Jeffery,

 

Unfortunately, I think you are pointing at a convention/design ( limitation ?)  of PSPNG when you said this:

                “We want to provision that to our LDAP (now) but in a way that vpn app might be moved to (somewhere else in LDAP later)”

 

My current understanding of the LDAP placement rules of PSPNG  (and group/user search logic) are based on the “folder structure” in grouper mapping to a single “OU/structure” in LDAP.

I don’t know of a way to break/override that convention at this time. ( Nor would I think you would want to do that. More on that next. )

 

MHO:

                In general, names matter. And normally a lot more than you want them to when something “changes” later that was not expected.

 

                If the AD group is moved (and supported to be moved ) then the “source group” (aka: in grouper) needs to be moved to get the AD group moved.

                That implies that both AD OU’s are modeled in grouper and the user moving the group has enough privs to both folders in grouper and the group in question.

 

                However, that may still break things using “AD groups” because the application using the group is what really matters.

                                The app may or may not be:

                                                DN based,

                                                “CN” based,

                                                                or

                                                GUID based (“happy path”?) .

 

                And the likely hood that all applications behave the same way… just about zero IMHO.

 

 

As I am standing up Grouper to manage AD groups (at the moment).I have negotiated a single OU for grouper to place and manage groups in our AD. ( Yes there is an OU structure in that OU, but that is all under grouper’s control. ) So the idea of moving from one grouper folder to another would be a logical move under the umbrella OU that grouper controls. ( And subject to all of the chaos that might happen in the applications. But I think a move inside the same PSPNG config would actually “move” the group and maintain the GUID. But I am not sure if that would work across PSPNG configs. [ How would they know they are the same “AD” to do a “move of the group”?  ?? ] )

                And FWIW: I am truncating the grouper stem names and letting the groupCreationBaseDn drive the rest of the parent OU structure in my single PSPNG config/setup.

                // not the exact config values

                … .groupCreationBaseDn = OU=GROUPER,DC=XXX,DC=XXX,DC=XXX,DC=XXX,DC=XXX

                … .groupCreationLdifTemplate = dn: ${utils.bushyDn(group.name.replaceFirst("grouper:folders:to:ignore:",""),"cn", "ou")}||cn: ${group.getExtension()}||objectclass: group||objectclass: top

 

 

On the other hand:

                Grouper can have a nested group across those “AD folders”( in grouper) too. So the need to “move” is not really useful unless the application(s) are GUID based. And when you are talking about logical moves across existing organizational boundaries (AKA: Not an org rename, but a actually “let them do this from now on” condition.) then is seems like changing everything in AD (OU, group name, and GUID) would be wise IMHO. And easily done in the short term by including the original grouper group in to the (new) target AD group while the new group (maybe with some “expires membership in 60 days”) takes over payments on managing the memberships in a different contributing sub group.

 

 

Now if you could get your AD team to let you map to the grouper folder to the root OU in AD, then you can reproduce/model all OU’s in the AD. ( But good luck taking that on too. :) )

                Though to be fair, the grouper integration does not need to have write access to the whole AD tree. You may just need to mock in the OU’s and then not let grouper users write to all of them. :) Open up the terminal folders (AKA: OU’s) where grouper can write to AD as appropriate. But I have not tried that approach. Nor do I think it is really any better than the “single OU for grouper” model that I am starting with. Just more complexity and empty folders in grouper IMHO.

 

 

YMMV. Good luck.  I look forward to the wisdom from the rest of the user community on this topic too. ( Maybe I have completely missed some options/designs? )

 

--

Carey Matthew

 

From: <> On Behalf Of Crawford, Jeffrey
Sent: Monday, June 10, 2019 11:59 AM
To: Grouper Users <>
Subject: [grouper-users] pspng and naming for reorgs

 

Morning,

 

Apologies for the Monday morning thought exercise, I’ll try and keep this as short as I can but it’s a complicated subject in my mind.

 

When looking at the Grouper TIER Deployment Guide, good work by the way, I’m left with the conundrum of the Grouper org structure of the groups vs what you want to provision downstream generically. This is specially relevant to us as we are very likely going to be going through a reorg once we hire a CIO type of position. So how can I make an LDAP export rule that applies to applications when that application may change hands. This includes some level of delegation to a department so we are not always in the loop for setting up new services which is what we want.

 

From what I gather the deployment guide would imply we create a vpn group like the following, if we include the major org and any number of suborg folders:

org:itservice:networking:app:vpn:entitlement:eligible

 

We want to provision that to our LDAP but in a way that vpn app might be moved to:

org:itservice:centralaccess:app:vpn:entitlement:eligible

 

On it’s surface you can take away everything up to and including “app” which then leaves you with “vpn:entitlement:eligible” but now imagine you also have:

org:med:it:app:vpn:entitlement:eligible

 

The PSPNG rule would result in the same exact string of “vpn:entitlement:eligible”, So I went back and figured I would also include the first folder after the org and then remove everything to the last “app” string. It would seem the first level org structure would rarely change, but that’s not a guarantee. If they change orgs to this level we may need to be involved as the Grouper service team. Therefore this gives me a regex process and results of:

 

# replaceAll("^org:([^:]+).*:app:(.*)$"), "$1:$2")

org:itservices:networking:app:vpn:entitlement:eligible -> itservices:vpn:entitlement:eligible

org:med:it:app:vpn:entitlement:eligible -> med:vpn:entitlement:eligible

 

The above solution isn’t perfect, you can still have cases where for example someone sets up

org:itservice:networking:app:vpn:entitlement:eligible

org:itservice:networking:datacenter:app:vpn:entitlement:eligible

 

and your right back where you started. Now I hope someone would actually create the last entry as:

org:itservice:networking:app:vpn:datacenter:entitlement:eligible

 

As that would be in line with what the application is doing (datacenter vpn vs generic campus vpn). We can have some structure by perhaps only delegating out from the second folder after the first level org so we would have to be involved with any large level org changes. But we can’t prevent people from creating a bad naming structure  (Some of this is of course education).

 

Of course you could make lots of psp_ng configs in the grouper-loader.properties and assign them individually we’ve done that to some degree. We already have 21 , however I’m looking for something cleaner and I’m not sure what kind of impact having 100’s of psp_ng configs in the loader could be. However this also means we’ll need to be involved with any changes as we will likely need to change some string in the psp_ng config anyway if an app is moved.

 

I’m looking for two things out of this email. Those of you who have given thought to this and implemented something, and to start the conversation of decupling application data from Org structure.

 

Jeffrey C.