Jeff Clowser wrote:
Steven Bonneville wrote:Well, sort of. What X.501 says and the LDAP RFCs follow is that an entryis 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......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 structuralobject class chains -- that's illegal.Just talking this through:I was looking for where this is specifically stated as illegal. I guess the answer to this is the X.501 spec (I think it costs money to get this, though?). RFC2252 states "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.". This could be interpreted as saying: LDAP is based on and follows X.501, unless otherwise specified, and here is where we specifically state where LDAP differs from X.501, and X.501 has this limit, but strictly speaking, LDAP does not(?) I suppose you could also interpret that as allowing multiple structural objectclasses, as long as they have a common ancestor (the LDAP RFC doesn't say that, but I suppose that might be more clearly stated in the X.501 spec?). Sounds like I am stepping into an LDAP/X.50x holy war :)
I'm sure the folks on the ldap umich list will be happy to provide their interpretations :-)
Thinking about this in a real-world context, given/if multiple structural objectclasses are illegal, then it seems that the definition of the account objectclass is poorly thought out (granted, it was defined long, long ago...) - it makes sense to extend a person entry to be an account (or vice versa), so that you don't have to have separate entries for one person to define unix login, "account" info, etc - I should be able to define a single user all in one entry, so that if I want to change a users password, grant or remove access to services, etc, I do it in one place. (maybe a bad example, since account doesn't include a password, which seems kinda strange itself...) Otherwise, you defeat part of the purpose of LDAP, and violate some basic tenants of data design (i.e. avoiding duplication of data, etc).
The account objectclass was poorly designed IMHO.
FWIW, this all started with a discussion of posixAccount, and how to restrict what hosts a user can log into. My initial thought was to just add the account objectclass to a user to have a host attribute for a user (wouldn't have to extend the schema, and could use existing standard oc's) , but then you run into the multiple structural oc's issue. I guess the "right" answer would be to define a non-standard objectclass that is an extention of person, posixaccount, or whatever that allows the host attribute.
We are going to be visiting this issue for our next release. In the new RFC2307bis (which we will somehow support) http://www.ietf.org/internet-drafts/draft-howard-rfc2307bis-01.txt - posixAccount and most of the other key objectclasses that you might want to "mix in" with existing structural objectclasses are defined as AUXILIARY specifically for this reason. As far as the problem with the account objectclass - one of the key things needed is the "host" attribute, for host based access restriction. I know that some tools (Directory Administrator) assume that, if a search is done for objectclass=posixAccount, the host attribute should be among them. I propose the creation of a new objectclass that will be AUXILIARY and also be a subclass of posixAccount. This objectclass will contain the "host" attribute (other attributes?). In order to make host based access restriction work, you would simply add this objectclass and host attribute to any existing user, even if they already have the posixAccount objectclass. I'm not sure what a good name for this objectclass would be - perhaps posixAccountExt or ??? At any rate, applications that use the search filter (objectclass=posixAccount) to get entries that contain the host attribute would continue to work. This would simplify new account creation because you could just use the new objectclass instead of posixAccount and it would inherit all of the posixAccount attributes.
- Jeff -- 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
