Hi Brian,I believe the behaviour you describe is either by design, or at least consistent with the documentation. As per the Admin Guide:
http://www.openldap.org/doc/admin24/overlays.html#Password Policiesthe procedure is to load the module and schema, then instantiate the overlay, and then add your pwdPolicy objects. Note that it is OK for ppolicy_default to refer to an entry that doesn't exist yet, and the overlay does behave gracefully in that case.
Starting from a clean slapd install in wheezy or sid, following these steps: # ldapmodify -H ldapi:// -QY EXTERNAL << eof dn: cn=module{0},cn=config add: olcModuleLoad olcModuleLoad: ppolicy eof # ldapadd -H ldapi:// -QY EXTERNAL -f /etc/ldap/schema/ppolicy.ldif # ldapadd -H ldapi:// -QY EXTERNAL << eof dn: olcOverlay=ppolicy,olcDatabase={1}hdb,cn=config objectClass: olcPPolicyConfig olcPPolicyDefault: cn=ppolicy,dc=example,dc=com eofAt this point the module is loaded and the overlay activated, but it doesn't enforce any policy because the policy entry doesn't exist.
# ldapadd -H ldapi:// -x -D cn=admin,dc=example,dc=com -W << eof dn: cn=ppolicy,dc=example,dc=com objectClass: device objectClass: pwdPolicy pwdAttribute: userPassword eof Adding this entry, once the overlay is already active, succeeds.IMO this bug could either be closed, because it does work following those steps, or forwarded upstream with a low severity (but I suspect it might be rejected as a configuration mistake). What do you think?
thanks, Ryan
signature.asc
Description: OpenPGP digital signature