Grouper Users - Open Discussion List

["Pete St. Onge" <>]

Hi Jeff,

Many thanks for this, much appreciated.

Based on your advice, I was able to use

changeLog.consumer.pspng_groupOfNames.groupCreationLdifTemplate = dn: 
${utils.bushyDn(group.name.replaceFirst("d:",""), "cn","ou")}||cn: 
${grouperUtil.extensionFromName(name)}||objectclass: groupOfNames

to get rid of the extraneous stem name. So far this appears to be 
working famously, thank you very much!

I'm still coming up to speed with how provisioning and attributes work; 
I've been manually setting the etc:pspng:provision_to attribute up on 
the stems and groups below the 'd:' stem, but will likely need to figure 
out a different way when we migrate out 2.2.x data into current Grouper.

Again, thank you very much!

Thanks and Best, -- pete

On 2019-07-19 4:14 p.m., Jeffrey Williams wrote:
> Hi Pete,
>
> If I understand correctly, I think there was a similar discussion 
> earlier.  Carey Black from OSU pointed out that there's a replaceFirst 
> function that could be used in the ldif creation template to edit out 
> the d: folder in provisioning.
>
>     groupCreationLdifTemplate = dn: ${utils.bushyDn(group.name
>     <http://group.name>.replaceFirst("grouper:folders:to:ignore:",""),  ....
>
>
> There may be other ways to tackle it, but I think this should work for you.
>
> -Jeff
>
> On Fri, Jul 19, 2019 at 4:00 PM Pete St. Onge < 
> <>> wrote:
>
>     :sigh: Error in original email config, fixed below. Apologies. The
>     perils of writing emails late in the day...
>
>     On 2019-07-19 3:57 p.m., Pete St. Onge wrote:
>      > In my initial web searches thus far, I haven't found a solution
>     to our
>      > migration from PSP to PSPNG as we migrate from an earlier version of
>      > Grouper to the current 2.4.x release.
>      >
>      > We have an existing Grouper instance provisioning some 10K groups
>     (of a
>      > total 20K or so groups) to an OpenLDAP service in a 'bushy'
>     layout. The
>      > provisioned groups are in one part of the Grouper tree,
>     everything else
>      > in the tree does not get provisioned.
>      >
>      > In our OpenLDAP service, we provision to a given OU --
>      >
>      > ou=grouper,dc=a,dc=b,dc=ca
>      >
>      > We have a stem in the root folder in Grouper (let's call it "d") for
>      > which any folder / group which falls in this area gets provisioned --
>      >
>      > ldap.properties:edu.internet2.middleware.psp.baseStem=d
>      >
>      > groups and folders below the d: stem in Grouper get provisioned below
>      >
>      > ou=grouper,dc=a,dc=b,dc=ca
>      >
>      > but d: itself does not get provisioned.
>      >
>      > So a group in the 'd:' stem, say 'd:sample-group' in grouper,
>     would get
>      > provisioned in LDAP as
>      >
>      > cn=sample-group,ou=grouper,dc=a,dc=b,dc=ca
>      >
>      >
>      > In our existing PSPNG in 2.4.0, however, that same group would get
>      > provisioned as
>      >
>      > cn=sample-group,ou=d,ou=grouper,dc=a,dc=b,dc=ca
>      >
>      > our configuration thus far is
>      >
>      > ('q', 'userid', and 'internalid' are renames of internal attributes)
>      >
>      > changeLog.consumer.pspng_groupOfNames.class =
>      > edu.internet2.middleware.grouper.pspng.PspChangelogConsumerShim
>      > changeLog.consumer.pspng_groupOfNames.type =
>      > edu.internet2.middleware.grouper.pspng.LdapGroupProvisioner
>      > changeLog.consumer.pspng_groupOfNames.quartzCron = 0 * * * * ?
>      > changeLog.consumer.pspng_groupOfNames.ldapPoolName = q
>      > changeLog.consumer.pspng_groupOfNames.supportsEmptyGroups = false
>      > changeLog.consumer.pspng_groupOfNames.memberAttributeName = member
>      > changeLog.consumer.pspng_groupOfNames.memberAttributeValueFormat =
>      > ${ldapUser.getDn()}
>      > changeLog.consumer.pspng_groupOfNames.groupSearchBaseDn =
>      > ou=grouper,dc=a,dc=b,dc=ca
>      > changeLog.consumer.pspng_groupOfNames.allGroupsSearchFilter =
>      > objectclass=groupOfNames
>      > changeLog.consumer.pspng_groupOfNames.singleGroupSearchFilter =
>      >
>     (&(objectclass=groupOfNames)(cn=${grouperUtil.extensionFromName(name)}))
>      > changeLog.consumer.pspng_groupOfNames.groupSearchAttributes =
>      > cn,objectclass
>      > changeLog.consumer.pspng_groupOfNames.groupCreationLdifTemplate =
>     dn:
>      > cn=${group.name <http://group.name>}||cn: ${group.name
>     <http://group.name>}||objectclass: groupOfNames
>      > changeLog.consumer.pspng_groupOfNames.userSearchBaseDn =
>      > dc=able,dc=utoronto,dc=ca
>      > changeLog.consumer.pspng_groupOfNames.userSearchFilter =
>      > utorid=${subject.id <http://subject.id>}
>      > changeLog.consumer.pspng_groupOfNames.userSearchAttributes =
>      > dn,cn,userid,mail,internalid,objectclass
>      > changeLog.consumer.pspng_groupOfNames.groupCreationLdifTemplate =
>     dn:
>      > cn=${group.name <http://group.name>},${utils.bushyDn(group.name
>     <http://group.name>, "cn", "ou")}
>      > changeLog.consumer.pspng_groupOfNames.grouperIsAuthoritative = true
>      >
>      >
>      > Unfortunately, moving forward with this change as-is would affect
>     some
>      > 10K groups and break some 60 applications in production.
>      >
>      > The previous behaviour is necessary for the upgrade to be put into
>      > production using PSPNG, which is to say we need to figure out how to
>      > remove the extraneous base stem (d:, ou=d) from the provisioning.
>      >
>      > (I should mention that we intend to have our provisioning into
>     AD  be
>      > into a flat namespace, as per previous discussions on this list).
>      >
>      > Ideas, suggestions, tofu recipes, etc all welcome.
>      >
>      > Thanks in advance, -- pete
>      >
>
>
>     -- 
>     Peter St. Onge  <>
>     Information Security Architect                     (416)978-5030
>     Business Continuity and Communications
>     Information + Technology Services          University of Toronto
>
>
>
> --
> Jeffrey Williams
> Identity Engineer
> Identity & Access Services
> https://its.uncg.edu


--
Peter St. Onge                           
Information Security Architect                     (416)978-5030
Business Continuity and Communications
Information + Technology Services          University of Toronto