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.