John Cooter wrote:
So, before I ask my question, here are my referenced objects, from a "slapcat -n 0": dn: olcDatabase={2}hdb,cn=config objectClass: olcDatabaseConfig objectClass: olcHdbConfig olcDatabase: {2}hdb olcDbDirectory: /var/lib/ldap olcDbIndex: objectClass eq,pres olcDbIndex: ou,cn,mail,surname,givenname eq,pres,sub structuralObjectClass: olcHdbConfig entryUUID: eb941fcc-bef3-1036-9d74-0d6e032eb747 creatorsName: cn=config createTimestamp: 20170426174545Z olcAccess: {0}to dn.base="" by self write by dn="cn=ldapadmin,dc=XXXXXXX ,dc=net" write by * read olcAccess: {1}to * by self write by dn="cn=ldapadmin,dc=XXXXXXX,dc=net" w rite by * read olcAccess: {2}to dn.subtree="ou=mail,ou=hosting,dc=XXXXXXX,dc=net" attrs= userPassword,UseAppPassword,children,entry,objectClass,cn,sn,uid by self w rite by dn="cn=ldapadmin,dc=XXXXXXX,dc=net" write by * auth by * read olcSuffix: dc=XXXXXXXX,dc=net olcRootDN: cn=ldapadmin,dc=XXXXXXX,dc=net olcRootPW:: e1NTSEF9K2p6YnhXL0xQTDJKZFFIZitac3l6RzVXaEN3UEhQUkc= entryCSN: 20170508155547.001404Z#000000#000#000000 modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth modifyTimestamp: 20170508155547Z
dn: olcOverlay={0}ppolicy,olcDatabase={2}hdb,cn=config objectClass: olcOverlayConfig objectClass: olcPPolicyConfig olcOverlay: {0}ppolicy olcPPolicyDefault: cn=passwordDefault,ou=policies,dc=XXXXXXX,dc=net olcPPolicyHashCleartext: FALSE olcPPolicyUseLockout: FALSE olcPPolicyForwardUpdates: FALSE structuralObjectClass: olcPPolicyConfig
the passwordDefaul policy exists in the correct location, and appears to apply to all user objects BUT
when I change a user object to a value that either violates the base policy (say, has only 4 characters instead of 5 or more), or would not conform to the check_password.so function, as established by various outside sources, it does not give me an error of any kind, and instead, writes the password to the DB and writes the following to the log:
Reread the slapo-ppolicy(5) manpage. You're making modifications using the rootDN, which is documented to ignore any configured policies.
May 10 11:00:05 ldapv slapd[1984]: conn=1007 op=0 EXT oid=1.3.6.1.4.1.1466.20037 May 10 11:00:05 ldapv slapd[1984]: conn=1007 op=0 STARTTLS May 10 11:00:05 ldapv slapd[1984]: conn=1007 op=0 RESULT oid= err=0 text= May 10 11:00:06 ldapv slapd[1984]: conn=1007 fd=11 TLS established tls_ssf=256 ssf=256 May 10 11:00:06 ldapv slapd[1984]: conn=1007 op=1 BIND dn="cn=ldapadmin,dc=XXXXXXX,dc=net" method=128 May 10 11:00:06 ldapv slapd[1984]: conn=1007 op=1 BIND dn="cn=ldapadmin,dc=XXXXXXX,dc=net" mech=SIMPLE ssf=0 May 10 11:00:06 ldapv slapd[1984]: conn=1007 op=1 RESULT tag=97 err=0 text= May 10 11:00:06 ldapv slapd[1984]: conn=1007 op=2 MOD dn="uid=USER,cn=TESTDOMAIN.com,ou=domain,ou=mail,ou=hosting,dc=XXXXXXX,dc=net" May 10 11:00:06 ldapv slapd[1984]: conn=1007 op=2 MOD attr=userPassword May 10 11:00:06 ldapv slapd[1984]: conn=1007 op=2 RESULT tag=103 err=0 text=
And the entry, as referenced by phpLDAPadmin, appears to correspond to the "bad" password. How can I go about confirming that the password policy is being enforced?
Bind as a regular user identity instead of the rootDN when making a change.