[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Objectclasses
Ron Aitchison wrote:
I have noticed in various documents purporting to describe LDAP and
OpenLDAP that in LDIF files most insisted on including objectclass:
top some did not, further most documents included the objectclass
hierarchy (e.g. objectclass: person and objectclass: inetOrgPerson)
but some did not. My reading of the RFC is not conclusive on either
point.
I've just run a series of experiments using OpenLDAP 2.0.27-2.7.1 on a
RedHat 7.1 ish installation to try and prove the issue:
I was able to create an apparently fully operational LDAP directory
(with my small experimental data set) without.
1. any objectclass:top entries
2. a single objectclass: inetOrgPerson (no hierarchy)
It also appeared that I was able to search on attributes that were
included in the object hierarchy but not in inetOrgPerson (e.g.
telephonenumber, cn and sn). I could find no apparent problems in the
limited testing that I did
This seems to me to be sensible behavior since the schema defines to
OpenLDAP the object hierarchy including top and OpenLDAP can process
it a lot faster than I can type it!. Further as a naturally lazy human
being it has lots of appeal! However before I go barreling into
full-blooded ruby/openldap implementation using this technique:
1. is there anything I cannot do with this set-up
2. are there limitations in using this approach security etc. etc
3. is there something coming down the pike that is going to make me
suffer for my laziness
Appreciate any help, thoughts or insight.
I don't exactly remember the versions, but aat the beginning objectClass
hierarchy was not enforced; later on, checks got stricter (i.e. only one
structural objectclass was allowed and so); now (2.2.13 for sure, but
2.1.X as well), objectClass inheritance is fully supported, i.e. if you
use inetOrgPerson, that implies all inetOrgPerson's hierarchy as well,
so you can search that entry by objectClass=organizationalPerson,
objectClass=person, objectClass=top. You don't need to write more than
the structural objectClass you intend to use for that entry.
p.
SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497