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
Are the X.5xx documents available on-line? Steven Bonneville wrote:>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 > >-- >Fedora-directory-users mailing list >Fedora-directory-users@redhat.com >https://www.redhat.com/mailman/listinfo/fedora-directory-users > >
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 :) 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). 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. - Jeff
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@redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users
Rich Megginson wrote:> Jeff Clowser wrote: > >> 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 :-)Heh :)> 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. >Are you proposing this simply as "lets all agree on this list on something", as "a schema extension that comes with FDS", or as a new standard oc, with properly registered OIDs and all? If a new standard oc, how hard is it to do that - not something I''ve ever done. I would like the third mainly because it makes it easier for for interoperability, but I can live with either of the other two. Would make sense to discuss if there are other attributes to add while we''re at it. - Jeff
Jeff Clowser wrote:> Rich Megginson wrote: > >> Jeff Clowser wrote: >> >>> 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 :-) > > > Heh :) > >> 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. >> > Are you proposing this simply as "lets all agree on this list on > something", as "a schema extension that comes with FDS", or as a new > standard oc, with properly registered OIDs and all? If a new standard > oc, how hard is it to do that - not something I''ve ever done. I would > like the third mainly because it makes it easier for for > interoperability, but I can live with either of the other two. Would > make sense to discuss if there are other attributes to add while we''re > at it.I would like it to be a standard as well, but at the same time, solve the existing problems our users have. Perhaps there is even enough time to get the "host" attribute added to rfc2307 bis. If not, then this specification would go through the RFC track, as either a Proposed Standard or an Informational RFC. http://www.ietf.org/tao.html#6> > - Jeff > > -- > Fedora-directory-users mailing list > Fedora-directory-users@redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users
On 26-Aug-2005, Rich Megginson wrote:> Are the X.5xx documents available on-line?Yes: http://www.itu.int/rec/recommendation.asp?type=products&lang=e&parent=T-REC-X The first three you download are free; register here: http://ecs.itu.ch/cgi-bin/ebookshop After the free ones, the prices range from ~CHF20-100 (~USD15-75) per document. -Dave