> Cc:-ed samba-technical list... > > masar...@aero.polimi.it wrote: >> Michael Ströder wrote: >>> masar...@aero.polimi.it wrote: >>>> Michael Ströder wrote: >>>>> masar...@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.
