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.

Andrew Bartlett wrote:

I generate the schema from these 'AD format' LDIF files:

http://samba.org/~abartlet/ol-ad/schema.ldif

Is this directly dumped from AD without any mangling?

http://samba.org/~abartlet/ol-ad/schema_samba4.ldif

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'?

http://samba.org/~abartlet/ol-ad/backend-schema.schema

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.

On Fri, 2008-01-18 at 12:05 +0100, Michael Ströder wrote:

Michael Ströder wrote:

...

Andrew Bartlett wrote:

...

http://samba.org/~abartlet/ol-ad/backend-schema.schema

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

http://samba.org/~abartlet/ol-ad/schema.ldif

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.

...

http://samba.org/~abartlet/ol-ad/schema_samba4.ldif

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'?

...

http://samba.org/~abartlet/ol-ad/backend-schema.schema

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

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

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

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

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

Note that we also have a converted core.schema in core.ldif, and the same split could be applied there if desired.