--On Wednesday, November 2, 2022 2:41 AM -0500 Jarett DeAngelis
<[email protected]> wrote:
You could simply load the ppolicy overlay in you configuration so that
the control is available, regardless of whether you intend to use it.
How is this done? In the LTB distribution there is a ppolicy ldif in the
schema directory of openldap/etc; no such file exists for "vanilla"
OpenLDAP and I'm not even sure if it would be compatible.
<https://www.openldap.org/doc/admin25/appendix-upgrading.html>
"B.2. ppolicy overlay
The overlay now implements version 10 of the ppolicy draft in full. This
includes the notion of a password administrator where applicable (as
determined by having a manage permission to the userPassword attribute) and
skips certain processing when there is no valid policy in effect or where
the operation is initiated by a password administrator. Many attributes are
now tagged with NO-USER-MODIFICATION in the schema, requiring the use of
relax control to modify them.
In OpenLDAP 2.4 the slapo-ppolicy(5) overlay relied on a separate schema
file to be included for it to function. This schema is now implemented
internally in the slapo-ppolicy module. When upgrading slapd.conf(5)
deployments the include statement for the schema must be removed. For
slapd-config(5) deployments, the config database must be exported via
slapcat and the old ppolicy schema removed from the export. The resulting
config database can then be imported."
No idea why the LTB project would ship a retired schema file, you'd need to
ask them.
The documentation describes the password policy overlay, but appears to
be in conf format rather than the ldifs we use now and there's no
indication as to what sort of "default" options would normally be
associated with permitting a client to bind, check passwords for login
and allow or reject the login.
https://www.openldap.org/doc/admin26/overlays.html (section 12.10.2) I
imagine there must be a reference for this somewhere as it has to be one
of the most common LDAP use cases?
I would note again that nothing in your log indicates that the lack of the
ppolicy overlay is the source of any problems. There is simply a warning
thrown and then the operation proceeds and completes normally with no
issues reported.
Since ppolicy is a database specific module, you would first add it to the
module load section of the global configuration (assuming it was built as a
module) and then instantiate it as an overlay on top of the backend, as
demonstrated in the code for test022-ppolicy:
dn: olcOverlay=ppolicy,olcDatabase={#}mdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcPPolicyConfig
olcOverlay: ppolicy
I don't know which database number your MDB database is, so you'd need to
fill that in above. There's no need to specify anything for the
configuration past that unless you intend to actually make use of the
overlay.
But again, nothing indicates the lack of it being present as the source of
any issues in your deployment.
Those were just truncated lines. Here is another example without the
truncation:
The logs again show that the sudo schema is missing from the system, but
that all operations executed do so correctly. Nothing in your logs
indicates any issues being caused by the lack of the ppolicy overlay being
instantiated.
So, if you want to remove all the reported issues from your logs, you can
instantiate ppolicy, and you can load the sudo schema. That may better
enable you to track down the actual root cause by removing extraneous noise.
Regards,
Quanah
