Re: slapo-allowed: allowedChildClasses and allowedChildClassesEffective

[masarati@aero.polimi.it]

> Cc:-ed samba-technical list...
>
> masarati@aero.polimi.it wrote:
>> Michael Ströder wrote:
>>> masarati@aero.polimi.it wrote:
>>>> Michael Ströder wrote:
>>>>> masarati@aero.polimi.it wrote:
>>>>>> slapo-allowed was modified between 2.4.21 and 2.4.22; support for
>>>>>> allowedChildClasses and allowedChildClassesEffective was added.
>>>>> The semantics you've implemented seems to be incompatible with my
>>>>> implementation in web2ldap which works correctly with MS AD. I do not
>>>>> claim to know the *exact* semantics of these attributes though.
>>>>>
>>>>> web2ldap only uses the attribute 'allowedChildClasses'. In the object
>>>>> class select form web2ldap now only shows an empty list of STRUCTURAL
>>>>> object classes to be usable for a new entry. AUXILIARY object classes
>>>>> are shown. At first glance it seems STRUCTURAL object classes are
>>>>> not returned by slapo-allowed in the search result at all.
>>>>
>>>> Since the main purpose of that overlay is to mimic AD, I think your
>>>> observations make sense.  I inferred the semantics of those attributes
>>>> from the description I found in the links I was pointed to by Andrew
>>>> Bartlett.  My interpretation is that allowedChildClasses should list
>>>> the
>>>> objectClasses that can be added to a given entry; in my
>>>> interpretation,
>>>> these are all AUXILIARY objectClasses known to the DSA.  The
>>>> allowedChildClassesEffective are those objectClasses the identity is
>>>> allowed to add by ACLs, and whose required attrs the identity is
>>>> allowed
>>>> to add by ACLs.  Unless I made any coding mistake...
>>>
>>> Hmm, aren't these attributes just for determiníng the usable object
>>> classes when adding new entries (like poor man's DIT structural rules)?
>>
>> In that case, slapo-allowed behavior would consist in listing all
>> STRUCTURAL objectclasses.
>
> Not only STRUCTURAL objectclasses. AUXILIARY object classes are definitely
> listed too. E.g. in MS AD when requesting allowedChildClasses on a user
> entry
> (STRUCTURAL object class User) only a very limited set of object classes
> are
> returned. Playing around with web2ldap's object class select form on MS AD
> it
> makes sense.

Well, it makes sense that although any, but exactly one, STRUCTURAL class
can be added in OpenLDAP, any, and all, AUXILIARY could be added, as soon
as *one*  STRUCTURAL class is present.

>>> In MS AD there are DIT content rules for limiting AUXILIARY object
>>> classes.
>>
>> My interest in having this overlay exactly reproduce AD's behavior is
>> close to zero.
>
> Given that the attribute type description
>
> 1. uses an OID by Microsoft in arc 1.2.840.113556 (see
> http://www.alvestrand.no/objectid/1.2.840.113556.html) and
>
> 2. that the only specification with this OID is in [MS-ADA1] and
>
> 3. Samba4 definitely aims to exactly mimique MS AD
>
> the behaviour of slapo-allowed should be *exactly* the same like in MS AD.
> Otherwise it seems that I've misunderstood all the former schema OID
> discussions we had on openldap-devel.

Agree (up to some point).  If by *exactly* you mean "including intrinsic
limitations", maybe I don't.  If you mean "semantically equivalent", I
totally agree.  However, given the purpose of the overlay, we can come to
a trade-off, where any limitation should be configurable.

> I admit the text in [MS-ADA1] is pretty terse and can be interpreted in
> various ways.

:)

> I guess Andrew should pass this to MS dochelp.
>
>> My main interest is in making OpenLDAP support Samba4 correctly, and the
>> request for this feature was initially related to Samba4.
>
> Could you please point me to an ITS? In case Samba4 has a different
> requirement I'd strongly request to use another attribute type description
> (different OID and NAME).

I don't recall whether this came from an ITS or from a feature request on
the mailing list.  For sure it was related to this thread
<http://www.redhat.com/archives/fedora-directory-devel/2006-November/msg00000.html>.

>> As soon as I know for sure what those attributes are supposed to
>> contain,
>> then I think they should reflect that definition within OpenLDAP (e.g.
>> an
>> entry with any structural objectclass can be added as the child of any
>> entry).
>
> For the time being there should be a way to disable those two attributes
> in
> slapo-allowed.

Sounds fine.  I committed that fix while cleaning up my list of pending
submissions and ITSes, it wasn't probably intended for release in 24.  As
a quick hack, you can probably back up to 2.4.21's version.  If you think
we can quickly come to an "agreed" functionality, I can improve the code. 
Otherwise, by the next release, I'll make those attrs optional.

p.