Skip to Content.
Sympa Menu

grouper-users - Re: [grouper-users] Weirdness when provisioning to LDAP

Subject: Grouper Users - Open Discussion List

List archive

Re: [grouper-users] Weirdness when provisioning to LDAP


Chronological Thread 
  • From: "Bryan E. Wooten" <>
  • To: "Peter St. Onge" <>, "" <>
  • Subject: Re: [grouper-users] Weirdness when provisioning to LDAP
  • Date: Tue, 1 Apr 2014 22:01:19 +0000
  • Accept-language: en-US

I may be off base here, but perhaps there is a problem between Subject_ID
(your fooid ? in sources) vs. Subject_Identifier (perhaps used to add
members to your Grouper group?

I would look carefully at your grouper_error.log and the requests being
sent to your LDAP server. Check for the DNs on both ends.

I use OpenDJ for my sources and provision to Active Directory via PSP. I'd
be happy to share my config files. Note that I use Subject_ID in both
sources and AD / PSP provisioning.

-Bryan

On 4/1/14 3:36 PM, "Peter St. Onge"
<>
wrote:

>[Eeps - Sorry for the resend, search & replace didn't quite work as well
>as I'd expected. Best, -- p]
>
>Thanks for this, much appreciated. The server is current OpenLDAP in
>Ubuntu, running in a VM. There is one instance of the grouper loader
>running when I call it, so there shouldn't be more than one provisioning
>job.
>
>The active parts of ldap.properties are as follows
>
>edu.vt.middleware.ldap.ldapUrl=ldap://127.0.0.1:389
>edu.vt.middleware.ldap.searchScope=SUBTREE
>edu.vt.middleware.ldap.baseDn=dc=fqdn
>edu.vt.middleware.ldap.bindDn=cn=admin,dc=fqdn
>edu.vt.middleware.ldap.bindCredential=grouper
>edu.vt.middleware.ldap.authtype=simple
>edu.vt.middleware.ldap.ssl=false
>edu.vt.middleware.ldap.tls=false
>edu.vt.middleware.ldap.pool.minPoolSize = 2
>edu.vt.middleware.ldap.pool.maxPoolSize = 5
>edu.vt.middleware.ldap.pagedResultsSize=0
>edu.vt.middleware.ldap.searchResultHandlers=edu.internet2.middleware.psp.l
>dap.QuotedDnResultHandler,edu.vt.middleware.ldap.handler.FqdnSearchResultH
>andler
>edu.internet2.middleware.psp.groupObjectClass=groupOfNames
>edu.internet2.middleware.psp.groupsBaseDn=ou=fooroot,ou=grouper,dc=fqdn
>edu.internet2.middleware.psp.peopleBaseDn=dc=fqdn
>edu.internet2.middleware.psp.structure=bushy
>edu.internet2.middleware.psp.cnSourceAttributeID=extension
>edu.internet2.middleware.psp.baseStem=fooroot
>
>As you might infer, the individual user accounts live in the top level
>of the directory (directly under dc=fqdn); so I should probably chance
>the search scope to ONELEVEL...
>
> <source
>adapterClass="edu.internet2.middleware.grouper.subj.GrouperJndiSourceAdapt
>er">
> <id>ldap</id>
> <name>LDAP Source Adapter</name>
> <type>person</type>
> <init-param>
> <param-name>INITIAL_CONTEXT_FACTORY</param-name>
> <param-value>com.sun.jndi.ldap.LdapCtxFactory</param-value>
> </init-param>
> <init-param>
> <param-name>PROVIDER_URL</param-name>
> <param-value>ldap://localhost:389</param-value>
> </init-param>
> <init-param>
> <param-name>SECURITY_AUTHENTICATION</param-name>
> <param-value>simple</param-value>
> </init-param>
> <init-param>
> <param-name>SECURITY_PRINCIPAL</param-name>
> <param-value>cn=admin,dc=fqdn</param-value>
> </init-param>
> <init-param>
> <param-name>SECURITY_CREDENTIALS</param-name>
> <param-value>grouper</param-value>
> </init-param>
> <init-param>
> <param-name>SubjectID_AttributeType</param-name>
> <param-value>fooid</param-value>
> </init-param>
> <init-param>
> <param-name>Name_AttributeType</param-name>
> <param-value>cn</param-value>
> </init-param>
> <init-param>
> <param-name>Description_AttributeType</param-name>
> <param-value>foostarid</param-value>
> </init-param>
> <!-- added per
>https://lists.internet2.edu/sympa/arc/grouper-users/2012-03/msg00046.html
>-->
> <init-param>
> <param-name>SubjectID_formatToLowerCase</param-name>
> <param-value>false</param-value>
> </init-param>
>
>fooid is the large number (numeric only, doesn't change when user
>changes names etc); foostarid is the user name they use when they log
>into different services, it is generally fixed but there are situations
>where it changes (marriage, etc).
>
>One more thing: This LDAP server has the memberof and refint overlays
>installed, and I'm using the config pattern from
>psp-example-grouper-to-openldap-memberof-overlay.
>
>If it helps, I'm also running the LDAP server on the same host, and can
>provide logs from there as well. Speaking of which, this stands out:
>
>533b0c74 conn=1083 op=6 SRCH base="utid=100000042,dc=fqdn" scope=0
>deref=3 filter="(objectClass=eduMember)"
>533b0c74 conn=1083 op=6 SRCH attr=objectclass objectClass
>
>If I recall correctly, eduMember should apply to groups (an individual
>should be an eduPerson), so I would assume this is a search against a
>group, rather than for an individual?
>
>Hmm. Apparently not:
>
>dn: fooid=100000588,dc=fqdn
>fooid: 100000588
>givenName: Alice
>sn: Windego
>cn: Alice Windego
>foostarid: windegoa
>objectClass: FOOentry
>objectClass: eduMember <-- This gets added by Grouper
>isstaff: FALSE
>isfaculty: FALSE
>isstudent: TRUE
>isregistered: TRUE
>isgrad: FALSE
>isother: FALSE
>isapplicant: FALSE
>issessional: FALSE
>isundergrad: FALSE
>ispostdoc: FALSE
>isinvited: FALSE
>islms: FALSE
>isstatusonly: FALSE
>isadjunct: FALSE
>isfulltime: FALSE
>isuntrusted: FALSE
>email:
>
>structuralObjectClass: FOOentry
>entryUUID: 209380aa-4b16-1033-9455-d9af0198ab27
>creatorsName: cn=admin,dc=fqdn
>createTimestamp: 20140328224329Z
>isMemberOf: fooroot:frank:isea <- This too is added by Grouper
>entryCSN: 20140401201600.670866Z#000000#000#000000
>modifiersName: cn=admin,dc=fqdn
>modifyTimestamp: 20140401201600Z
>
>So the Grouper stem is being added to the user record, but shouldn't
>that be the DN for group?
>
>Thanks, -- pete
>
>
>On 14-04-01 03:27 PM, David Langenberg wrote:
>> On the surface, it looks like you may have some inconsistencies between
>> sources.xml and ldap.properties. As for the mysteriously vanishing
>> entries, what kind of LDAP server is this & are there any other
>> provisioning jobs outside of the grouper-PSP which could be trying to
>> maintain the OU you're putting groups into?
>>
>> Dave
>>
>> On Tue, Apr 1, 2014 at 1:17 PM, Peter St. Onge
>><>wrote:
>>
>>> I've been experimenting with Grouper locally and have become somewhat
>>> stymied with provisioning.
>>>
>>> I'm using a local LDAP as my subject source; it's also where I want
>>> Grouper to provision groups to. I can search for any of my attributes
>>> of interest from the command line, as well as in the web UI, and get
>>> back the results I expect to see...
>>>
>>> gsh 0% GrouperSession.startRootSession()
>>> edu.internet2.middleware.grouper.GrouperSession:
>>> 4ee55c98f5794f08891734319cf30a8d,'GrouperSystem','application'
>>> gsh 1% subj = SubjectFinder.findByIdOrIdentifier("hermesal", false)
>>> subject: id='100000168' type='person' source='ldap' name='Alice Hermes'
>>> [Not a real person; the users in this LDAP were generated]
>>>
>>> The Grouper loader is able to write new folders into LDAP without
>>> problem, as well with the empty groups, although I do find this in the
>>> API's grouper_error.log:
>>>
>>> 2014-04-01 14:36:13,572: [DefaultQuartzScheduler_Worker-1] WARN
>>> Psp.getAllSourceIdentifiers(1584) - - PSP 'psp' - Unable to resolve
>>> attribute 'groupNames'
>>> 2014-04-01 14:36:13,572: [DefaultQuartzScheduler_Worker-1] WARN
>>> Psp.getAllSourceIdentifiers(1584) - - PSP 'psp' - Unable to resolve
>>> attribute 'memberSubjectIds'
>>>
>>>
>>> When I try to provision users into groups, the resulting group looks
>>> like this:
>>>
>>> dn: cn=tg1,ou=fooroot,ou=grouper,dc=fqdn
>>> objectClass: eduMember
>>> objectClass: groupOfNames
>>> objectClass: top
>>> description: Test Group 1
>>> member:
>>> cn: tg1
>>> structuralObjectClass: groupOfNames
>>> hasMember: Alice Deeds
>>>
>>> A peculiarity a couple of us here have noticed is that when stored as
>>> 'groupOfNames' the entries seem to disappear after a short amount of
>>> time...
>>>
>>> Some caveats - using the above result, our dn's are of this form:
>>>
>>> dn: fooid=100000168,dc=fqdn
>>>
>>> The fooid is defined in the institutional LDAP schema, and is used
>>> internally. 'fooid' seems to be mapping correctly to the 'id'
>>>
>>> When I restart the grouper loader, I see lines like this in
>>> grouper_error.log when it tries to do the full update:
>>>
>>>
>>> 2014-04-01 15:06:02,947: [DefaultQuartzScheduler_Worker-1] INFO
>>> Psp.execute(980) - - Psp 'psp' - Calc
>>>
>>>
>>>CalcRequest[id=100000042,requestID=2014/04/01-15:06:02.947,returnData=ev
>>>erything,schemaEntityRef=SchemaEntityRef[targetID=ldap,entityName=member
>>>,isContainer=false]]
>>> 2014-04-01 15:06:02,948: [DefaultQuartzScheduler_Worker-1] INFO
>>> Psp.execute(984) - - Psp 'psp' - Calc XML:
>>> <psp:calcRequest xmlns:psp='http://grouper.internet2.edu/psp'
>>> requestID='2014/04/01-15:06:02.947' returnData='everything'>
>>> <psp:id ID='100000042'/>
>>> <psp:schemaEntity targetID='ldap' entityName='member'/>
>>> </psp:calcRequest>
>>>
>>> 2014-04-01 15:06:02,976: [DefaultQuartzScheduler_Worker-1] ERROR
>>> Psp.execute(1015) - - Psp 'psp' - Calc
>>>
>>>
>>>CalcResponse[id=100000042,status=failure,error=noSuchIdentifier,errorMes
>>>sages={Unable
>>> to calculate provisioned object.},requestID=2014/04/01-15:06:02.947]
>>> 2014-04-01 15:06:02,984: [DefaultQuartzScheduler_Worker-1] ERROR
>>> Psp.execute(1017) - - Psp 'psp' - Calc XML:
>>> <psp:calcResponse xmlns:psp='http://grouper.internet2.edu/psp'
>>> status='failure' requestID='2014/04/01-15:06:02.947'
>>> error='noSuchIdentifier'>
>>> <errorMessage>Unable to calculate provisioned object.</errorMessage>
>>> <psp:id ID='100000042'/>
>>> </psp:calcResponse>
>>>
>>> 2014-04-01 15:06:02,986: [DefaultQuartzScheduler_Worker-1] ERROR
>>> Psp.execute(1175) - - Psp 'psp' - Diff
>>>
>>>
>>>DiffResponse[id=100000042,status=failure,error=noSuchIdentifier,errorMes
>>>sages={Unable
>>> to calculate provisioned object.},requestID=2014/04/01-15:06:02.937]
>>> 2014-04-01 15:06:02,996: [DefaultQuartzScheduler_Worker-1] ERROR
>>> Psp.execute(1177) - - Psp 'psp' - Diff XML:
>>> <psp:diffResponse xmlns:psp='http://grouper.internet2.edu/psp'
>>> status='failure' requestID='2014/04/01-15:06:02.937'
>>> error='noSuchIdentifier'>
>>> <errorMessage>Unable to calculate provisioned object.</errorMessage>
>>> <psp:id ID='100000042'/>
>>> </psp:diffResponse>
>>>
>>> 2014-04-01 15:06:02,996: [DefaultQuartzScheduler_Worker-1] ERROR
>>> Psp.execute(1440) - - Psp 'psp' - Sync
>>>
>>>
>>>SyncResponse[id=100000042,status=failure,error=noSuchIdentifier,errorMes
>>>sages={Unable
>>> to calculate provisioned object.},requestID=2014/04/01-15:06:02.935]
>>> 2014-04-01 15:06:02,997: [DefaultQuartzScheduler_Worker-1] ERROR
>>> Psp.execute(1442) - - Psp 'psp' - Sync SPML:
>>> <psp:syncResponse xmlns:psp='http://grouper.internet2.edu/psp'
>>> status='failure' requestID='2014/04/01-15:06:02.935'
>>> error='noSuchIdentifier'>
>>> <errorMessage>Unable to calculate provisioned object.</errorMessage>
>>> <psp:id ID='100000042'/>
>>> </psp:syncResponse>
>>>
>>> 2014-04-01 15:06:03,000: [DefaultQuartzScheduler_Worker-1] ERROR
>>> Psp.execute(811) - - Psp 'psp' - BulkSync
>>>
>>>
>>>BulkSyncResponse[id=<null>,status=failure,error=<null>,errorMessages={},
>>>requestID=2014/04/01-15:06:01.574,responses=2]
>>> 2014-04-01 15:06:03,001: [DefaultQuartzScheduler_Worker-1] ERROR
>>> Psp.execute(813) - - Psp 'psp' - BulkSync SPML:
>>> <psp:bulkSyncResponse xmlns:psp='http://grouper.internet2.edu/psp'
>>> status='failure' requestID='2014/04/01-15:06:01.574'>
>>> <psp:syncResponse status='success'
>>>requestID='2014/04/01-15:06:01.845'>
>>> <psp:synchronizedResponse
>>>xmlns:psp='http://grouper.internet2.edu/psp
>>> '>
>>> <psp:psoID ID='ou=test,ou=fooroot,ou=grouper,dc=fqdn'
>>> targetID='ldap'/>
>>> </psp:synchronizedResponse>
>>> <psp:id ID='fooroot:test'/>
>>> </psp:syncResponse>
>>> <psp:syncResponse status='success'
>>>requestID='2014/04/01-15:06:02.131'>
>>> <psp:synchronizedResponse
>>>xmlns:psp='http://grouper.internet2.edu/psp
>>> '>
>>> <psp:psoID ID='cn=tg1,ou=fooroot,ou=grouper,dc=fqfdn'
>>> targetID='ldap'/>
>>> </psp:synchronizedResponse>
>>> <psp:id ID='fooroot:tg1'/>
>>> </psp:syncResponse>
>>> </psp:bulkSyncResponse>
>>>
>>> 2014-04-01 15:06:03,005: [DefaultQuartzScheduler_Worker-1] ERROR
>>> PspChangeLogConsumer.fullSync(344) - - PSP Consumer 'null' - Full sync
>>> was not successful
>>>
>>>
>>>'BulkSyncResponse[id=<null>,status=failure,error=<null>,errorMessages={}
>>>,requestID=2014/04/01-15:06:01.574,responses=2]'
>>>
>>> Any and all questions/pointers appreciated.
>>>
>>> Thanks and best, -- pete
>>>
>>> --
>>> Peter St. Onge
>>>
>>>
>>
>>
>>
>
>
>--
>Peter St. Onge
>




Archive powered by MHonArc 2.6.16.

Top of Page