--On Wednesday, November 2, 2022 2:41 AM -0500 Jarett DeAngelis jarett@bioteam.net 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