Cc:-ed samba-technical list...
> Michael Ströder wrote:
>> masarati(a)aero.polimi.it wrote:
>>> Michael Ströder wrote:
>>>> masarati(a)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
>>>> 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
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
> 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
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
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.