Grouper Users - Open Discussion List

[Tom Zeller <>]

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