Adds support for ppolicy overlay. #31
Conversation
This adds support for the ppolicy overlay, by adding the necessary changes to the cn=config database. The user will be required to activate the ppolicy schema, and any password enforcement will rely on a user defined default password object at cn=passwordDefault,<olcSuffix>.
| if $ppolicy { | ||
| validate_re($pp_hash_cleartext, '^TRUE$|^FALSE$') | ||
| validate_re($pp_use_lockout, '^TRUE$|^FALSE$') | ||
| validate_re($pp_forward_updates, '^TRUE$|^FALSE$') |
There was a problem hiding this comment.
I would prefer these to be exposed as native booleans and do the conversion of true -> 'TRUE' & false -> 'FALSE' within the module, (maybe add a function to do that?). I'd also rather not abbreviate the ppolicy to pp in the parameter names, yeah they're long and wordy but it matches the other parameters. I also see 'pp' and think 'pretty print' 😄
|
The one nit with this is in the case of the server being a read-only replica, in order to increase lockout/bind failed counters in the read-write upstream directory the |
|
I've merged this (with some minor alterations) now that I've added preliminary Thanks for your contributions, I've been meaning to add |
|
Thank you for merging these changes. The overlays have been working fine on our setup with this ordering, but I agree that the OpenLDAP documentation is really confusing on that topic. We'd started working on some of these changes too, and I noticed that there's a puppet library function - bool2str - that converts a boolean to two strings. So adding another function to do this may not be necessary; something like: Also, thank you for adding preliminary support for the chain overlay (another area with confusing documentation!). We had started working on this, but were running into some issues, and we'll go from what you've done so far. |
I knew there was a
It took me most of last night to work out how to get chaining to work, as you say the documentation is confusing and I could only find examples using the old |
The user is required to load the schema but it's not needed to be able to enable the overlay so just document that its required. Requiring the schema meant it has to be included before the server which causes an error that surfaced when testing with Puppet 4.6.0.
This adds support for the ppolicy overlay, by adding the necessary
changes to the cn=config database. The user will be required to activate
the ppolicy schema, and any password enforcement will rely on a user
defined default password object at cn=passwordDefault,.