Grouper Users - Open Discussion List

[Jeffrey Williams <>]

On Wed, Jul 31, 2019 at 3:16 PM Black, Carey M. <> wrote:

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”.

samAccountName should go up to 256 characters since at least Win2k, so you ought to be good there for the most part.   

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.

 

I've ran into this same constraint as well about samAccountName = cn = name from our Windows Engineers. I played around with the idea of UUID as samAccountName and got grief from our AD Admin over it.  Enough that I moved away from trying to use it to key off of and over to gidNumber, leaving samAccountName to ${group.extension} and happier AD Admins as a result.

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. )

 

The closest thing that a default AD schema is going to have to store an external reference id for groups is probably going to be gidNumber.  Anything else seemed to be a shoehorn attempt that won't make sense to AD engineers.  

There are a number of good things about using gidNumber in this event. Including:

1.  Providing consistency on how to reference groups across multiple directory systems, so when other operators run into issues, there's a common configuration for AD, 389DS, and openLDAP users to start from.
2. AD by default leaves this as null, so there's no chance of id collision in a vanilla AD environment caused by AD itself.
3. Requires no change to PSPNG code or behavior to implement.  gidNumber is already implemented in Grouper.  It's doing what you need today. :)
4. Allows Grouper to be authoritative in the sub-OU it's given without being concerned about objects outside of it's searchBaseDN.

Did the AD Admin's have an issue with you using gidNumber in this instance?

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".....

If Grouper is not generating the value that is used to uniquely identify the groups it maintains, it cannot said to be authoritative for said groups. Much like my caching DNS server at home cannot be authoritative for Google just because it knows the IP address.

I agree that using samAccountName as a search attribute should be avoided because it's domain-scoped and has odd dependencies and behaviors(in fact, I'd just set it to ${group.extension} to make your AD admins happy and leave it out of your search string entirely).  However, I think having Grouper defer its search criteria to downstream systems is problematic for at least a couple of reasons.

1. If you're using multiple provisioners to sync a group across multiple directories, you would have multiple objectGUID's(or their equivalent) for each directory.
2. For each group provisioned, PSPNG would have to 1) provision the group, 2) turn around and query AD again using a different set of search criteria to get the objectGUID, most likely DN. 3) store the objectGUID in a new table alongside the group's UUID and the provisioner it's associated with. Whee!  gidNumber accomplishes the same thing without steps 2 and 3.
3. objectGUID is scoped for the entire domain and is really intended for internal use only.

Active Directory really doesn't have an externally-facing unique identifier that's pre-populated.  Again, the closest thing I've found is gidNumber, for which Grouper generates ID index as a compatible value to use.

While it's understood that directory systems should be authoritative, it doesn't mean that upstream systems have to use their GUIDs.  In fact, directory systems should be robust enough in their schema to allow applications with sufficient access and namespace(or sub-OU) in the directory to be authoritative for the namespace given without having to resort to internal GUIDs that are frankly out-of-scope.  

--
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: mailto: <mailto:> On Behalf Of Black, Carey M.
Sent: Sunday, July 28, 2019 11:02 PM
To: Jeffrey Williams <mailto:>
Cc: mailto:
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 mailto:

From: Jeffrey Williams <mailto:>
Sent: Saturday, July 27, 2019 11:27 AM
To: Black, Carey M. <mailto:>
Cc: mailto:
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 <mailto:> 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. <mailto:> 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 mailto:



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





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

--

Jeffrey Williams 

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