I believe this is going to become more and more of a problem with LDAP in general - how to create entries that belong to many different objectclasses, if more than one of them are structural? It's almost as if you need an analogous auxiliary objectclass for each structural one.
I've encountered this problem before in Java programming, and I used the following paradigm: create pairs of interface/implementation class.
Start with the interface e.g.
public interface IDoer {
public String getProp1();
public String getProp2();
...
}
Then, create the implementation class:
public class DoerImpl implements IDoer {
...
}
This idea could be extended to LDAP (albeit clumsily perhaps) e.g.
objectclass auxInetOrgPerson SUP 'inetOrgPerson' AUXILIARY
to "extend" the structural inetOrgPerson class into an "interface" that
could be mixed in with another structural objectclass. I don't know if
this is possible or allowed by LDAP or X.500. It would probably have
been better to do the obverse e.g. create auxInetOrgPerson first as an
AUXILIARY class with all of the attributes, then create inetOrgPerson
SUP 'auxInetOrgPerson' STRUCTURAL. But then you would have to do that
with all of the superclasses as well: organizationalPerson and person.
Jeff Clowser wrote:
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?- JeffLooking 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?).-- Fedora-directory-users mailing list Fedora-directory-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-directory-users
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
-- Fedora-directory-users mailing list Fedora-directory-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-directory-users
