Skip to Content.
Sympa Menu

grouper-users - RE: [grouper-users] PSPNG Group rename events....

Subject: Grouper Users - Open Discussion List

List archive

RE: [grouper-users] PSPNG Group rename events....

Chronological Thread 
  • From: "Black, Carey M." <>
  • To: "Hyzer, Chris" <>, Jeffrey Williams <>
  • Cc: "" <>
  • Subject: RE: [grouper-users] PSPNG Group rename events....
  • Date: Wed, 31 Jul 2019 19:16:01 +0000
  • Arc-authentication-results: i=1; 1;spf=pass;dmarc=pass action=none;dkim=pass;arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed;; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Ohv8lZcQq5bP78ZahDNcX5uksdK+vzH9CQ7iCwe5a88=; b=CLjlN29xGi9fu6RIw0YG/wpBuD5pzkf/BcFzG0rrLd97A+HYJW2fqn6kWb3zddZtuMSpcudVCYU9big4NsnWcjpRihGxZObrNMFVdLSs6k+K82aMsD19D8AIsvOPngTten8UmAbYDiJw/Lvh8rs6Vc/2brKcgQ7NoZO/8aNROTL8BRitIlqlQtytshV+++L9Ye7CJ4Vzg6lBNHGbk1Hjc56mtOScjOE9iO+R00K/Zfe6TBmGTpVTo3o4pJXFh7YAt8WseIdFG/xdt7uLiQDpeAFHh1KQmmscEHzzgVkRSbfqpQi2S9RptOwSVSpnvLu7n8w3Y5KmERCifw33olVe1g==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901;; cv=none; b=gZW2cjXQfAtLy9sgAOkPmIIbZpkHyGPQ4UWVjmX22WfI1WFxXIRUzF1PNCoxsZ43l1uTclbJUOrvaqtnNqihd7PiX7b8mtO9VPYIJrFXZ6I1Ik6GZ9L2NThu4vuMoonGUL9oCj5yhFxtpx0ZiWwEA85rlWfX2fHj6aiFiTNPtCk6VzC0p9T1pcZKdg5SMsDXZl06IqAbQ4e+1T9RriC0EPg3mFwQjbuQNccSCt8k7KXrW9w9Jj9va6Re16XLPWOeZ5nvwIuEPBLLI7Rpb4azPQicOXF7MWd9kTdjoFQGbzMMluj7mEG4NV8dtO012A6EOrvOVFXDsIrN5dvzEnUk0g==


Unfortunately, my local AD wants samaccountname=cn (well as much as will fit
into samaccountname) to always be true.
And the samaccountname to be an “English name for the group”.

Some grumbling about Powershell still uses the samaccountname by default to
“name” the group.. or something like that.
And there are other "naming constraints" too.

However, if there was some other attribute that I could stuff the grouper
UUID into that could work. ( very much the POSIX group ID pattern, just a
different value)
I would have to ask if they have, or would be willing to add, one. (
Adding attributes may be out of the question for some orgs. )

Also, IMHO,
Grouper should hold the external reference because it has a "lower
burden on the connected system" and Grouper can be "authoritative" for the
value it holds. :) AKA: Connected System admins can't remove/change the
value because "that looks like junk".....

Carey Matthew

<> On Behalf Of Hyzer, Chris
Sent: Wednesday, July 31, 2019 10:04 AM
To: Black, Carey M. <>; Jeffrey Williams <>
Subject: RE: [grouper-users] PSPNG Group rename events....

Cant pspng set the grouper group uuid to samaccountname and lookup by that?

I don’t think you can move or rename the AD group since grouper is the system
of record and specifies the location of the group and could create a new one
where it should be and delete the old to get the samaccountname?


<> On Behalf Of Black, Carey M.
Sent: Sunday, July 28, 2019 11:02 PM
To: Jeffrey Williams <>
Subject: RE: [grouper-users] PSPNG Group rename events....


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

                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
                So PSPNG seems fragile (under some data change conditions
that break the matching rules) to me.


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. <>
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 <>
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 =
changeLog.consumer.pspng_campusBushyLdap.groupCreationLdifTemplate =

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.


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

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

Jeffrey Williams 
Identity Engineer
Identity & Access Services

Archive powered by MHonArc 2.6.19.

Top of Page