I'm not quite sure what I'm looking for here, sorry:
In Samba4, we don't yet have full schema validation. In some ways it just has not been a priority - we validate that the attribute and objectClasses exist, but not that they match up.
In using OpenLDAP, I'm hoping to avoid having to write that logic, so I stopped adding extensibleObject to all our objectClass values, and replaced it with samba4Top, contaning all the things that AD's top contains, but OpenLDAPs does not.
So far so good, but AD has: dn: CN=Domain-DNS,${SCHEMADN} objectClass: top objectClass: classSchema subClassOf: domain systemAuxiliaryClass: samDomain
Looking at http://www.grotan.com/ldap/microsoft.ext.schema
I created entries in my schema file like:
dITContentRule ( 1.2.840.113556.1.5.67 NAME 'domainDNS' AUX ( samDomain ) )
dITContentRule ( 1.2.840.113556.1.5.3 NAME 'samDomain' AUX ( samDomainBase ) )
This created two problems: It appears that you cannot create a ditContentRule for a non-structural objectClass (samDomain is AUXILIARY), and even if I do, I can't tack on the samba4Top on the end, because of:
Adding DomainDN: DC=samba,DC=example,DC=com (permitted to fail) ldb load failed: LDAP error 65 LDAP_OBJECT_CLASS_VIOLATION - <class 'samba4Top' not allowed by content rule 'domainDNS'> <>
Is there a different approach I should be taking? I need to extend 'top' without extending OpenLDAP's hardcoded top, and I need something that looks like dITcontentRule without the restrictions. Any hints?
Thanks,
Andrew Bartlett
On Thu, 2008-01-17 at 17:27 +1100, Andrew Bartlett wrote:
I'm not quite sure what I'm looking for here, sorry:
In Samba4, we don't yet have full schema validation. In some ways it just has not been a priority - we validate that the attribute and objectClasses exist, but not that they match up.
In using OpenLDAP, I'm hoping to avoid having to write that logic, so I stopped adding extensibleObject to all our objectClass values, and replaced it with samba4Top, contaning all the things that AD's top contains, but OpenLDAPs does not.
So far so good, but AD has: dn: CN=Domain-DNS,${SCHEMADN} objectClass: top objectClass: classSchema subClassOf: domain systemAuxiliaryClass: samDomain
Looking at http://www.grotan.com/ldap/microsoft.ext.schema
I created entries in my schema file like:
dITContentRule ( 1.2.840.113556.1.5.67 NAME 'domainDNS' AUX ( samDomain ) )
dITContentRule ( 1.2.840.113556.1.5.3 NAME 'samDomain' AUX ( samDomainBase ) )
This created two problems: It appears that you cannot create a ditContentRule for a non-structural objectClass (samDomain is AUXILIARY), and even if I do, I can't tack on the samba4Top on the end, because of:
Adding DomainDN: DC=samba,DC=example,DC=com (permitted to fail) ldb load failed: LDAP error 65 LDAP_OBJECT_CLASS_VIOLATION - <class 'samba4Top' not allowed by content rule 'domainDNS'> <>
Is there a different approach I should be taking? I need to extend 'top' without extending OpenLDAP's hardcoded top, and I need something that looks like dITcontentRule without the restrictions. Any hints?
I suppose I could just calculate the resultant set of (structuralclass | top | auxilirayclasses) and merge them into the MUST and MAY of that structural class.
Would this be the best (if ugly) way forward?
Andrew Bartlett
Andrew Bartlett wrote:
I'm not quite sure what I'm looking for here, sorry:
I'm not quite sure if I correctly understood what you're trying to do because I don't have access to all relevant schema definitions.
In using OpenLDAP, I'm hoping to avoid having to write that logic, so I stopped adding extensibleObject to all our objectClass values, and replaced it with samba4Top, contaning all the things that AD's top contains, but OpenLDAPs does not.
Could you please post definition of 'samba4Top'?
So far so good, but AD has: dn: CN=Domain-DNS,${SCHEMADN} objectClass: top objectClass: classSchema subClassOf: domain systemAuxiliaryClass: samDomain
This is the AD-specific schema entry which gets converted to a DIT content rule in the LDAPv3-compliant subschema subentry. Yes?
Looking at http://www.grotan.com/ldap/microsoft.ext.schema
I created entries in my schema file like:
dITContentRule ( 1.2.840.113556.1.5.67 NAME 'domainDNS' AUX ( samDomain ) )
dITContentRule ( 1.2.840.113556.1.5.3 NAME 'samDomain' AUX ( samDomainBase ) )
This created two problems: It appears that you cannot create a ditContentRule for a non-structural objectClass
Yes, see section 4.1.6. of RFC 4512. You should try not to violate this because leads to interop problems with LDAPv3 compliant implementations. (My web2ldap obeys DIT content rules governing STRUCTURAL object classes when showing select lists for choosing object classes when modifying an entry.)
(samDomain is AUXILIARY), and even if I do, I can't tack on the samba4Top on the end, because of:
How are 'domainDNS' and 'samDomain' defined? Is 'domainDNS' STRUCTURAL?
Just some wild guess since I don't have everything needed at hand: How about defining 'samba4Top' as ABSTRACT object class and derive 'samDomain' as AUXILIARY from it?
Ciao, Michael.
On Thu, 2008-01-17 at 12:49 +0100, Michael Ströder wrote:
Andrew Bartlett wrote:
I'm not quite sure what I'm looking for here, sorry:
I'm not quite sure if I correctly understood what you're trying to do because I don't have access to all relevant schema definitions.
In using OpenLDAP, I'm hoping to avoid having to write that logic, so I stopped adding extensibleObject to all our objectClass values, and replaced it with samba4Top, contaning all the things that AD's top contains, but OpenLDAPs does not.
Could you please post definition of 'samba4Top'?
I generate the schema from these 'AD format' LDIF files:
http://samba.org/~abartlet/ol-ad/schema.ldif
http://samba.org/~abartlet/ol-ad/schema_samba4.ldif
In schema_samba4 you will find samba4Top, which is a subset of Microsoft's top, cut down until OpenLDAP would load it.
So far so good, but AD has: dn: CN=Domain-DNS,${SCHEMADN} objectClass: top objectClass: classSchema subClassOf: domain systemAuxiliaryClass: samDomain
This is the AD-specific schema entry which gets converted to a DIT content rule in the LDAPv3-compliant subschema subentry. Yes?
Yeah, I convert the whole schema (via a munging program, skipping and renaming a few things) into:
http://samba.org/~abartlet/ol-ad/backend-schema.schema
Looking at http://www.grotan.com/ldap/microsoft.ext.schema
I created entries in my schema file like:
dITContentRule ( 1.2.840.113556.1.5.67 NAME 'domainDNS' AUX ( samDomain ) )
dITContentRule ( 1.2.840.113556.1.5.3 NAME 'samDomain' AUX ( samDomainBase ) )
This created two problems: It appears that you cannot create a ditContentRule for a non-structural objectClass
Yes, see section 4.1.6. of RFC 4512. You should try not to violate this because leads to interop problems with LDAPv3 compliant implementations. (My web2ldap obeys DIT content rules governing STRUCTURAL object classes when showing select lists for choosing object classes when modifying an entry.)
(samDomain is AUXILIARY), and even if I do, I can't tack on the samba4Top on the end, because of:
How are 'domainDNS' and 'samDomain' defined? Is 'domainDNS' STRUCTURAL?
Yes, domainDNS is structural, but samDomain and samDomainBase are auxillary.
Andrew Bartlett
Andrew Bartlett wrote:
I generate the schema from these 'AD format' LDIF files:
Is this directly dumped from AD without any mangling?
Is this what you will load in the LDAP server acting as backend? It looks somewhat tweaked to Samba's need.
But without further processing this would not load since naming attribute 'cn' is missing in the entry:
dn: cn=privilege,${SCHEMADN} objectClass: top objectClass: attributeSchema lDAPDisplayName: privilege isSingleValued: FALSE systemFlags: 17 systemOnly: TRUE schemaIDGUID: 7429BC94-CC6A-4481-8B2C-A97E316EB182 adminDisplayName: Privilege attributeID: 1.3.6.1.4.1.7165.4.1.7 attributeSyntax: 2.5.5.4 oMSyntax: 20
Obviously you have any pre-processing before adding this to OpenLDAP. But do you also add the naming attribute 'cn'?
I cannot load this schema file in my build of OpenLDAP HEAD. slapd won't start (but unfortunately without error message). Are you sure that every object class referenced by a DIT content rule is really there?
Ciao, Michael.
Michael Ströder wrote:
Andrew Bartlett wrote:
I cannot load this schema file in my build of OpenLDAP HEAD.
It seems that this is a monolithic schema file also containing standard attribute type declarations normally already defined within OpenLDAP's schema files. Are you planning to do it that way when deploying Samba 4 with OpenLDAP? I understand that there might be subtle differences between AD's schema declaration and how things are defined in RFCs.
But such a redefinition of standard schema elements would be problematic because OpenLDAP internally has hard-coded schema elements you cannot change by configuration. (These are just left as comments within the schema config files shipped with OpenLDAP.) And you don't know which schema elements will be transferred from schema files to the C code in the future.
Ciao, Michael.
On Fri, 2008-01-18 at 12:05 +0100, Michael Ströder wrote:
Michael Ströder wrote:
Andrew Bartlett wrote:
I cannot load this schema file in my build of OpenLDAP HEAD.
It seems that this is a monolithic schema file also containing standard attribute type declarations normally already defined within OpenLDAP's schema files. Are you planning to do it that way when deploying Samba 4 with OpenLDAP? I understand that there might be subtle differences between AD's schema declaration and how things are defined in RFCs.
But such a redefinition of standard schema elements would be problematic because OpenLDAP internally has hard-coded schema elements you cannot change by configuration. (These are just left as comments within the schema config files shipped with OpenLDAP.) And you don't know which schema elements will be transferred from schema files to the C code in the future.
Indeed I do not! I find this to be a right royal pain, and as such maintain a file (attached) that is the crude input to the conversion program, setting out the mappings that must occur.
Trying to determine where AD diverges from the schema OpenLDAP uses is not a task I've yet taken on.
Andrew Bartlett
--On Monday, January 21, 2008 8:31 AM +1100 Andrew Bartlett abartlet@samba.org wrote:
Trying to determine where AD diverges from the schema OpenLDAP uses is not a task I've yet taken on.
s/schema OpenLDAP uses/RFC definitions/
:P
That's one of the nightmares in dealing with AD. Things like making cn single valued causes no end to headaches.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
On Sun, 2008-01-20 at 14:16 -0800, Quanah Gibson-Mount wrote:
--On Monday, January 21, 2008 8:31 AM +1100 Andrew Bartlett abartlet@samba.org wrote:
Trying to determine where AD diverges from the schema OpenLDAP uses is not a task I've yet taken on.
s/schema OpenLDAP uses/RFC definitions/
:P
That's one of the nightmares in dealing with AD. Things like making cn single valued causes no end to headaches.
One of the tasks I need to do is solve, to some extent, this headache. I'm very interested to know of any existing mappings between AD's LDAP and the RFC variety.
Fedora DS has one, for it's AD sync plugin, but it only deals with users, and in to many respects it just defines new elements rather than mapping.
Are there any others that you know of? (or at least a table of the classes that Microsoft didn't mess with).
I strongly suspect I won't ever get to the stage of being able to use OpenLDAP's schema files, unless they are strictly broken up into files that do and don't conflict with Microsoft (which is probably not an OpenLDAP goal :-)
Andrew Bartlett
--On Monday, January 21, 2008 11:13 AM +1100 Andrew Bartlett abartlet@samba.org wrote:
One of the tasks I need to do is solve, to some extent, this headache. I'm very interested to know of any existing mappings between AD's LDAP and the RFC variety.
Fedora DS has one, for it's AD sync plugin, but it only deals with users, and in to many respects it just defines new elements rather than mapping.
Are there any others that you know of? (or at least a table of the classes that Microsoft didn't mess with).
At Stanford, "cn" and "telephoneNumber" were the two problematic ones I recall hitting. :)
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
Andrew Bartlett wrote:
I strongly suspect I won't ever get to the stage of being able to use OpenLDAP's schema files, unless they are strictly broken up into files that do and don't conflict with Microsoft (which is probably not an OpenLDAP goal :-)
Files provided by OpenLDAP are a mere dump of the contents of the related RFCs, but users are not required to use them. User-defined schema is user-defined schema and, although most of interoperability would probably break if you don't load core.schema (an significant portions of it are actually hardcoded), you don't need to use those files. So breaking things up, or extracting portions and copying them where they are needed by your application should not be an issue, given that they are pretty stable, since they're based on standard track documents. Of course, as soon as you change standard track definitions, you work against interoperability, but that's another issue.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------
On Mon, 2008-01-21 at 08:11 +0100, Pierangelo Masarati wrote:
Andrew Bartlett wrote:
I strongly suspect I won't ever get to the stage of being able to use OpenLDAP's schema files, unless they are strictly broken up into files that do and don't conflict with Microsoft (which is probably not an OpenLDAP goal :-)
Files provided by OpenLDAP are a mere dump of the contents of the related RFCs, but users are not required to use them. User-defined schema is user-defined schema and, although most of interoperability would probably break if you don't load core.schema (an significant portions of it are actually hardcoded), you don't need to use those files. So breaking things up, or extracting portions and copying them where they are needed by your application should not be an issue, given that they are pretty stable, since they're based on standard track documents. Of course, as soon as you change standard track definitions, you work against interoperability, but that's another issue.
But the moment I copy those definitions, I end up exactly where I am now, with files that are *not* updated when it is decided, for some perfectly reasonable reason or other, to place that attribute in the C code of slapd.
Andrew Bartlett
Andrew Bartlett wrote:
But the moment I copy those definitions, I end up exactly where I am now, with files that are *not* updated when it is decided, for some perfectly reasonable reason or other, to place that attribute in the C code of slapd.
Well, putting definitions in the code is basically related to the need of using those definitions internally for some purpose. I think this need was discussed at some point, in view of the availability of back-config, and Howard correctly pointed out that the load sequence could be formalized a little bit more, to require:
- load standard track schema - load modules (module-specific schema can be defined by modules) - load global configuration - load databases
In this way, there would be no need to have hardcoded standard track items, provided those required by slapd are loaded at some point.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------
On Mon, 2008-01-21 at 18:26 +1100, Andrew Bartlett wrote:
On Mon, 2008-01-21 at 08:11 +0100, Pierangelo Masarati wrote:
Andrew Bartlett wrote:
I strongly suspect I won't ever get to the stage of being able to use OpenLDAP's schema files, unless they are strictly broken up into files that do and don't conflict with Microsoft (which is probably not an OpenLDAP goal :-)
Files provided by OpenLDAP are a mere dump of the contents of the related RFCs, but users are not required to use them. User-defined schema is user-defined schema and, although most of interoperability would probably break if you don't load core.schema (an significant portions of it are actually hardcoded), you don't need to use those files. So breaking things up, or extracting portions and copying them where they are needed by your application should not be an issue, given that they are pretty stable, since they're based on standard track documents. Of course, as soon as you change standard track definitions, you work against interoperability, but that's another issue.
But the moment I copy those definitions, I end up exactly where I am now, with files that are *not* updated when it is decided, for some perfectly reasonable reason or other, to place that attribute in the C code of slapd.
To move this part of the discussion in a forward direction...
In Fedora DS, I was able to get a patch accepted to trim the 00core schema down to the really, really core stuff. I'm unsure if the same would even be possible with OpenLDAP, given the way schema is loaded (by listing each file)?
Thanks,
Andrew Bartlett
Andrew Bartlett wrote:
To move this part of the discussion in a forward direction...
In Fedora DS, I was able to get a patch accepted to trim the 00core schema down to the really, really core stuff. I'm unsure if the same would even be possible with OpenLDAP, given the way schema is loaded (by listing each file)?
I don't want to enter too much into details, but, to avoid breaking existing configurations that only include core.schema, nothing would prevent from defining the files
really_core.schema not_so_core.schema
and have a core.schema file consisting in
include really_core.schema include not_so_core.schema
The all you'd need to do would be to only load the relevant portion of the split.
However, I believe this is a moot point, since I expect most of the users to move to using back-config, which means that core.schema will no longer need to be around except for configuration initialization.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------
Pierangelo Masarati wrote:
Andrew Bartlett wrote:
To move this part of the discussion in a forward direction...
In Fedora DS, I was able to get a patch accepted to trim the 00core schema down to the really, really core stuff. I'm unsure if the same would even be possible with OpenLDAP, given the way schema is loaded (by listing each file)?
I don't want to enter too much into details, but, to avoid breaking existing configurations that only include core.schema, nothing would prevent from defining the files
really_core.schema not_so_core.schemaand have a core.schema file consisting in
include really_core.schema include not_so_core.schema
The all you'd need to do would be to only load the relevant portion of the split.
However, I believe this is a moot point, since I expect most of the users to move to using back-config, which means that core.schema will no longer need to be around except for configuration initialization.
Note that we also have a converted core.schema in core.ldif, and the same split could be applied there if desired.
On Fri, 2008-01-18 at 11:41 +0100, Michael Ströder wrote:
Andrew Bartlett wrote:
I generate the schema from these 'AD format' LDIF files:
Is this directly dumped from AD without any mangling?
Other than cutting it down (it is a partial schema, based on what we need at the moment), this is based on what AD presents.
Is this what you will load in the LDAP server acting as backend? It looks somewhat tweaked to Samba's need.
But without further processing this would not load since naming attribute 'cn' is missing in the entry:
This loads in Samba4, not into OpenLDAP, and our module chain fixed it up.
dn: cn=privilege,${SCHEMADN} objectClass: top objectClass: attributeSchema lDAPDisplayName: privilege isSingleValued: FALSE systemFlags: 17 systemOnly: TRUE schemaIDGUID: 7429BC94-CC6A-4481-8B2C-A97E316EB182 adminDisplayName: Privilege attributeID: 1.3.6.1.4.1.7165.4.1.7 attributeSyntax: 2.5.5.4 oMSyntax: 20
Obviously you have any pre-processing before adding this to OpenLDAP. But do you also add the naming attribute 'cn'?
I cannot load this schema file in my build of OpenLDAP HEAD. slapd won't start (but unfortunately without error message). Are you sure that every object class referenced by a DIT content rule is really there?
Indeed, this does not load, and that is my issue!
I've updated this one to almost load (needed to exlude memberOf, which is provided by OpenLDAP's memberOf module), with this error:
/home/data/samba/git/samba/source/st/dc/private/ldap/backend-schema.schema: line 4292 dITContentRule: Content Rule not for STRUCTURAL object class: "1.2.840.113556.1.5.3" slaptest: bad configuration file!
The problem is that indeed, this dITContentRule is for an AUXILIARY class. The other problems occour after I eliminate that rule.
Andrew Bartlett
openldap-technical@openldap.org
-
Andrew Bartlett -
Howard Chu -
Michael Ströder -
Pierangelo Masarati -
Quanah Gibson-Mount