[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: ppolicy overlay - not seeming to function?



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/