slapo-allowed: allowedChildClasses and allowedChildClassesEffective (was: Seg faults with 2.4.22)
Redirected this to openldap-devel...
masarati@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.
Ciao, Michael.
Redirected this to openldap-devel...
masarati@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...
p.
masarati@aero.polimi.it wrote:
Redirected this to openldap-devel...
masarati@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.
Ciao, Michael.
masarati@aero.polimi.it wrote:
Redirected this to openldap-devel...
masarati@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.
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. 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).
p.
Cc:-ed samba-technical list...
masarati@aero.polimi.it wrote:
Michael Ströder wrote:
masarati@aero.polimi.it wrote:
Michael Ströder wrote:
masarati@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.
Ciao, Michael.
Cc:-ed samba-technical list...
masarati@aero.polimi.it wrote:
Michael Ströder wrote:
masarati@aero.polimi.it wrote:
Michael Ströder wrote:
masarati@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
- uses an OID by Microsoft in arc 1.2.840.113556 (see
http://www.alvestrand.no/objectid/1.2.840.113556.html) and
that the only specification with this OID is in [MS-ADA1] and
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.
-
masarati＠aero.polimi.it -
Michael Ströder