Jeff Clowser wrote: > Basically, part of the thread devolved to the idea of creating a single > user entry that has objectclasses: inetorgperson, account, > posixaccount, shadowaccount, etc. If I understand the response (see > below), this violates ldap standards because you are mixing in > structural objectclasses and that is not allowed(?) > > This is all I could find that came close - rfc2251 seems to say servers > may disallow changing structural objectclasses on an entry (to prevent > changing a user to a country, for example). RFC 2252 actually seems to > specifically say you _can_ mix structural objectclasses in one entry. Well, sort of. What X.501 says and the LDAP RFCs follow is that an entry is characterized by exactly one *chain* of structural object classes that has exactly one structural object class as the most subordinate object class in the chain. You then can add zero or more auxiliary object classes to add more attributes. So an entry structured as objectclass: top objectclass: person objectclass: organizationalPerson objectclass: inetOrgPerson objectclass: posixAccount objectclass: shadowAccount is legal. The most subordinate structural object class is inetOrgPerson, which the schema says is a subclass of organizationalPerson, which is a subclass of person, which is a subclass of top. The posixAccount and shadowAccount object classes are auxiliary, so no problem including those. Now, we can't add account as an object class of this entry, because it is a structural object class that is not part of the structural object class chain connecting inetOrgPerson to top, so we'd end up with two structural object class chains -- that's illegal. By using inetOrgPerson, you also have to include all of its superclasses. So you can't have inetOrgPerson without organizationalPerson, for example. If you can extend the schema, you can always derive a new structural class from an existing one. The parent structural class still appears as an objectclass attribute of an entry since it is part of the superclass chain of the structural object class of the entry. Look at evolutionPerson (in /usr/share/evolution-data-server-1.0/evolutionperson.schema on RHEL4) for an example. It's derived from inetOrgPerson and therefore gets all its attributes and the attributes of inetOrgPerson's superclasses. -- Steve Bonneville
