Grouper Users - Open Discussion List

["Black, Carey M." <>]

Jeffrey,

 

Thank you for the reply.

 

While I think your workaround would work, I also think that the integration technique of PSPNG should not depend on using the POSIX group id value (or some other “static value” from Grouper) to keep the integration “synced and stable”.

 

IMHO:

                PSPNG should automatically bring the AD GUID back and stuff it into a Grouper attribute. (Maybe an attribute specific to the provisioner?) That way the AD group could be moved, renamed, etc… and Grouper would still be able to find it and maintain it. ( including resetting the name/dn, etc…) AND/OR  PSPNG should know how to process a “change event” that affects an attribute that is used in the DN or CN attributes of the groupCreationLdifTemplate config value.  [ I know which of those solutions I think would be more stable and less prone to user error. :) ]

 

 

I just don’t see an option for either of those solutions in the current configs.

                So PSPNG seems fragile (under some data change conditions that break the matching rules) to me.

 

 

All,

 

Maybe there is a way to include the groups “previous name” into the search conditions? ( But I am just not clear how that could be 100% generically done. Maybe with “alternate name”, but that would only cover some group properties and not all of them. Not to mention attribute value changes….)

 

Is there any way to get PSPNG to bring attributes back (to Grouper attributes) when it creates the provisioned object?

 

--

Carey Matthew

 

From: Jeffrey Williams <>
Sent: Saturday, July 27, 2019 11:27 AM
To: Black, Carey M. <>
Cc:
Subject: Re: [grouper-users] PSPNG Group rename events....

 

Also, if this seems to work and stand up to scrutiny, I'll be happy to update the wiki as well.

 

On Sat, Jul 27, 2019 at 11:21 AM Jeffrey Williams <> wrote:

Hi Carey,

I ran into that a while back and found it to be due to using the group name(or extension) as the single group search criteria(and isAuthoritative=false).  So everytime the name changes, PSPNG can't find the new group and tries to provision a new one.  In the template I proposed in the last AD provisioning thread, I use gidNumber and objectClass to find groups(and set isAuthoritative=true).  This allows me to update group name without it creating a new group with new objectSID's.

 

changeLog.consumer.pspng_campusBushyLdap.grouperIsAuthoritative = true

changeLog.consumer.pspng_campusBushyLdap.singleGroupSearchFilter = (&(objectclass=group)(gidNumber=${idIndex}))
changeLog.consumer.pspng_campusBushyLdap.groupCreationLdifTemplate = dn:${utils.bushyDn(group.name,"CN","OU")}||objectclass:group||description:${group.description}||displayName:${group.displayName.replace(group.parentStemName.toString()+":","")}||gidNumber: ${group.idIndex}  

 

I'd love feedback on this, so let me know if you try it out.  I let DN auto-populate CN for me, but if you find you have to explicitly call it out, I use cn: ${group.extension}.  Description and displayName are optional.  Both will happily update themselves when changed(you may want to add those columns in ADUC's display in order to more easily view them).

 

Currently with this, if you change the name of a parent folder, it'll create a new folder(and substructure from that point), move your existing groups to the new structure and leave the old OU's in place and empty(I get the warning/error "folder delete not implemented" or some such).   Aside from that, I think this is at least better(if not ideal) in AD, since group memberships are objectSID-based, so you can move/rename/update groups all day and they'll maintain their membership in other groups.

 

I was able to transition to gidNumber by adding it to the ldifCreationTemplate, run a gsh container with the new template loaded and do a full-sync.  Then update your daemon containers with the template and single search criteria.  That method seemed to work for me so that I didn't upset the existing objectSID's.

 

Let me know how this works out.

 

-Jeff

 

On Fri, Jul 26, 2019 at 11:50 PM Black, Carey M. <> wrote:

All,

Experimentally, it looks like PSPNG does not rename AD groups when the Grouper name for the group is updated.  It appears to create a new group and "abandon" the old group.
        NOTE: Maybe I need to change something in the PSPNG config to avoid that behavior?
        Also The old group was not deleted. Likely because I did not set grouperIsAuthoritative=TRUE . If I had that set, I would guess, but have not verified, that the group with the "old name" might have been deleted.


I find it troubling that a new group would be created and populated  because it would not provide any way old for any application dependent on the AD group ( maybe by it's GUID ) to be able to follow the rename. Rather the observed behavior would pull the rug out from under the group and maybe leave it lay there growing stale.

Any advice from the PSPNG users out there?
Is there a way to get PSPNG to rename the existing group?

--
Carey Matthew

 

--

Jeffrey Williams 

Identity Engineer
Identity & Access Services
https://its.uncg.edu

 

 

--

Jeffrey Williams 

Identity Engineer
Identity & Access Services
https://its.uncg.edu