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 Policies

the 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
eof

At 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

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to