Grouper Users - Open Discussion List

[Jonathan Tellier <>]

I've done some more investigations and grouper is really unable to
resolve subject information contained in my LDAP . I've manually added
a subject in my LDAP that is not also already present in the sample
DB. No matter what I do, grouper just doesn't allow me to manage it.
It's not shown in grouper's ui or anything.

My manually-created LDAP tree matches the one described in grouper's
config file, my manually-created subjects have the correct attributes
and grouper doesn't complain when accessing the LDAP. I'm using
ApacheDS as a directory. Could this be a problem?

I'm a bit confused. What seems to be not working is essentially
loading subjects from a LDAP source. There's nothing fancy here...

Thanks,
--jtellier


On Thu, Jun 7, 2012 at 1:28 PM, Jonathan Tellier 
<>
 wrote:
> Ok, well it turns out that I was not correctly calling the psp
> command. It was indeed the group that was not being found, not the
> subject. So I've got that out of the way. Now, I've got another
> problem: my group is not being populated even though the provisioning
> command completes successfully.
>
> I've made a group with 2 members that come from the sample dataset (ID
> elbe and pema). I've manually added these subjects into the LDAP. When
> I try to provision my group with "gsh.sh -psp -sync foo:qux", grouper
> always wants to delete all entries from the LDAP and never wants to
> add any. That's what I understand by looking at the logs... For
> instance, if the LDAP already contains the "pema" subject and I try to
> add "elbe", this is what I can see in the logs :
>
> 2012-06-07 16:12:32,175: [main] DEBUG
> AbstractLdap.modifyAttributes(819) -  - Modify attributes with the
> following parameters:
> 2012-06-07 16:12:32,176: [main] DEBUG
> AbstractLdap.modifyAttributes(820) -  -   dn =
> cn=qux,ou=foo,ou=groups,dc=example,dc=com
> 2012-06-07 16:12:32,182: [main] DEBUG
> AbstractLdap.modifyAttributes(821) -  -   mods = [Add attribute:
> description: qux, Remove attribute: member:
> cn=pema,ou=people,dc=example,dc=com]
> 2012-06-07 16:12:32,363: [main] ERROR LdapSpmlTarget.execute(502) -  -
> Target 'ldap' - A schema violation occurred
> javax.naming.directory.SchemaViolationException: [LDAP: error code 65
> - OBJECT_CLASS_VIOLATION: failed for MessageType : MODIFY_REQUEST
> Message ID : 4
>    Modify Request
>        Object : 'cn=qux,ou=foo,ou=groups,dc=example,dc=com'
>            Modification[0]
>                Operation :  add
>                Modification
>    description: qux
>            Modification[1]
>                Operation :  delete
>                Modification
>    member: cn=pema,ou=people,dc=example,dc=com
> org.apache.directory.shared.ldap.model.message.ModifyRequestImpl@7b3d2b36
>   ManageDsaITImpl Control
>        Type OID    : '2.16.840.1.113730.3.4.2'
>        Criticality : 'false'
> '
> : ERR_279 Required attributes [member(2.5.4.31)] not found within
> entry cn=qux,ou=foo,ou=groups,dc=example,dc=com]; remaining name
> 'cn=qux,ou=foo,ou=groups,dc=example,dc=com'
>
> The operation fails because I'm using ApacheDS, which does not seem to
> support empty group (or maybe it's a configuration thing...)
>
> So I reckon (more bonus points ? :) ) that grouper is not able to
> resolve any subjects. It doesn't try to add the one that should be
> added and wants to delete the one that shouldn't be touched.
>
> I've went through the logs but could not find mentions of unresolved
> subjects. The complete log is here:
>
> http://pastebin.com/ifyWeC2G
>
> Am I missing something?
>
> Thanks,
> --jtellier
>
>
> On Wed, Jun 6, 2012 at 6:26 PM, Tom Zeller 
> <>
>  wrote:
>> Set provisioning log levels to debug in log4j.properties and try again.
>>
>> Yes, your reckoning is likely correct, the "noSuchIdentifier" and
>> "unable to calculate provisioned object" error messages mean that no
>> provisioned object identifier could be calculated. However, this is
>> for 'stem:ADM1100-H12', so I do not think this means that cn=elbe can
>> not be resolved. If cn=elbe could not be resolved, then the calc
>> response would consist of a group (or is this a stem ?) without the
>> cn=elbe member.
>>
>> Increasing log verbosity should help.
>>
>> P.S. bonus points awarded for using the word "reckon".
>>
>> # Provisioning : PSP (version 2.1+)
>> log4j.logger.edu.internet2.middleware.psp = DEBUG
>>
>> # Provisioning : vt-ldap
>> log4j.logger.edu.vt.middleware.ldap = DEBUG
>>
>> # Provisioning : Grouper plugin to Shibboleth attribute resolver
>> log4j.logger.edu.internet2.middleware.grouper.shibboleth = DEBUG
>>
>> On Wed, Jun 6, 2012 at 2:08 PM, Jonathan Tellier 
>> <>
>>  wrote:
>>> Hi,
>>>
>>> I'm trying to set up a deployment where Grouper would retrieve its
>>> data from a DB and would then provision everything to an LDAP
>>> directory. In order to test, I'm using the sample HSQL DB with sample
>>> data that comes with the Grouper Installer. I've also set up an LDAP
>>> in which I've manually added an single entry corresponding to one of
>>> the subjects in the DB. I've added this one subject to a group by
>>> using Grouper. When I try to provision the stem to my LDAP by using
>>> GSH, I get this error:
>>>
>>>  <psp:calcResponse xmlns:psp='http://grouper.internet2.edu/psp'
>>> status='failure' requestID='2012/06/06-18:52:24.793'
>>> error='noSuchIdentifier'>
>>>  <errorMessage>Unable to calculate provisioned object.</errorMessage>
>>>  <psp:id ID='stem:ADM1100-H12'/>
>>> </psp:calcResponse>
>>>
>>> The logs do not give me any other useful information.
>>>
>>> Now, I think I've got an idea about what's happening, but I don't know
>>> how to fix my problem. The user that comes from the DB has the ID
>>> "elbe". Now, the "elbe" user that I've manually created in my LDAP has
>>> the following DN : "cn=elbe,ou=people,dc=example,dc=com". I reckon
>>> that Grouper cannot resolve the "elbe" ID into the
>>> "cn=elbe,ou=people,dc=example,dc=com" DN, thus raising a
>>> "noSuchIdentifier" error. Does that make sense?
>>>
>>> I've played with the attributes definition in order to set the CN as
>>> the subject identifier, but it didn't help.
>>>
>>> Any ideas about what I could do to be able to provision data into my LDAP?
>>>
>>> Thanks,
>>> --jtellier