[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