--- Comment #4 from David Coutadeur <david.coutadeur(a)gmail.com> ---
(In reply to Ondřej Kuzník from comment #3)
On Fri, Nov 05, 2021 at 01:09:06PM +0000, openldap-its(a)openldap.org
>> What is your usecase where you'd need different modules in the same
> No particular use case.
> It's just that before ppm, LTB project maintained another module named
> "check-password", and maybe it can help the transition to announce that
> OpenLDAP support multiple modules at one time... But again there is no real use
Then I would wait until a compelling use case comes up before we
consider reverting that change.
>>> 2/ it does not seem to work. (ie the extended module is not launched). See
>>> below for my config and data.
>> Just checking you are actually building with --enable-modules?
> Yes indeed.
> If it can help:
> ./configure [...]
Yes, that's fine, checking your policy again:
- pwdCheckQuality is 2, great, but the password you're setting is hashed
already so it will just fail before considering whether the module
should be used
No it's not. Sorry I didn't send you the modification ldif:
- you are not using pwdUseCheckModule - the module configured will
actually be used even if dealing with plaintext passwords
Yes, it seems working with this parameter set inside the default policy!
I did'nt understand this parameter fully at first instance.
This parameter is quite new, isn't it? (specific to 2.6 release?) IMO it is
actually a big step in migration process. Maybe can you add this in the
migration steps from 2.5 to 2.6. (it does not seem to be documented here for
At least section 4.2.6 of the Behera draft implicitly suggests that
password administrators should be exempt from quality checking by being
able to "set or reset the password to a well-known value." Is that the
reason it wasn't being used for you or are you still having issues
regardless of the above?
I have used a non-admin account for password modification.
The manpage doesn't seem to document that the module is not used unless
pwdCheckQuality is also enabled. I'll see about fixing that, thanks.
> Thanks for the clarification.
> Actually, I meant the documentation of slapo-ppolicy (man page)
> it could be nice to explain:
> - what is deprecated
> - what is each attribute made for
That's already documented here:
Could you suggest any improvements to address whatever other confusion
you think exists?
The extended module is described at multiple places in the manual. Maybe quote
each time the minimum essential parameters implicated in the process?
The first occurrence where it is missing is for example:
Specify the path of a loadable module containing a
check_password() function for additional password quality checks. The use of
this module is described further below in the description of the
Note: The user-defined loadable module must be in slapd's
standard executable search PATH, or an absolute path must be provided.
Note: Use of a ppolicy_check_module is a non-standard extension
to the LDAP password policy proposal.
Anyway, many thanks for your help!
You are receiving this mail because:
You are on the CC list for the issue.