[Date Prev][Date Next]
Re: slapo-allowed: allowedChildClasses and allowedChildClassesEffective
> email@example.com wrote:
>>> Redirected this to openldap-devel...
>>> 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
>>> STRUCTURAL object classes to be usable for a new entry. AUXILIARY
>>> classes are shown. At first glance it seems STRUCTURAL object classes
>>> 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
> when adding new entries (like poor man's DIT structural rules)?
In that case, slapo-allowed behavior would consist in listing all
> 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. My main interest is in making OpenLDAP support Samba4
correctly, and the request for this feature was initially related to
Samba4. 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).