Grouper Users - Open Discussion List

["Klug, Lawrence" <>]

Hi Tom

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