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