10:27 p.m.
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
--
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Samba Developer, Red Hat Inc.
12:25 a.m.
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
http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Samba Developer, Red Hat Inc.
3:49 a.m.
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.
2:16 p.m.
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
http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Samba Developer, Red Hat Inc.
2:41 a.m.
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?
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.
3:05 a.m.
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.
Ciao, Michael.
1:31 p.m.
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
--
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Samba Developer, Red Hat Inc.
2:16 p.m.
--On Monday, January 21, 2008 8:31 AM +1100 Andrew Bartlett
<abartlet(a)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
4:13 p.m.
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(a)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
--
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Samba Developer, Red Hat Inc.
8:25 p.m.
--On Monday, January 21, 2008 11:13 AM +1100 Andrew Bartlett
<abartlet(a)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
11:11 p.m.
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(a)sys-net.it
---------------------------------------
11:26 p.m.
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
http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Samba Developer, Red Hat Inc.
11:41 p.m.
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(a)sys-net.it
---------------------------------------
11:46 p.m.
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
http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Samba Developer, Red Hat Inc.
1:03 a.m.
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(a)sys-net.it
---------------------------------------
1:36 a.m.
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.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
2:36 p.m.
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
--
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Samba Developer, Red Hat Inc.
5793
days inactive
5797
days old
openldap-technical@openldap.org
16 comments
5 participants
participants (5)
-
Andrew Bartlett -
Howard Chu -
Michael Ströder -
Pierangelo Masarati -
Quanah Gibson-Mount