Re: "invalid structural object class chain"

[Hallvard B Furuseth <h.b.furuseth@usit.uio.no>]

Karsten Kankowski writes:
> objectClass: Person
> objectClass: (...)
> objectClass: account
> (...)
> I get back:
> ldapadd: Object class violation (65)
>         additional info: invalid structural object class chain
> (inetOrgPerson/account)

The structural object class chain says what kind of real-world entity
your LDAP object describes: person, account, country, whatever.

The complaint means that your data model is wrong: Your LDAP object
describes a person who is also a computer account.  No, a person is not
an account.  He may own a computer account, that's all.  The correct
model is that two different entities (a person and an account) get two
LDAP objects.

Your data model may give you practical problems - what if some person
has two accounts?  Then you need two different LDAP objects with
different home directories etc - yet there is only one of the person,
and from an address book point of view you'll likely not want him to be
listed as two people.  So you may be better off with two directory trees
- one with people and one with accounts, maybe with uid=<main account>
as the RDN of the people.

If you don't think that'll be a problem, likely you can in this case
just remove 'account' which is structural and keep 'posixAccount' which
is auxiliary.  Alternatively you could create a personAccount object
class with SUP ( inetOrgPerson $ account ) so you can unite the two
structural object class chains into one.

> All what I hopfully know is, that a subsequent class of a Structural
> can be one or more auxiliary OR an other Structural. I assume that
> Top->Person->organizationalPerson->inetOrgperson "looks" like one
> structural class in case that they inherit via the SUP keyword (
> called superclass ?? )

The ordering of the values in the LDAP object is irrelevant.  The point
is that there must be a single structural object class which directly or
indirectly inherits (via SUP) from all the other structural classes.

In addition you can have whatever auxiliary classes you want.

-- 
Hallvard