Grouper Users - Open Discussion List

["Black, Carey M." <>]

Chris,

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 

From:  
<> On Behalf Of Hyzer, Chris
Sent: Wednesday, July 31, 2019 10:04 AM
To: Black, Carey M. <>; Jeffrey Williams <>
Cc: 
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?

Thanks
Chris

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

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(http://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