Jeff Clowser wrote:
Steven Bonneville wrote:
> 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...
>
> ...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.
>
>
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(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-directory-users