Grouper Users - Open Discussion List

[Tom Zeller <>]

Yes. Replace "eduMember" with "uclaMember" in the StaticDataConnector.

> Is it a viable workaround  to plug in our objectClass "uclaMember" as a 
> replacement  for eduMember as a until version (201108) is finalized?   Is 
> it a simple matter of modifying of ldappc-resolver.xml?
>
> Thanks,
>
> Lawrence
>
> -----Original Message-----
> From: 
> 
>  
> [mailto:]
>  On Behalf Of Tom Zeller
> Sent: Thursday, November 10, 2011 9:42 AM
> To: Grouper Users Mailing List
> Subject: Re: [grouper-users] RE: LDAPCNG Issues - follow up question
>
> Some folks from MACE-dir are on this list, but perhaps that might be the 
> best place to ask.
>
>  
>
> TomZ
>
> 2011/11/10 Ma, Ying 
> <>:
>> Hi,
>>
>> Thanks for pointing this out. Does anyone know if this version (201108) of 
>> eduMember is finalized or on its way to be finalized as Internet2 standard?
>>
>> Thanks,
>> Ying Ma
>> Middleware Service
>> IT Services, UCLA
>> 
>> (310)206-4978
>>
>> -----Original Message-----
>> From: 
>> 
>> [mailto:]
>>  On Behalf Of Pål Axelsson
>> Sent: Wednesday, November 09, 2011 3:22 PM
>> To: 
>> 
>> Subject: RE: [grouper-users] RE: LDAPCNG Issues - follow up question
>>
>> Hi,
>>
>> I've seen that there is a new draft on eduMember where this issue is
>> addressed. isMemberOf changes name to eduIsMemberOf and hasMember
>> changes name to edeHasMember.
>>
>> https://spaces.internet2.edu/download/attachments/2309/eduMember-20110
>> 8-draf
>> t-00.html
>>
>> Pål Axelsson
>>
>>
>>
>>> -----Original Message-----
>>> From: 
>>> 
>>>  [
>>> ]
>>>  On Behalf Of Klug, Lawrence
>>> Sent: Wednesday, November 09, 2011 11:24 PM
>>> To: Tom Zeller
>>> Cc: 
>>> 
>>> Subject: [grouper-users] RE: LDAPCNG Issues - follow up question
>>>
>>> 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
>>> >
>>> >
>>
>