Skip to Content.
Sympa Menu

grouper-users - Re: [grouper-users] Grouper

Subject: Grouper Users - Open Discussion List

List archive

Re: [grouper-users] Grouper


Chronological Thread 
  • From: "Crawford, Jeffrey" <>
  • To: "" <>
  • Cc: "" <>
  • Subject: Re: [grouper-users] Grouper
  • Date: Thu, 14 Mar 2019 19:25:12 +0000

ou:dn:=xxx is an extensibleMatch search. Are you defining that in the template? Also is this AD. I’ve seen issues with extensibleMatch searches there before.

 

Jeffrey

 

From: Andre Daniels <>
Reply-To: "" <>
Date: Wednesday, February 27, 2019 at 12:55 AM
To: "Crawford, Jeffrey" <>
Cc: "" <>, "" <>
Subject: Re: [grouper-users] Grouper

 

Sorry it tooks so long to get back to you all on this. I have tried all three of the suggested methods and they all suffice in their own way. I would still like to know what this error means. Using Extensible matching would be the cleanest approach for us without altering schema. It seems to work for provisioning right away but I have found that later some as-of-yet unidentified job throws this:

 

2019-02-26 21:52:08,159: [DefaultQuartzScheduler_Worker-4] ERROR LdapObject.matchesLdapFilter(279) -  - Problem checking ldap filter in memory: [org.ldaptive.SearchFilter@-1233342575::filter=(&(objectclass=groupOfNames)(cn=active)(ou:dn:=acl)(ou:dn:=dcvpn)(ou:dn:=its)), parameters={}]

LDAPException(resultCode=92 (not supported), errorMessage='Extensible matching is not supported when attempting to determine whether a given entry matches a search filter.')

at com.unboundid.ldap.sdk.Filter.matchesEntry(Filter.java:3287)

at com.unboundid.ldap.sdk.Filter.matchesEntry(Filter.java:3187)

at com.unboundid.ldap.sdk.Filter.matchesEntry(Filter.java:3152)

at edu.internet2.middleware.grouper.pspng.LdapObject.matchesLdapFilter(LdapObject.java:275)

at edu.internet2.middleware.grouper.pspng.LdapGroupProvisioner.fetchTargetSystemGroups(LdapGroupProvisioner.java:499)

at edu.internet2.middleware.grouper.pspng.Provisioner.fetchTargetSystemGroupsInBatches(Provisioner.java:866)

at edu.internet2.middleware.grouper.pspng.Provisioner.prepareGroupCache(Provisioner.java:825)

at edu.internet2.middleware.grouper.pspng.Provisioner.startProvisioningBatch(Provisioner.java:553)

at edu.internet2.middleware.grouper.pspng.Provisioner.provisionBatchOfItems(Provisioner.java:1657)

at edu.internet2.middleware.grouper.pspng.PspChangelogConsumerShim.processChangeLogEntries(PspChangelogConsumerShim.java:71)

at edu.internet2.middleware.grouper.changeLog.ChangeLogHelper.processRecords(ChangeLogHelper.java:245)

at edu.internet2.middleware.grouper.app.loader.GrouperLoaderType$5.runJob(GrouperLoaderType.java:638)

at edu.internet2.middleware.grouper.app.loader.GrouperLoaderJob.runJob(GrouperLoaderJob.java:465)

at edu.internet2.middleware.grouper.app.loader.GrouperLoaderJob.execute(GrouperLoaderJob.java:345)

at org.quartz.core.JobRunShell.run(JobRunShell.java:202)

at org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:573)

 

 

Thanks

Andre

 

On Wed, Jan 30, 2019 at 8:30 AM Crawford, Jeffrey <> wrote:

Hi Andre,

 

So are you trying to create a provisioner and keep the group list flat? But have a distinct provisioner for different folders in the structure? In that case, when you are creating the changelog entries i.e. a provisioning point like pspsng_GroupA as “changelog.consumer.pspng_GroupA…” and then apply the etc:pspng:provision_to attribute with the value pspng_GroupA to structure in grouper were you want it to start provisioning.

 

Then add the a second provisioner entry for pspng_GroupB like above and apply the provision_to attribute to the other folder in the grouper org. Then each of the changelog.consumer.pspng_GroupA.groupSearchBaseDN = ou=groupa,ou=groups,… and changelog.consumer.pspng_GroupA.groupSearchBaseDN = ou=groupb,ou=groups,… We assume the other configuration points would otherwise be the same between the GroupA and GroupB loader definitions.

 

As an example of how to apply the attributes in a grouper shell, (not sure we should be attaching images here for how to do this on the ui) would look something like:

grouperSession = GrouperSession.startRootSession();

attributeDefName = AttributeDefNameFinder.findByName("etc:pspng:provision_to", true);

stem = StemFinder.findByName(grouperSession, "path:to:GroupA");

stem.getAttributeDelegate().assignAttribute(attributeDefName);

stem.getAttributeValueDelegate().assignValueString(attributeDefName.getName(), "pspng_GroupA");

stem = StemFinder.findByName(grouperSession, "path:to:GroupB");

stem.getAttributeDelegate().removeAttribute(attributeDefName);

stem.getAttributeDelegate().assignAttribute(attributeDefName);

stem.getAttributeValueDelegate().assignValueString(attributeDefName.getName(), "pspng_GroupB");

 

Jeffrey C.

 

From: <> on behalf of Andre Daniels <>
Reply-To: "" <>
Date: Friday, January 25, 2019 at 5:48 PM
To: "" <>
Subject: [grouper-users] Grouper

 

Hello,

 

I am a not sure how to best configure pspng to provision to an ldap ou that has a folder-like hierarchy and groups with similar names. The groupSearchBaseDn does not appear to accept a jexl _expression_, so how does one prevent name collision? If I set the baseDn to allGroups, how does the provisioner determine whether a given update is for the allGroups:groupA:admins or allGroups:groupB:admins?

 

Thanks,

Andre

 

--

Andre Daniels 

Sr. Developer/Security Analyst

University of California Santa Cruz

(831) 459-1980


 

--

Andre Daniels 

Sr. Developer/Security Analyst

University of California Santa Cruz

(831) 459-1980



  • Re: [grouper-users] Grouper, Crawford, Jeffrey, 03/14/2019

Archive powered by MHonArc 2.6.19.

Top of Page