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: "Peter St. Onge" <>
  • To: "Bryan E. Wooten" <>, "" <>
  • Subject: Re: [grouper-users] Weirdness when provisioning to LDAP
  • Date: Wed, 02 Apr 2014 09:11:02 -0400

Thanks, Bryan - Am looking carefully into it. If you wouldn't mind
sending your config files my way, I'd really appreciate it.

Thanks and best, -- pete

On 14-04-01 06:01 PM, Bryan E. Wooten wrote:
> 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
>>
>


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

Top of Page