[389-users] Question regarding Combining ObjectClasses to add attributes

[Rich Megginson]

On 07/10/2012 09:01 AM, Anderson, Cary at 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:rmeggins at redhat.com]
> *Sent:* Monday, July 09, 2012 9:14 AM
> *To:* General discussion list for the 389 Directory server project.
> *Cc:* Anderson, Cary at CIO
> *Subject:* Re: [389-users] Question regarding Combining ObjectClasses 
> to add attributes
>
> On 07/09/2012 09:44 AM, Anderson, Cary at 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-users at lists.fedoraproject.org  <mailto:389-users at lists.fedoraproject.org>
> https://admin.fedoraproject.org/mailman/listinfo/389-users
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/389-users/attachments/20120710/3f8bac7e/attachment.html>