OS: Debian Etch Openldap version: 2.3.30
Hi all:
Moving towards housing configuration data within openldap, I have the directory working correctly and reading cn=config without any issues.
However, if the password-hash {K5KEY} is specified, slapd refuses to start and immediately reports:
olcPasswordHash: value #0: <olcPasswordHash> scheme not available ({K5KEY}) olcPasswordHash: value #0: <olcPasswordHash> no valid hashes found config error processing cn=config: <olcPasswordHash> no valid hashes found
I am guessing this has to do with the order modules and configuration are loaded -- however, I am not at all sure.
The smbk5pwd module is loaded and the hash directive works correctly via slapd.conf.
Any help would be much appreciated.
thank you,
Mustafa A. Hashmi wrote:
Moving towards housing configuration data within openldap, I have the directory working correctly and reading cn=config without any issues.
However, if the password-hash {K5KEY} is specified, slapd refuses to start and immediately reports:
olcPasswordHash: value #0: <olcPasswordHash> scheme not available ({K5KEY}) olcPasswordHash: value #0: <olcPasswordHash> no valid hashes found config error processing cn=config: <olcPasswordHash> no valid hashes found
I am guessing this has to do with the order modules and configuration are loaded -- however, I am not at all sure.
The smbk5pwd module is loaded and the hash directive works correctly via slapd.conf.
That sounds like a bug. In fact, {K5KEY} is loaded by smbk5pwd, so if in slapd.conf you correctly load the module __before__ using password-hash things work as expected. However, when the configuration is loaded from the back-config database, modules are loaded __after__ the global entry, which contains password-hash. Apparently, checking the value of the password-hash attribute must be deferred to __after__ loading the entire configuration. This might be true in general. I suggest you file an ITS for this issue http://www.openldap.org/its/.
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:
That sounds like a bug. In fact, {K5KEY} is loaded by smbk5pwd, so if in slapd.conf you correctly load the module __before__ using password-hash things work as expected. However, when the configuration is loaded from the back-config database, modules are loaded __after__ the global entry, which contains password-hash. Apparently, checking the value of the password-hash attribute must be deferred to __after__ loading the entire configuration. This might be true in general. I suggest you file an ITS for this issue http://www.openldap.org/its/.
If it's a general problem, then we're going to need to re-shuffle the layout of the cn=config tree so that global directives are processed after any modules are loaded. But I think password mechs are the only item that can be registered at runtime that currently have a problem.
Howard Chu wrote:
Pierangelo Masarati wrote:
That sounds like a bug. In fact, {K5KEY} is loaded by smbk5pwd, so if in slapd.conf you correctly load the module __before__ using password-hash things work as expected. However, when the configuration is loaded from the back-config database, modules are loaded __after__ the global entry, which contains password-hash. Apparently, checking the value of the password-hash attribute must be deferred to __after__ loading the entire configuration. This might be true in general. I suggest you file an ITS for this issue http://www.openldap.org/its/.
If it's a general problem, then we're going to need to re-shuffle the layout of the cn=config tree so that global directives are processed after any modules are loaded. But I think password mechs are the only item that can be registered at runtime that currently have a problem.
It seems to be so. I'm considering different approaches:
* force some sequentiality in parsing config entries; for example: - schema first - then modules (modules may rely on presence of schema) - then the rest but this is not ensuring the right ordering of thngs
* turn failed config parsing into a list of modifications to be recursively reapplied later until either success or a complete run thru the list results in no success This also does not ensure the right ordering
* change the layout so that config database parsing from LDIF is treated differently from slapd.conf, in two phases: - read-in - validation
In all the above cases there's no guarantee the original ordering is preserved, so the safest solution would be to keep a changelog of configuration to be rolled-in again at startup instead of relying on the configuration stored on disk.
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 8/9/07, Pierangelo Masarati ando@sys-net.it wrote:
That sounds like a bug. In fact, {K5KEY} is loaded by smbk5pwd, so if in slapd.conf you correctly load the module __before__ using password-hash things work as expected. However, when the configuration is loaded from the back-config database, modules are loaded __after__ the global entry, which contains password-hash. Apparently, checking the value of the password-hash attribute must be deferred to __after__ loading the entire configuration. This might be true in general. I suggest you file an ITS for this issue http://www.openldap.org/its/.
ITS filed : http://www.openldap.org/its/index.cgi?findid=5082
Thank you.
Pierangelo Masarati wrote:
Howard Chu wrote:
Pierangelo Masarati wrote:
That sounds like a bug. In fact, {K5KEY} is loaded by smbk5pwd, so if in slapd.conf you correctly load the module __before__ using password-hash things work as expected. However, when the configuration is loaded from the back-config database, modules are loaded __after__ the global entry, which contains password-hash. Apparently, checking the value of the password-hash attribute must be deferred to __after__ loading the entire configuration. This might be true in general. I suggest you file an ITS for this issue http://www.openldap.org/its/.
If it's a general problem, then we're going to need to re-shuffle the layout of the cn=config tree so that global directives are processed after any modules are loaded. But I think password mechs are the only item that can be registered at runtime that currently have a problem.
It seems to be so. I'm considering different approaches:
- force some sequentiality in parsing config entries; for example:
- schema first
- then modules (modules may rely on presence of schema)
True, the ppolicy module has this problem. I consider that a design flaw but we were specifically requested to write it that way. IMO modules should load their own schema and not have such external dependencies, which is generally how we've coded all the others.
- then the rest
but this is not ensuring the right ordering of thngs
Right. Also, modules may be used to load new syntaxes and matching rules. As such, schema needs to be loaded after modules, which is why I've ordered things that way in the current cn=config tree.
The simplest solution is to move any global options that may have module dependencies out of the top cn=config entry and into a subordinate entry that is parsed later. In this case it may be most appropriate to move olcPasswordHash into the database structures, and allow it to be set in the frontendDB and overridden in individual databases.
In all the above cases there's no guarantee the original ordering is preserved, so the safest solution would be to keep a changelog of configuration to be rolled-in again at startup instead of relying on the configuration stored on disk.
There should not be any other ordering dependencies.
Howard Chu wrote:
It seems to be so. I'm considering different approaches:
- force some sequentiality in parsing config entries; for example:
- schema first
- then modules (modules may rely on presence of schema)
True, the ppolicy module has this problem. I consider that a design flaw but we were specifically requested to write it that way. IMO modules should load their own schema and not have such external dependencies, which is generally how we've coded all the others.
I was not just concerned by issues like schema loaded from configuration, but also by issues like modules using stuff that depends on standard track schema, which modules could assume it's always available. Right now this is true for hardcoded schema, but might not be for configuration-loaded schema.
A possible approach would be to hardcode more of standard track, for example by using a "stdschema" module; for example, the dsaschema that's in contrib should do something like this.
- then the restbut this is not ensuring the right ordering of thngs
Right. Also, modules may be used to load new syntaxes and matching rules. As such, schema needs to be loaded after modules, which is why I've ordered things that way in the current cn=config tree.
The simplest solution is to move any global options that may have module dependencies
We know which have dependencies now, but more might gain dependencies later, as soon as they get abstracted and factored out.
out of the top cn=config entry and into a subordinate entry that is parsed later. In this case it may be most appropriate to move olcPasswordHash into the database structures, and allow it to be set in the frontendDB and overridden in individual databases.
In all the above cases there's no guarantee the original ordering is preserved, so the safest solution would be to keep a changelog of configuration to be rolled-in again at startup instead of relying on the configuration stored on disk.
There should not be any other ordering dependencies.
Not now. By carefully changing stuff we should be able to avoid further issues.
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 ---------------------------------------
openldap-software@openldap.org
-
Howard Chu -
Mustafa A. Hashmi -
Pierangelo Masarati