Skip to Content.
Sympa Menu

grouper-users - [grouper-users] Migrating bushy layout from PSP to PSPNG - extraneous OU/stem

Subject: Grouper Users - Open Discussion List

List archive

[grouper-users] Migrating bushy layout from PSP to PSPNG - extraneous OU/stem

Chronological Thread 
  • From: "Pete St. Onge" <>
  • To: "" <>
  • Subject: [grouper-users] Migrating bushy layout from PSP to PSPNG - extraneous OU/stem
  • Date: Fri, 19 Jul 2019 15:57:07 -0400

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


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

groups and folders below the d: stem in Grouper get provisioned below


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


In our existing PSPNG in 2.4.0, however, that same group would get provisioned as


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

Archive powered by MHonArc 2.6.19.

Top of Page