[Fedora-directory-users] Wishlist

[Jeff Clowser]

Sorry to dredge up a really old thread, but I've been trying to track 
down something about it that's been bothering me.

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(?)

It was something I hadn't known before, so finally got around to looking 
for where that was defined.

Looking at RFC 2251:

Each entry MUST have an objectClass attribute.  The objectClass
attribute specifies the object classes of an entry, which along with
the system and user schema determine the permitted attributes of an
entry.  Values of this attribute may be modified by clients, but the
objectClass attribute cannot be removed.  Servers may restrict the
modifications of this attribute to prevent the basic structural class
of the entry from being changed (e.g. one cannot change a person into
a country).  When creating an entry or adding an objectClass value to
an entry, all superclasses of the named classes are implicitly added
as well if not already present, and the client must supply values for
any mandatory attributes of new superclasses.

Looking at rfc 2252:

The format for representation of object classes is defined in X.501
[3]. In general every entry will contain an abstract class ("top" or
"alias"), at least one structural object class, and zero or more
auxiliary object classes.  Whether an object class is abstract,
structural or auxiliary is defined when the object class identifier
is assigned.  An object class definition should not be changed
without having a new identifier assigned to it.


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.

Did I misunderstand something?  If this is actually illegal, does anyone 
know a reference that documents this?  Or am I just completely confused 
here?

 - Jeff

>> Looking briefly at rfc1274, it looks like host is an allowed 
>> attribute of account objectclass, so actually, the schema is all 
>> already there if you create users that have the account, 
>> posixAccount, and shadowAccount objectclasses, ...
>
> Unfortunately, the objectclass "account" is a structural objectclass, 
> which means you can't "mix it in" with other structural objectclasses 
> such as inetOrgPerson.  So I think either the standard needs to be 
> revised to make account auxiliary, or create a new objectclass 
> (auxAccount?).