Grouper Users - Open Discussion List

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