Skip to Content.
Sympa Menu

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

Subject: Grouper Users - Open Discussion List

List archive

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


Chronological Thread 
  • From: Jeffrey Williams <>
  • To: "Pete St. Onge" <>
  • Cc: "" <>
  • Subject: Re: [grouper-users] Migrating bushy layout from PSP to PSPNG - extraneous OU/stem
  • Date: Fri, 19 Jul 2019 16:14:32 -0400

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


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





Archive powered by MHonArc 2.6.19.

Top of Page