Re: ppolicy overlay - not seeming to function?

[Howard Chu <hyc@symas.com>]

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.

--
  -- Howard Chu
  CTO, Symas Corp.           http://www.symas.com
  Director, Highland Sun     http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/