Matthieu Cerda wrote:
Hello folks,
I just stumbled upon a (maybe not) surprising technical issue with my OpenLDAP setup: ppolicy seems unable to update pwdAccountLockedTime on my users.
Setup:
OpenLDAP 2.4.40(+dfsg-1+deb8u2) on Debian jessie
Password policy and ACLs:
---8<--- dn: cn=default,ou=policies,dc=company,dc=com objectClass: top objectClass: person objectClass: pwdPolicy cn: passwordDefault cn: default pwdAttribute: userPassword sn: passwordDefault pwdAllowUserChange: TRUE pwdCheckQuality: 0 pwdExpireWarning: 0 pwdFailureCountInterval: 0 pwdGraceAuthNLimit: 0 pwdInHistory: 3 pwdLockout: TRUE pwdLockoutDuration: 300 pwdMaxAge: 0 pwdMaxFailure: 3 pwdMinAge: 0 pwdMinLength: 8 pwdMustChange: FALSE pwdSafeModify: FALSE ---8<---
---8<--- access to attrs=userPassword,shadowLastChange by dn="uid=mcerda,ou=people,dc=company,dc=com" write by self write by anonymous auth by * none
access to dn.base="" by * read
access to * by dn="uid=mcerda,ou=people,dc=company,dc=com" write by users read by * none ---8<---
- pwdFailureTime gets updated on each failed login attempt on users
until pwdMaxFailure is reached (3)
- Testing for account locking is done both by observing we appearance in
user object and using '-e ppolicy' on ldapsearch (ppolicy_use_lockout is enabled)
Everytime an user reaches pwdMaxFailure count, the debug log (level 65535) gives:
---8<--- 585947a5 => mdb_entry_get: found entry: "cn=default,ou=policies,dc=company,dc=com" 585947a5 mdb_entry_get: rc=0 585947a5 mdb_modify: uid=fbar,ou=people,dc=company,dc=com 585947a5 slap_queue_csn: queueing 0x65696ef4bce0 20161220150053.705334Z#000000#000#000000 585947a5 mdb_dn2entry("uid=fbar,ou=people,dc=company,dc=com") 585947a5 => mdb_dn2id("uid=fbar,ou=people,dc=company,dc=com") 585947a5 <= mdb_dn2id: got id=0x9 585947a5 => mdb_entry_decode: 585947a5 <= mdb_entry_decode 585947a5 mdb_modify_internal: 0x00000009: uid=fbar,ou=people,dc=company,dc=com 585947a5 => access_allowed: result not in cache (pwdAccountLockedTime) 585947a5 => access_allowed: delete access to "uid=fbar,ou=people,dc=company,dc=com" "pwdAccountLockedTime" requested 585947a5 => dn: [2] 585947a5 => acl_get: [3] attr pwdAccountLockedTime 585947a5 => acl_mask: access to entry "uid=fbar,ou=people,dc=company,dc=com", attr "pwdAccountLockedTime" requested 585947a5 => acl_mask: to all values by "", (=0) 585947a5 <= check a_dn_pat: uid=mcerda,ou=people,dc=company,dc=com 585947a5 <= check a_dn_pat: users 585947a5 <= check a_dn_pat: anonymous 585947a5 <= acl_mask: [3] applying read(=rscxd) (stop) 585947a5 <= acl_mask: [3] mask: read(=rscxd) 585947a5 => slap_access_allowed: delete access denied by read(=rscxd) 585947a5 => access_allowed: no more rules 585947a5 mdb_modify: modify failed (50) 585947a5 send_ldap_result: conn=1000 op=0 p=3 585947a5 send_ldap_result: err=50 matched="" text="" 585947a5 slap_graduate_commit_csn: removing 0x6569601047f0 20161220150053.705334Z#000000#000#000000 585947a5 send_ldap_response: msgid=1 tag=97 err=49 ---8<---
I can't see a reason why the update gets denied. Setting the global ACL to:
---8<--- access to * by dn="uid=mcerda,ou=people,dc=company,dc=com" write by * write ---8<---
fixes the issue (but I obviously not want an open bar slapd).
The documentation (http://www.openldap.org/doc/admin24/overlays.html) advises nothing about ACLs.
That is not the documentation, that is only a guide. The manpages are the authoritative documentation.
Is this and issue or a misconfiguration ?
Read the slapo-ppolicy(5) manpage.
Thanks in advance,
Hello Howard and Ozgur,
My answers are inlined in the following text.
I attached a copy of the slapd.conf if you would like to take a look.
Thanks for taking the time to answer my questions, it's appreciated. Have a nice day !
Howard Chu wrote :
Matthieu Cerda wrote:
Hello folks,
I just stumbled upon a (maybe not) surprising technical issue with my OpenLDAP setup: ppolicy seems unable to update pwdAccountLockedTime on my users.
(...)
The documentation (http://www.openldap.org/doc/admin24/overlays.html) advises nothing about ACLs.
That is not the documentation, that is only a guide. The manpages are the authoritative documentation.
Got it, i was misled by the '/doc' in the URL I guess.
Is this and issue or a misconfiguration ?
Read the slapo-ppolicy(5) manpage.
(Note: the default password policy I use has pwdLockout: TRUE, pwdMaxFailure: 3 and pwdLockoutDuration:0)
The manpage says nothing about ACL's except: 'Note that some of the policies do not take effect when the operation is performed with the rootdn identity; all the operations, when performed with any other identity, may be subjected to constraints, like access control.'
To clarify, I'm obviously not testing the ppolicy on a rootdn (the database does not have any actually), it is a random user without any specific privilege (besides beeing allowed access to * with read rights when authenticated).
My current understanding of ppolicy pwdLockout attribute is that when a user exceeds its pwdMaxFailure count when pwdLockout is TRUE, the overlay itself sets pwdAccountLockedTime internally according to the pwdLockoutDuration value, bypassing ACLs (in this case, my setup should work). If it is not the case, who needs write access to the attribute ?
Do I need a rootdn set, even if I do not use it, for this to work properly maybe ?
Thanks in advance,
Ozgur Karatas wrote: Hello,
The "deleted access denied by read" error has been fixed to OpenLDAP next version, I remember. I think it was from that slapo-ppolicy and has been fix in the 2.4.11 version.
Well this is a 2.4.40 OpenLDAP, it should be OK then ?
---8<--- # slapd -V @(#) $OpenLDAP: slapd (Jan 16 2016 23:00:08) $ root@chimera:/tmp/buildd/openldap-2.4.40+dfsg/debian/build/servers/slapd ---8<---
I also tried with LTB project's 2.4.44 release with the same results, so I doubt this is a known bug (or even a bug at all), I think my configuration is incorrect but I am currently incapable or seeing why.
Regards,
Ozgur Karatas
openldap-technical@openldap.org