Grouper Users - Open Discussion List

["Klug, Lawrence" <>]

I would assume that I also need to delete existing groups from the repository 
and LDAP - would the repository need to be re-initailized?

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

 
[mailto:]
 On Behalf Of Tom Zeller
Sent: Thursday, November 10, 2011 10:21 AM
To: Klug, Lawrence
Cc: Grouper Users Mailing List
Subject: Re: [grouper-users] RE: LDAPCNG Issues - follow up question

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