[Date Prev][Date Next]
Re: slapo-allowed: allowedChildClasses and allowedChildClassesEffective
> Cc:-ed samba-technical list...
> firstname.lastname@example.org wrote:
>> Michael Ströder wrote:
>>> email@example.com wrote:
>>>> Michael Ströder wrote:
>>>>> firstname.lastname@example.org 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
>>>> objectClasses that can be added to a given entry; in my
>>>> 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
>>>> 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
> (STRUCTURAL object class User) only a very limited set of object classes
> returned. Playing around with web2ldap's object class select form on MS AD
> 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
>> 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
>> As soon as I know for sure what those attributes are supposed to
>> then I think they should reflect that definition within OpenLDAP (e.g.
>> entry with any structural objectclass can be added as the child of any
> For the time being there should be a way to disable those two attributes
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.