Redirected this to openldap-devel... 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 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.

masarati(a)aero.polimi.it wrote: >> Redirected this to openldap-devel... >> >> 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 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 MS AD there are DIT content rules for limiting AUXILIARY object classes.

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

>> 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.

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).

> 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.