Grouper Users - Open Discussion List

["Klug, Lawrence" <>]

Tom,

I've been talking with our  LDAP  administrator and apparently we have a 
naming conflict with the eduMember  objectClass.  This is a result of the 
upgrade to Sun Java System Directory Server Enterprise Edition 6.3.1.

Please read her comments below:

Yes, eduMember is the cause of the problem. I have eduMember implemented in 
the directory. However, one of the eduMember attribute isMemberOf has the 
name conflict with DSEE 6.3 system attribute name. I had to delete the 
eduMember version of isMemberOf during our migration from DSEE 5.2 to 6.3. In 
other words, eduMember implementation use to be fine in DSEE5.2, but it can 
no longer be implemented in DSEE 6.3 because of the name conflict.

I'm now implementing a new object class uclaMember in eds7. This object class 
has two attributes: uclaIsMemberOf and uclaHasMember. I'm going to ask you to 
try use uclaMember instead of eduMember with LDAPCNG to see if this could be 
a possible workaround. 

If you want, you can post the issue to grouper mailing list to see if anyone 
else has encounter the same issue and if they have a better workaround.


-----Original Message-----
From: 

 
[mailto:]
 On Behalf Of Tom Zeller
Sent: Tuesday, November 08, 2011 5:12 PM
To: Klug, Lawrence
Cc: 

Subject: Re: LDAPCNG Issues - follow up question

You probably need to add the eduMember objectclass to your ldap server. The 
schema file is not included in the distribution, which is a bug, which will 
be fixed in 2.1.

The objectClass for a group is defined in ldappcng.xml :

    <object id="group" authoritative="true">
      <attribute name="objectClass" ref="group-objectclass-eduMember" />

and ldappc-resolver.xml :

  <resolver:DataConnector id="StaticDataConnector" xsi:type="dc:Static">
    <dc:Attribute id="group-objectclass-eduMember">
      <dc:Value>top</dc:Value>
      <dc:Value>${groupObjectClass}</dc:Value>
      <dc:Value>eduMember</dc:Value>
    </dc:Attribute>

The ${groupObjectClass} is defined in ldappc.properties, which is by default :

 groupObjectClass=groupOfNames

The eduMember objectclass, however, will probably need to be added to your 
ldap directory.

The eduMember schema definition is not included in the distribution, but is 
available from

 
http://anonsvn.internet2.edu/cgi-bin/viewvc.cgi/i2mi/trunk/ldappcng/ldappcng/misc/ldap/

Apologies for the hassle.

TomZ

https://bugs.internet2.edu/jira/browse/GRP-505

On Tue, Nov 8, 2011 at 11:05 AM, Klug, Lawrence 
<>
 wrote:
> When running LDAPPCNG 2.x for group synchronization, we are observing 
> LDAP errors and some of the changes are not propagated to the 
> directory. We're seeing two types of errors:
>
> LDAP: error code 67 - Not Allowed On RDN
>
> LDAP: error code 19 - Constraint violation in modifications
>
>
>
> The errors seem to revolve around add/delete operations, i.e. adding 
> or deleting a member from an existing  group.
>
>
>
> We're thinking it might be a schema issue. Can you point us to the 
> objectClass definition  (should be a standard Internet2 edu object 
> class) that LDAPPCNG2.x is working with?  We'd like to check the 
> schema implementation on our ED to see if it's compliant with LDAPPCNG2.x.
>
>
>
> Thanks,
>
>
>
> Lawrence Klug
>
> UCLA Middleware Services
>
> Office: 310 825-2061
>
> Cell: 818 667-2386
>
>