Re: Schema & Strucutal objecclass in 2.1.X (Re: setting up LDAP question)

[Stephan Siano <stephan.siano@suse.de>]

On Mittwoch, 6. November 2002 15:41, Jehan PROCACCIA wrote:
[...]
>
> I am not complaining about FREE software ! I really appreciate using it,
> don't misunderstand what I am asking here. I'am just seeking document
> which would explain me why my ldap database isn't suitable for openldap
> 2.1.X. If openldap used to accept thing that now are unacceptable due to
> the respect of the RFCs, it would be great to get advices when you are
> novice to these problems.
>
> From what I read and what you told me, I concluded that "I cannot use
> two structural objectclasses in the same entry" except if these
> objectclass are in the same family of inheritence right ?
>
> Exemple, these 3 objectclass declaration in an entry are acceptable ?
>
> objectclass ( 2.5.6.6 NAME 'person'
>         SUP top STRUCTURAL
>
> objectclass ( 2.5.6.7 NAME 'organizationalPerson'
>         SUP person STRUCTURAL
>
> objectclass     ( 2.16.840.1.113730.3.2.2 NAME 'inetOrgPerson'
>     SUP organizationalPerson STRUCTURAL
>
> Actually in the long list of my entries objectclass, only
> kerberosSecurityObject seemed to cause the problem:
>
> objectclass ( 1.3.6.1.4.1.2312.4.2.4 NAME 'kerberosSecurityObject' SUP
> top STRUCTURAL
>         DESC 'A uid with an associated Kerberos principal'
>         MUST ( krbName ) )
>
> with krbName attribute used to be in core.schema, changing it to
> AUXILIARY resolved it :-)

The documentation point is a bit tricky. The RFCs defining the LDAP V3 
protocol are somewhat inprecise in the direct wording. They are speaking 
about "structural objectclasses" and otherwise refer to the X.501 object 
model. The X.501 definitions are really clear about this issue. Each Object 
may belong to multiple structural object classes, but all of them have to 
belong to a single structural object class chain. That means, an object can 
be inetOrgPerson, organizationalPerson, and person, because one of these 
objectclasses (inetOrgPerson) is directly or indirectly derived from all 
other objectclasses. inetOrgPerson is neither derived from 
kerberosSecurityObject nor is kerberosSecurityObject derived from 
inetOrgPerson, so an object may not be both unless you define a new 
structural objectclass (e.g. intevryKerberosInetOrgPerson) that is derived 
from both and you make your objects also that object class.

> As it is stocked in /etc/openldap/schema/redhat/kerberosobject.schema, I
> suspect that it has been added in the RedHat openldap RPMS !? and that
> RedHat RPMS should be patche or change to take care of this .
>
> By the way, are there source RPMS (SRPMS) of 2.1.X openldap somewhere ?

On www.openldap.org, you can get a tarball in the download section. To create 
a (source and binary) rpm you just have to creae a spec-file.

Yours
Stephan Siano

-- 
Stephan Siano                           Mail:  Stephan.Siano@suse.de
SuSE Linux AG                           Phone: 06196 50951 31
CU PS South TCC UC                      Fax:   06196 409607
Mergenthalerallee 45-47	
D-65760 Eschborn