Grouper Users - Open Discussion List

["Pete St. Onge" <>]

: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}||cn: ${group.name}||objectclass: groupOfNames
> changeLog.consumer.pspng_groupOfNames.userSearchBaseDn = 
> dc=able,dc=utoronto,dc=ca
> changeLog.consumer.pspng_groupOfNames.userSearchFilter = 
> utorid=${subject.id}
> changeLog.consumer.pspng_groupOfNames.userSearchAttributes = 
> dn,cn,userid,mail,internalid,objectclass
> changeLog.consumer.pspng_groupOfNames.groupCreationLdifTemplate = dn: 
> cn=${group.name},${utils.bushyDn(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