Grouper Users - Open Discussion List

["Peter St. Onge" <>]

[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.ldap.QuotedDnResultHandler,edu.vt.middleware.ldap.handler.FqdnSearchResultHandler
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.GrouperJndiSourceAdapter">
    <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=everything,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,errorMessages={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,errorMessages={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,errorMessages={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