I am using openldap 2.4. I have configured it with following configuration.
include /etc/ldap/schema/core.schema
include /etc/ldap/schema/cosine.schema
include /etc/ldap/schema/nis.schema
include /etc/ldap/schema/inetorgperson.schema
include /etc/ldap/schema/HFSchema.schema
include /etc/ldap/schema/ppolicy.schema
pidfile /var/run/slapd/slapd.pid
modulepath /usr/lib/ldap
moduleload back_hdb.la
moduleload ppolicy.la
database hdb
suffix "dc=example,dc=com"
rootdn "cn=admin,dc=example,dc=com"
rootpw {SSHA}xzW0DfNFHahvm/C68ZR4YvbZGFQJjfz5
overlay ppolicy
ppolicy_default "cn=DefaultPwdPolicy,ou=Policies,dc=example,dc=com"
ppolicy_use_lockout
ppolicy_hash_cleartext
Also I added default password policy
# DefaultPwdPolicy, Policies, example.com
dn: cn=DefaultPwdPolicy,ou=Policies,dc=example,dc=com
cn: DefaultPwdPolicy
pwdAttribute: 2.5.4.35
objectClass: pwdPolicy
objectClass: top
objectClass: device
pwdAllowUserChange: TRUE
pwdMaxAge: 7776000
pwdInHistory: 5
pwdCheckQuality: 2
pwdMinLength: 8
pwdExpireWarning: 432000
pwdLockoutDuration: 900
pwdMaxFailure: 3
pwdMustChange: TRUE
pwdSafeModify: TRUE
pwdLockout: TRUE
But still admin is able to create users without these constraints. How will I confirm if my ppolicy overlay is working? How can I test if these constraint are actually been applied.?
The only user that is free from the password policy constraints is the internal rootdn
user. You shouldn't use that yourself for anything. It is the user that slapd
itself uses to update the DIT. You should define another admin user, in the DIT, with the necessary permissions. Using the rootdn
user for admin tasks will bypass every constraint known to man.
To use the ppolicy
fully, you have to use the password policy request control and check for the corresponding response control in your code so you can discover impending expiry, grace periods, etc.