[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: eduPerson object not working
Hi,
Here's a version that worked for me. It is a straight hack of the georgetown ldif into
a .schema. Kurt Zeilenga pointed out that these attributes should probably have some
sort of match specification, for indexing purposes. I haven't added any myself as yet.
An appropriate match would be something like:
EQUALITY caseIgnoreMatch
since these are all strings, except for eduPersonOrgDN and eduPersonOrgUnitDN which should
have:
EQUALITY distinguishedNameMatch
since they are DNs.
Some lines may be wrapped by your mail client.
--------------------------begin eduperson.schema-----------------------------------------
#
# eduPerson Objectclass version 1.0 (2001-01-22)
#
# See http://www.educause.edu/eduperson for background and usage
#
# eduPerson is an effort of Internet2 and EDUCAUSE
#
# [...]
#
# 1.3.6.1.4.1.5923 is the toplevel OID for this work
# .1 = MACE related work
# .1.1 = eduperson
# .1.1.1 = attributes
# .1.1.2 = objectclass
# .1.1.3 = syntax
#
# CHANGELOG
#
# Jul 20, 2000 (gettes@georgetown.edu) Original version
# Aug 17, 2000 (gettes@georgetown.edu) Added EPPNEphemeral
# also cleanup and initial documentation
# Jan 22, 2001 (gettes@georgetown.edu) Removed EPPNEphemeral
# EPPNephemeral not part of 1.0
# moved all OIDs below 5923.1
#
# [hacked into a .schema file for OpenLDAP use by Craig Squires Nov 20, 2001.]
#
# NOTE: 1466.115.121.1.15 SYNTAX is strings; 1466.115.121.1.12 is distinguished names
# eduPersonAffiliation: relation to the institution; e.g. faculty, student, staff, alum,
# member, affiliate, employee; multiple values are allowed; in particular, eduPersonPrimaryAffiliation
# should be here too, if it exists. Indexing: pres,eq,sub.
attributetype ( 1.3.6.1.4.1.5923.1.1.1.1 NAME 'eduPersonAffiliation'
DESC 'eduPerson per Internet2 and EDUCAUSE'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
# eduPersonNickname: person's informal or customary name; useful for 'user-friendly' search by name;
# should be self-maintained, and should not depend on the cn. Indexing: pres,eq,sub.
attributetype ( 1.3.6.1.4.1.5923.1.1.1.2 NAME 'eduPersonNickname'
DESC 'eduPerson per Internet2 and EDUCAUSE'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
# eduPersonOrgDN: distinguished name of the organization to which the person is primarily affiliated;
# e.g. o=Hogwarts,dc=hsww,dc=wiz
attributetype ( 1.3.6.1.4.1.5923.1.1.1.3 NAME 'eduPersonOrgDN'
DESC 'eduPerson per Internet2 and EDUCAUSE'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE )
# eduPersonOrgUnitDN: distinguished name of the organizational unit(s) to which the person belongs;
# multiple values allowed; e.g. ou=potions,o=Hogwarts,dc=hsww,dc=wiz
# Indexing: pres,eq,sub.
attributetype ( 1.3.6.1.4.1.5923.1.1.1.4 NAME 'eduPersonOrgUnitDN'
DESC 'eduPerson per Internet2 and EDUCAUSE'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
# eduPersonPrimaryAffiliation: see eduPersonAffiliation; single value; usable e.g. for access control.
# Indexing: pres,eq,sub.
attributetype ( 1.3.6.1.4.1.5923.1.1.1.5 NAME 'eduPersonPrimaryAffiliation'
DESC 'eduPerson per Internet2 and EDUCAUSE'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
# eduPersonPrincipalName: id for intra-institutional authentication; e.g. person@univ.edu, where univ
# is the appropriate local security domain; local institution should be able to affirm identity to non-local
# institutions on the basis of this id; could e.g. be a local kerberos id. Indexing: pres,eq,sub.
attributetype ( 1.3.6.1.4.1.5923.1.1.1.6 NAME 'eduPersonPrincipalName'
DESC 'eduPerson per Internet2 and EDUCAUSE'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
objectclass ( 1.3.6.1.4.1.5923.1.1.2 NAME 'eduPerson' SUP 'inetOrgPerson' STRUCTURAL
MAY ( eduPersonAffiliation $ eduPersonNickname $
eduPersonOrgDN $ eduPersonOrgUnitDN $
eduPersonPrimaryAffiliation $ eduPersonPrincipalName ) )
--------------------------------------------end----------------------------------------------------
If you want to follow the suggestion below and eliminate the relation to inetOrgPerson,
then just remove "SUP 'inetOrgPerson'" from the objectclass specification.
Craig
On Sun, 31 Mar 2002, Theodore Knab wrote:
> I suppose this partially explains why the ldap.georgetown.edu gives a replay to
> the query of ldap and a query to root. :-)
>
> http://www.emailman.com/ldap/public.html
>
> > Michael Gettes released the eduPerson schema as an LDAP change file. It expects a
> > version 3 compatible LDAP that contains the schema as an object that can be changed
> > while the server is running. OpenLDAP does not implement this (yet). Is iPlanet the
> > only implementation? Someone needs to convert the change file to a schema file that is
> > usable by OpenLDAP. I've heard of several people doing it and a lot of people say it
> > should not be difficult but I've never seen anyone release their copy for inspection or
> > use. Since it only adds 6 attributes and the changefile does provide all the details it
> > really should not be hard to convert. But here I've been trying to learn LDAP for the
> > past year and I still have not done it.
>
> > Michael Gettes has also indicated in conferences that he made a mistake in the
> > changefile. He made the eduPerson subordinate to inetOrgPerson but this is not
> > required.
>
--
........................................................................
$Id: mathdeptsysadmin,v 1.0 Mon Apr 1 08:27:12 2002 Craig Squires Exp $