On 07/10/2012 09:01 AM, Anderson, Cary@CIO wrote:
Thanks for the quick response.
The RHN knowledgebase article I found was titled: "How to use "host"
attribute to limit ldap users can be accessed by specified host?" kb#
65838
https://access.redhat.com/knowledge/solutions/65838
It doesn't say anything about an "Account" objectclass.
See also http://port389.org/wiki/Howto:Posix
*From:*Rich Megginson [mailto:rmegg...@redhat.com]
*Sent:* Monday, July 09, 2012 9:14 AM
*To:* General discussion list for the 389 Directory server project.
*Cc:* Anderson, Cary@CIO
*Subject:* Re: [389-users] Question regarding Combining ObjectClasses
to add attributes
On 07/09/2012 09:44 AM, Anderson, Cary@CIO wrote:
I have recently started working with the Director Server, and I have
read the documents for both 389 and RHDS, but I am having some
difficulties regarding ObjectClass types, and combining them in order
to extend the available attributes for an object. The documents
indicate that you can only have one Structural ObjectClass and
multiple Aux. ObjectClasses, and I'm a bit hazy on the rules for
Abstract ObjectClasses.
If I take the example of needing to add the "host" attribute to a user
object. A RHN knowledgebase article indicates to add the "hostobject"
ObjectClass rather than the "Account" ObjectClass.
Can you provide a link to this kbase article?
My assumption was that "hostobject" was an Aux. ObjectClass, and that
"Account" was Structural, but when I look at the two ObjectClasses via
the administrative GUI, they both have "Top" listed as the parent
ObjectClass. So I'm not certain why one is appropriate and the other
is not.
It would appear the console does not tell you if the objectclass is
structural, auxiliary, or abstract. You cannot tell by just the
inheritance - by default, all objectclasses have "top" as the superior
unless otherwise specified.
This is the official LDAPv3 description -
http://www.ietf.org/rfc/rfc4512.txt
An entry may have only one STRUCTURAL objectclass, and multiple
AUXILIARY objectclasses. Chances are you will want to use AUXILIARY
objectclasses for your extra attributes (like posixAccount) and just
use one of the pre-defined objectclasses (like inetOrgPerson) as your
STRUCTURAL objectclass.
Moving forward I want to be able to combine ObjectClasses to extend
available objects without introducing data integrity issues in my ldap
directory. I am looking for some clarification of rules regarding
structural objectclasses,
See rfc4512
and if there is an easy way via the admin gui to tell the difference
between structural, auxillary, and abstract objectclasses.
No. You'll have to search cn=schema to check:
ldapsearch -xLLL -s base -b "cn=schema" "objectclass=*" objectclasses
| perl -p0e 's/\n //g' | grep AUXILIARY
Note that ldapsearch wraps the output, so you'll have to use perl (or
sed) to unwrap - see http://richmegginson.livejournal.com/18726.html
Also will the directory do some sort of intregrity checking if you
attempt to combine improper objectclasses either via commandline or
the admin gui?
Yes, although by default 389 will allow an entry to have multiple
structural objectclasses, but that will change in a future release, so
don't rely on that behavior.
Thanks
* Cary Anderson*
**916.464.5108
*Linux Support**|****Engineering Dept**.*
--
389 users mailing list
389-us...@lists.fedoraproject.org <mailto:389-us...@lists.fedoraproject.org>
https://admin.fedoraproject.org/mailman/listinfo/389-users
--
389 users mailing list
389-us...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
