openldap-bugs

openldap-bugs@openldap.org

1 participants
20962 discussions

RE: [EXTERNAL] (ITS#8762) Unlocking an account doesn't remove pwdFailureTime
by mihai.munteanu＠thalesgroup.com 31 Oct '17

31 Oct '17

Hello Jon, Have you reconsidered your resolution after my last comment related to the= password policy described in https://tools.ietf.org/html/draft-behera-ldap= -password-policy-10 ? Thanks, Kind regards, Mihai -----Original Message----- From: Jon C Kidder [mailto:jckidder@aep.com]=20 Sent: Friday, October 27, 2017 2:46 PM To: MUNTEANU Mihai-Adrian; openldap-its(a)OpenLDAP.org Subject: RE: [EXTERNAL] (ITS#8762) Unlocking an account doesn't remove pwdF= ailureTime This is not a bug. pwdFailureTime is only cleared after the first successful bind. If you're = manually unlocking the user's account it can be assumed that you've gone th= rough the exercise of ensuring the user is using the proper password. Perh= aps by setting a new temporary password? If you haven't gone through that = exercise 1 attempt vs multiple attempts is not going to matter. The user i= s going to lock their account again anyway. We've just recently deployed a password self-service tool and have accounte= d for this current behavior in our help desk procedures. Our cyber securit= y team loves this behavior. JON C KIDDER | MIDDLEWARE ADMINISTRATOR LEAD JCKIDDER(a)AEP.COM | D:614.716.4= 970 1 RIVERSIDE PLAZA, COLUMBUS, OH 43215 -----Original Message----- From: openldap-bugs [mailto:openldap-bugs-bounces@openldap.org] On Behalf O= f mihai.munteanu(a)thalesgroup.com Sent: Friday, October 27, 2017 3:48 AM To: openldap-its(a)OpenLDAP.org Subject: [EXTERNAL] (ITS#8762) Unlocking an account doesn't remove pwdFailu= reTime This is an EXTERNAL email. STOP. THINK before you CLICK links or OPEN attac= hments. If suspicious please forward to incidents(a)aep.com for review. ********************************************************************** Full_Name: Mihai Munteanu Version: 2.4.44 OS: CentOS7 x64 URL: https://urldefense.proofpoint.com/v2/url?u=3Dftp-3A__ftp.openldap.org_= incoming_&d=3DDwIBAg&c=3DgMbiD-Q9WoaRgoXZKCrSug&r=3DWacA_KdnzU1pvF8wEQ4v1A&= m=3D3fgtnQphBlucWYzXakB6baAXEq2msUxFLlsMdi1aZQY&s=3DfE28OfhKUqMQkynWWNTkl9-= sUN8henbPip3IgOunodI&e=3D Submission from: (NULL) (86.12.190.162) Scenario:=20 0. we have configured that after 3 login failed attempts, the account to be locked. 1. user test1 fails to login 3 times -> account is locked 2. admin unlocks test1's account and notify test1 user 3. user test1 tries 1 time to login using a wrong password and gets his acc= ount locked again. Expectation here: account should not be locked after first attempt of a wro= ng password, but after third attempt, as it was the case on step 1.=20 It turns out that it is locked again after first attempt due to the fact th= at on step 2, only pwdAccountLockedTime field is removed from LDAP, but not also pwdFailureTime fields. It seems pwdFailureTime is internally cleared only: - when test1 successfully authenticate (having his account unlocked) - admin changes test1's password See below my details: $>ldapsearch -x -b "cn=3Dtest1,ou=3Dusers,dc=3Dthales,dc=3Dcom" + ... pwdChangedTime: 20171027043554Z pwdFailureTime: 20171027052019.225837Z pwdFailureTime: 20171027052021.776604Z pwdFailureTime: 20171027052024.436413Z pwdAccountLockedTime: 20171027052024Z entryCSN: 20171027055105.381686Z#000000#000#000000 ... $>cat unlock.ldif: dn: cn=3Dtest1,ou=3Dusers,dc=3Dthales,dc=3Dcom changetype: modify delete: pwdAccountLockedTime - delete: pwdFailureTime $>ldapmodify -x -W -D "cn=3Dadmin,ou=3Dusers,dc=3Dthales,dc=3Dcom" -f unloc= k.ldif Enter LDAP Password:=20 modifying entry "cn=3Dtest1,ou=3Dusers,dc=3Dthales,dc=3Dcom" ldap_modify: Constraint violation (19) additional info: pwdFailureTime: no user modification allowed $>cat unlock.ldif dn: cn=3Dtest1,ou=3Dusers,dc=3Dthales,dc=3Dcom changetype: modify delete: pwdAccountLockedTime $>ldapmodify -x -W -D "cn=3Djamessmith,ou=3Dusers,dc=3Dthales,dc=3Dcom" -f = unlock.ldif Enter LDAP Password:=20 modifying entry "cn=3Dtest1,ou=3Dusers,dc=3Dthales,dc=3Dcom" $>ldapsearch -x -b "cn=3Dtest1,ou=3Dusers,dc=3Dthales,dc=3Dcom" + ... pwdChangedTime: 20171027043554Z pwdFailureTime: 20171027052019.225837Z pwdFailureTime: 20171027052021.776604Z pwdFailureTime: 20171027052024.436413Z entryCSN: 20171027055105.381686Z#000000#000#000000 ... Result: pwdAccountLockedTime is removed but pwdFailureTime is not automatic= ally removed also. Expected: since I'm not allowed to remove pwdFailureTime I would expect to = be automatically removed via removal of pwdAccountLockedTime.

1 0

Re: (ITS#8734) Fixes for multiple back-asyncmeta issues
by nivanova＠symas.com 30 Oct '17

30 Oct '17

Hi, A new version of the patch has been uploaded as ftp://ftp.openldap.org/incoming/nadezhda-ivanova-171030.patch It contains fixes to a couple of problems found after the initial submission: 1. A problem where asyncmeta could not proxy a request containing a \0 in the filter 2. An unnecessary and misleading log message, that logged the operation as timed out when it wasn't. ----- Original Message ----- From: "openldap-its" <openldap-its(a)OpenLDAP.org> To: nivanova(a)symas.com Sent: Wednesday, September 13, 2017 4:22:51 PM Subject: Re: (ITS#8734) Fixes for multiple back-asyncmeta issues *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** Thanks for your report to the OpenLDAP Issue Tracking System. Your report has been assigned the tracking number ITS#8734. One of our support engineers will look at your report in due course. Note that this may take some time because our support engineers are volunteers. They only work on OpenLDAP when they have spare time. If you need to provide additional information in regards to your issue report, you may do so by replying to this message. Note that any mail sent to openldap-its(a)openldap.org with (ITS#8734) in the subject will automatically be attached to the issue report. mailto:openldap-its@openldap.org?subject=(ITS#8734) You may follow the progress of this report by loading the following URL in a web browser: http://www.OpenLDAP.org/its/index.cgi?findid=8734 Please remember to retain your issue tracking number (ITS#8734) on any further messages you send to us regarding this report. If you don't then you'll just waste our time and yours because we won't be able to properly track the report. Please note that the Issue Tracking System is not intended to be used to seek help in the proper use of OpenLDAP Software. Such requests will be closed. OpenLDAP Software is user supported. http://www.OpenLDAP.org/support/ -------------- Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved.

1 0

(ITS#8764) A small typo in README
by believelinan＠aliyun.com 29 Oct '17

29 Oct '17

Full_Name: Nan Li Version: 2.4.45 OS: URL: Submission from: (NULL) (137.69.117.201) I download source code of version 2.4.45, found a small typo in README at line 32: 32 detailed instructions can be found in the OpenLDAP Admnistrator's where "Admnistrator" should be "Administrator".

1 0

Re: (ITS#8763) ACL scope warning
by Claude.Dube＠MUHC.MCGILL.CA 29 Oct '17

29 Oct '17

--0__=0ABB0B5BDFE312E48f9e8a93df938690918c0ABB0B5BDFE312E4 Content-type: multipart/alternative; Boundary="1__=0ABB0B5BDFE312E48f9e8a93df938690918c0ABB0B5BDFE312E4" --1__=0ABB0B5BDFE312E48f9e8a93df938690918c0ABB0B5BDFE312E4 Content-transfer-encoding: quoted-printable Content-type: text/plain; charset=US-ASCII Ryan, Thank for the information Claude = Ryan Tandy = <ryan(a)nardis.ca> = = To 10/28/2017 07:58 claude.dube(a)muhc.mcgill.ca = PM = cc openldap-its(a)OpenLDAP.org = Subj= ect Re: (ITS#8763) ACL scope warning= = = = = = = Hi Claude, Please use the openldap-technical(a)openldap.org mailing list for usage o= r configuration questions. If you post your slapd.conf to the list I'm sure someone will be able to point out the reason for the warning. This ITS will be closed. = --1__=0ABB0B5BDFE312E48f9e8a93df938690918c0ABB0B5BDFE312E4 Content-transfer-encoding: quoted-printable Content-type: text/html; charset=US-ASCII Content-Disposition: inline <html><body> Ryan, Thank for the information<b= r> Claude <img width=3D"16" height=3D"16" src=3D"cid:1__=3D0ABB0B5BDFE312E48f9e8a= 93d(a)isn.rtss.qc.ca" border=3D"0" alt=3D"Inactive hide details for Ryan = Tandy ---10/28/2017 07:58:38 PM---Ryan Tandy <ryan(a)nardis.ca>"><f= ont size=3D"2" color=3D"#424282" face=3D"sans-serif">Ryan Tandy ---10/2= 8/2017 07:58:38 PM---Ryan Tandy <ryan(a)nardis.ca> <table width=3D"100%" border=3D"0" cellspacing=3D"0" cellpadding=3D"0">= <tr valign=3D"top"><td style=3D"background-image:url(cid:2__=3D0ABB0B5B= DFE312E48f9e8a93d(a)isn.rtss.qc.ca); background-repeat: no-repeat; " widt= h=3D"40%"> <ul style=3D"padding-left: 72pt"><= b>Ryan Tandy <ryan(a)nardis.ca>  10/28/2017 07:58 PM</ul>= </td><td width=3D"60%"> <table width=3D"100%" border=3D"0" cellspacing=3D"0" cellpadding=3D"0">= <tr valign=3D"top"><td width=3D"1%"><img width=3D"58" height=3D"1" src=3D= "cid:3__=3D0ABB0B5BDFE312E48f9e8a93d@isn.rtss.qc.ca" border=3D"0" alt=3D= ""> <div align=3D"right">To</di= v></td><td width=3D"100%"><img width=3D"1" height=3D"1" src=3D"cid:3__=3D= 0ABB0B5BDFE312E48f9e8a93d(a)isn.rtss.qc.ca" border=3D"0" alt=3D""> <ul style=3D"padding-left: 7pt">cl= aude.dube(a)muhc.mcgill.ca</ul> </td></tr> <tr valign=3D"top"><td width=3D"1%"><img width=3D"58" height=3D"1" src=3D= "cid:3__=3D0ABB0B5BDFE312E48f9e8a93d@isn.rtss.qc.ca" border=3D"0" alt=3D= ""> <div align=3D"right">cc</di= v></td><td width=3D"100%"><img width=3D"1" height=3D"1" src=3D"cid:3__=3D= 0ABB0B5BDFE312E48f9e8a93d(a)isn.rtss.qc.ca" border=3D"0" alt=3D""> <ul style=3D"padding-left: 7pt">op= enldap-its(a)OpenLDAP.org</ul> </td></tr> <tr valign=3D"top"><td width=3D"1%"><img width=3D"58" height=3D"1" src=3D= "cid:3__=3D0ABB0B5BDFE312E48f9e8a93d@isn.rtss.qc.ca" border=3D"0" alt=3D= ""> <div align=3D"right">Subject</font= ></div></td><td width=3D"100%"><img width=3D"1" height=3D"1" src=3D"cid= :3__=3D0ABB0B5BDFE312E48f9e8a93d@isn.rtss.qc.ca" border=3D"0" alt=3D"">= <ul style=3D"padding-left: 7pt">Re= : (ITS#8763) ACL scope warning</ul> </td></tr> </table> <table border=3D"0" cellspacing=3D"0" cellpadding=3D"0"> <tr valign=3D"top"><td width=3D"58"><img width=3D"1" height=3D"1" src=3D= "cid:3__=3D0ABB0B5BDFE312E48f9e8a93d@isn.rtss.qc.ca" border=3D"0" alt=3D= ""></td><td width=3D"336"><img width=3D"1" height=3D"1" src=3D"cid:3__=3D= 0ABB0B5BDFE312E48f9e8a93d(a)isn.rtss.qc.ca" border=3D"0" alt=3D""></td></= tr> </table> </td></tr> </table> <tt>Hi Claude, Please use the openldap-technical(a)openldap.org mailing list for usage o= r configuration questions. If you post your slapd.conf to the list I'm <b= r> sure someone will be able to point out the reason for the warning. This ITS will be closed. </tt> </body></html>= --1__=0ABB0B5BDFE312E48f9e8a93df938690918c0ABB0B5BDFE312E4-- --0__=0ABB0B5BDFE312E48f9e8a93df938690918c0ABB0B5BDFE312E4 Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <1__=0ABB0B5BDFE312E48f9e8a93d(a)isn.rtss.qc.ca> Content-Transfer-Encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=0ABB0B5BDFE312E48f9e8a93df938690918c0ABB0B5BDFE312E4 Content-type: image/gif; name="pic11478.gif" Content-Disposition: inline; filename="pic11478.gif" Content-ID: <2__=0ABB0B5BDFE312E48f9e8a93d(a)isn.rtss.qc.ca> Content-Transfer-Encoding: base64 R0lGODlhWABDALP/AAAAAK04Qf79/o+Gm7WuwlNObwoJFCsoSMDAwGFsmIuezf///wAAAAAAAAAA AAAAACH5BAEAAAgALAAAAABYAEMAQAT/EMlJq704682770RiFMRinqggEUNSHIchG0BCfHhOjAuh EDeUqTASLCbBhQrhG7xis2j0lssNDopE4jfIJhDaggI8YB1sZeZgLVA9YVCpnGagVjV171aRVrYR RghXcAGFhoUETwYxcXNyADJ3GlcSKGAwLwllVC1vjIUHBWsFilKQdI8GA5IcpApeJQt8L09lmgkH LZikoU5wjqcyAMMFrJIDPAKvCFletKSev1HBw8KrxtjZ2tvc3d5VyKtCKW3jfz4uMKmq3xu4N0nK BVoJQmx2LGVOmrqNjjJf2hHAQo/eDwJGTKhQMcgQEEAnEjFS98+RnW3smGkZU6ncCWav/4wYOnAI TihRL/4FEwbp28BXMMcoscQCVxlepL4IGDSCyJyVQOu0o7CjmLN50OZlqWmyFy5/6yBBuji0AxFR M00oQAqNIstqI6qKHUsWRAEAvagsmfUEAImyxgbmUpJk3IklNUtJOUAVLoUr1+wqDGTE4zk+T6FG uQb3SizBCwatiiUgCBN8vrz+zFjVyQ8FWkOlg4NQiZMB5QS8QO3mpOaKnL0Z2EKvNMSILEThKhCg zMKPVxYJh23qm9KNW7pArPynMqZDiErsTMqI+LRi3QAgkFUbXpuFKhSYZALd0O5RKa2z9EYKBbpb qxIKsjUPRgD7I2XYV6wyrOw92ykExP8NW4URhknC5dKGE4v4NENQj2jXjmfNgOZDaXb5glRmXQ33 YEWQYNcZFnrYcIQLNzyTFDQNkXIff0ExVlY4srziQk43inZgL4rwxxINMvpFFAz1KOODHiu+4aEw NEjFl5B3JIKWKF3k6I9bfUGp5ZZcdunll5IA4cuHvQQJ5gcsoCWOOUwgltIwAKRxJgbIkJAQZEq0 2YliZnpZZ4BH3CnYOXldOUOfQoYDqF1LFHbXCrO8xmRsfoXDXJ6ChjCAH3QlhJcT6VWE6FCkfCco CgrMFsROrIEX3o2whVjWDjoJccN3LdggSGXLCdLEgHr1lyU3O3QxhgohNKXJCWv8JQr/PDdaqd6w 2rj1inLiGeiCJoDspAoQlYE6QWLSECehcWIYxIQES6zhbn1iImTHEQyqJ4eIxJJoUBc+3CbBuwZE V5cJPPkIjFDdeEabQbd6WgICTxiiz0f5dBKquXF6k4senwEhYGnKEFJeGrxUZy8dB8gmAXI/sPvH ESfCwVt5hTgYiqQqtdRNHQIU1PJ33ZqmzgE90OwLaoJcnMop1WiMmgkPHQRIrwgFuNV90A3doNKT mrKIN07AnGcI9BQjhCBN4RfA1qIZnMqorJCogKfGQnxSCDilTVIA0yl5ciTovgLuBDKFUDE9aQcw 9SA+rjSNf9/M1gxrj6VwDTS0IUSElMzBfsj0NFXR2kwsV1A5IF1grLgLL/r1R40BZEnuBWgmQEyb jqRwSAt6bqMCOFkvKFN2GPPkUzIm/SCF8z8pVzpbjVnMsy0vOr1hw3SaSRUhpY09v0z0J1FnwzPl fmh+xl4WtR0zGu24I4KbMQm3lnVu2oNWxI9W/lcyzA+mCKF4DBikxb/+UWtOGRiFP8qEwAayIgIA Ow== --0__=0ABB0B5BDFE312E48f9e8a93df938690918c0ABB0B5BDFE312E4 Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <3__=0ABB0B5BDFE312E48f9e8a93d(a)isn.rtss.qc.ca> Content-Transfer-Encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=0ABB0B5BDFE312E48f9e8a93df938690918c0ABB0B5BDFE312E4--

1 0

Re: (ITS#8763) ACL scope warning
by ryan＠nardis.ca 28 Oct '17

28 Oct '17

Hi Claude, Please use the openldap-technical(a)openldap.org mailing list for usage or configuration questions. If you post your slapd.conf to the list I'm sure someone will be able to point out the reason for the warning. This ITS will be closed.

1 0

(ITS#8763) ACL scope warning
by claude.dube＠muhc.mcgill.ca 28 Oct '17

28 Oct '17

Full_Name: Claude Version: 2.4.45 OS: entOS Linux release 7.3.1611 (Core) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (198.168.152.20) the slapd.conf openldap configuration file see below. slapd daemon is issuing ACL scope warning for unknown reason that ACL is in the slapd.conf warning messages : config_back_db_open: line 0: warning: cannot assess the validity of the ACL scope within backend naming context How that warning can be addressed? Thanks how to recreate warning messages based on slapd.conf below. I'd like to get of rid of that ACL scope warning Thanks, Claude ### - slapd is launched by this running command ### /usr/sbin/slapd -d acl # # output of slapd daemon # 59f51611 @(#) $OpenLDAP: slapd 2.4.45 (Sep 10 2017 16:37:12) $ root@templateldap:/a/admin/ldap/openldap-2.4.45/servers/slapd 59f51611 => access_allowed: search access to "cn=config" "objectClass" requested 59f51611 <= root access granted 59f51611 => access_allowed: search access granted by manage(=mwrscxd) 59f51611 => access_allowed: search access to "cn=schema,cn=config" "objectClass" requested 59f51611 <= root access granted 59f51611 => access_allowed: search access granted by manage(=mwrscxd) 59f51611 => access_allowed: search access to "cn={0}core,cn=schema,cn=config" "objectClass" requested 59f51611 <= root access granted 59f51611 => access_allowed: search access granted by manage(=mwrscxd) 59f51611 => access_allowed: search access to "cn={1}cosine,cn=schema,cn=config" "objectClass" requested 59f51611 <= root access granted 59f51611 => access_allowed: search access granted by manage(=mwrscxd) 59f51611 => access_allowed: search access to "cn={2}inetorgperson,cn=schema,cn=config" "objectClass" requested 59f51611 <= root access granted 59f51611 => access_allowed: search access granted by manage(=mwrscxd) 59f51611 => access_allowed: search access to "olcDatabase={-1}frontend,cn=config" "objectClass" requested 59f51611 <= root access granted 59f51611 => access_allowed: search access granted by manage(=mwrscxd) Backend ACL: access to dn.base="dc=example,dc=com" by * read 59f51611 => access_allowed: search access to "olcDatabase={0}config,cn=config" "objectClass" requested 59f51611 <= root access granted 59f51611 => access_allowed: search access granted by manage(=mwrscxd) Backend ACL: access to dn.base="cn=admin,cn=config" by * none 59f51611 => access_allowed: search access to "olcDatabase={1}mdb,cn=config" "objectClass" requested 59f51611 <= root access granted 59f51611 => access_allowed: search access granted by manage(=mwrscxd) Backend ACL: access to dn.children="dc=example,dc=com" by * search Backend ACL: access to dn.base="dc=example,dc=com" by * read Backend ACL: access to * by * none 59f51611 config_back_db_open: line 0: warning: cannot assess the validity of the ACL scope within backend naming context 59f51611 slapd starting #### - slapd.conf - ##### # # NOTES: inetorgperson picks up attributes and objectclasses # from all three schemas # # NB: RH Linux schemas in /etc/openldap # include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema # NO REFERRALS # DON'T bother with ARGS file pidfile /var/run/openldap/slapd.pid argsfile /var/run/openldap/slapd.args loglevel ACL disallow bind_anon # ##################################### # frontend database ##################################### # access to dn.base="dc=example,dc=com" by * read ####################################################################### # bdb database definitions # # replace example and com below with a suitable domain # # If you don't have a domain you can leave it since example.com # is reserved for experimentation or change them to My and inc ####################################################################### database mdb #access to dn.base="dc=example,dc=com" by * read access to dn.children="dc=example,dc=com" by * search access to dn.base="dc=example,dc=com" by * read suffix "dc=example, dc=com" # # superuser rootdn "cn=jimbob, dc=example, dc=com" rootpw dirtysecret # The database directory MUST exist prior to running slapd AND # change path as ncessary directory /var/lib/ldap # Indices to maintain for this directory # required if searches will use # unique id so equality match only index uid eq # allows general searching on commonname, givenname and email index cn,gn,mail eq,sub # allows multiple variants on surname searching index sn eq,sub # sub above includes subintial,subany,subfinal # optimise department searches index ou eq # if searches will include objectClass uncomment following # index objectClass eq # shows use of default index parameter index default eq,sub # indices missing - uses default eq,sub index telephonenumber # ##################################### # config database ##################################### # database config access to dn.base="cn=admin,cn=config" by * none rootdn "cn=admin,cn=config" rootpw {SSHA}rZGfPJkJYWy036tqoQb9jZ4Tz36c7ddG

1 0

RE: [EXTERNAL] (ITS#8762) Unlocking an account doesn't remove pwdFailureTime
by mihai.munteanu＠thalesgroup.com 27 Oct '17

27 Oct '17

According to https://tools.ietf.org/html/draft-behera-ldap-password-policy-= 10 , chapter 5.2.13. pwdMaxFailure This field is described as: "This attribute specifies the number of consecutive failed bind attempts af= ter which the password may not be used to authenticate." In first case, when user is just created, for example, he can fail to login= 3 times and accounts get locked, which means the "password may not be used= to authenticate", as stated above. However, after admin unlocks the account, the user is still registered with= 3 failed bind attempts (the pwdFailureTime is not deleted) but now the use= r can use the password to authenticate. This scenario contradicts the defin= ition of pwdFailureTime. Moreover, the pwdLockout attribute description says, on chapter 5.2.11 that= " This attribute indicates, when its value is "TRUE", that the password ma= y not be used to authenticate after a specified number of consecutive faile= d bind attempts. The maximum number of consecutive failed bind attempts is= specified in pwdMaxFailure." In our password policy, pwdLockout is set to TRUE but after admin unlocks t= est1 account, because pwdFailureTime is not cleared, it is considered that = there are already 3 consecutive failed bind attempts, am I right? However, in this case, the user is allowed to use the password for new auth= entication which contradicts the definition of pwdLockout field. Kind regards, Mihai (+40213032732)=20 -----Original Message----- From: Jon C Kidder [mailto:jckidder@aep.com]=20 Sent: Friday, October 27, 2017 2:46 PM To: MUNTEANU Mihai-Adrian; openldap-its(a)OpenLDAP.org Subject: RE: [EXTERNAL] (ITS#8762) Unlocking an account doesn't remove pwdF= ailureTime This is not a bug. pwdFailureTime is only cleared after the first successful bind. If you're = manually unlocking the user's account it can be assumed that you've gone th= rough the exercise of ensuring the user is using the proper password. Perh= aps by setting a new temporary password? If you haven't gone through that = exercise 1 attempt vs multiple attempts is not going to matter. The user i= s going to lock their account again anyway. We've just recently deployed a password self-service tool and have accounte= d for this current behavior in our help desk procedures. Our cyber securit= y team loves this behavior. JON C KIDDER | MIDDLEWARE ADMINISTRATOR LEAD JCKIDDER(a)AEP.COM | D:614.716.4= 970 1 RIVERSIDE PLAZA, COLUMBUS, OH 43215 -----Original Message----- From: openldap-bugs [mailto:openldap-bugs-bounces@openldap.org] On Behalf O= f mihai.munteanu(a)thalesgroup.com Sent: Friday, October 27, 2017 3:48 AM To: openldap-its(a)OpenLDAP.org Subject: [EXTERNAL] (ITS#8762) Unlocking an account doesn't remove pwdFailu= reTime This is an EXTERNAL email. STOP. THINK before you CLICK links or OPEN attac= hments. If suspicious please forward to incidents(a)aep.com for review. ********************************************************************** Full_Name: Mihai Munteanu Version: 2.4.44 OS: CentOS7 x64 URL: https://urldefense.proofpoint.com/v2/url?u=3Dftp-3A__ftp.openldap.org_= incoming_&d=3DDwIBAg&c=3DgMbiD-Q9WoaRgoXZKCrSug&r=3DWacA_KdnzU1pvF8wEQ4v1A&= m=3D3fgtnQphBlucWYzXakB6baAXEq2msUxFLlsMdi1aZQY&s=3DfE28OfhKUqMQkynWWNTkl9-= sUN8henbPip3IgOunodI&e=3D Submission from: (NULL) (86.12.190.162) Scenario:=20 0. we have configured that after 3 login failed attempts, the account to be locked. 1. user test1 fails to login 3 times -> account is locked 2. admin unlocks test1's account and notify test1 user 3. user test1 tries 1 time to login using a wrong password and gets his acc= ount locked again. Expectation here: account should not be locked after first attempt of a wro= ng password, but after third attempt, as it was the case on step 1.=20 It turns out that it is locked again after first attempt due to the fact th= at on step 2, only pwdAccountLockedTime field is removed from LDAP, but not also pwdFailureTime fields. It seems pwdFailureTime is internally cleared only: - when test1 successfully authenticate (having his account unlocked) - admin changes test1's password See below my details: $>ldapsearch -x -b "cn=3Dtest1,ou=3Dusers,dc=3Dthales,dc=3Dcom" + ... pwdChangedTime: 20171027043554Z pwdFailureTime: 20171027052019.225837Z pwdFailureTime: 20171027052021.776604Z pwdFailureTime: 20171027052024.436413Z pwdAccountLockedTime: 20171027052024Z entryCSN: 20171027055105.381686Z#000000#000#000000 ... $>cat unlock.ldif: dn: cn=3Dtest1,ou=3Dusers,dc=3Dthales,dc=3Dcom changetype: modify delete: pwdAccountLockedTime - delete: pwdFailureTime $>ldapmodify -x -W -D "cn=3Dadmin,ou=3Dusers,dc=3Dthales,dc=3Dcom" -f unloc= k.ldif Enter LDAP Password:=20 modifying entry "cn=3Dtest1,ou=3Dusers,dc=3Dthales,dc=3Dcom" ldap_modify: Constraint violation (19) additional info: pwdFailureTime: no user modification allowed $>cat unlock.ldif dn: cn=3Dtest1,ou=3Dusers,dc=3Dthales,dc=3Dcom changetype: modify delete: pwdAccountLockedTime $>ldapmodify -x -W -D "cn=3Djamessmith,ou=3Dusers,dc=3Dthales,dc=3Dcom" -f = unlock.ldif Enter LDAP Password:=20 modifying entry "cn=3Dtest1,ou=3Dusers,dc=3Dthales,dc=3Dcom" $>ldapsearch -x -b "cn=3Dtest1,ou=3Dusers,dc=3Dthales,dc=3Dcom" + ... pwdChangedTime: 20171027043554Z pwdFailureTime: 20171027052019.225837Z pwdFailureTime: 20171027052021.776604Z pwdFailureTime: 20171027052024.436413Z entryCSN: 20171027055105.381686Z#000000#000#000000 ... Result: pwdAccountLockedTime is removed but pwdFailureTime is not automatic= ally removed also. Expected: since I'm not allowed to remove pwdFailureTime I would expect to = be automatically removed via removal of pwdAccountLockedTime.

1 0

Re: (ITS#8762) Unlocking an account doesn't remove pwdFailureTime
by mihai.munteanu＠thalesgroup.com 27 Oct '17

27 Oct '17

--_000_73687a3a63cc4dd6950d893d7e7e73e9THSONEA01HUB06Ponegrp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 1. See below the contents of our password policy: # Search scope: sub # Search filter: (objectClass=3D*) # Total entries: 1 # # Generated by LDAP Account Manager (http://www.ldap-account-manager.org) on October 27, 2017 10:48 am # Versio= n: 5.5 version: 1 # Entry 1: cn=3DpasswordDefault,ou=3Dpolicies,dc=3Dthales,dc=3Dcom dn: cn=3DpasswordDefault,ou=3Dpolicies,dc=3Dthales,dc=3Dcom cn: passwordDefault createtimestamp: 20171004124029Z creatorsname: dc=3DManager,dc=3Dthales,dc=3Dcom entrycsn: 20171004124029.795969Z#000000#000#000000 entrydn: cn=3DpasswordDefault,ou=3Dpolicies,dc=3Dthales,dc=3Dcom entryuuid: f3031268-3d4c-1037-9198-453c4b052276 hassubordinates: FALSE modifiersname: dc=3DManager,dc=3Dthales,dc=3Dcom modifytimestamp: 20171004124029Z objectclass: top objectclass: device objectclass: pwdPolicy objectclass: pwdPolicyChecker pwdallowuserchange: TRUE pwdattribute: userPassword pwdcheckmodule: check_password.so pwdcheckquality: 2 pwdexpirewarning: 0 pwdfailurecountinterval: 0 pwdgraceauthnlimit: 0 pwdinhistory: 4 pwdlockout: TRUE pwdlockoutduration: 0 pwdmaxage: 7776000 pwdmaxfailure: 3 pwdminage: 0 pwdminlength: 8 pwdmustchange: FALSE pwdsafemodify: FALSE structuralobjectclass: device subschemasubentry: cn=3DSubschema ----------------- 2. we are using the lamcms from www.ldap-account-manager.org<http://www.lda= p-account-manager.org>. In the web interface there is a "Unlock account" bu= tton which we use. I suppose they are using the php ldap_modify() method in= order to remove the 'pwdAccountLockedTime' field. Of course, temporary mod= ifying their sources and trying to remove also the pwdFailureTime generates= the following error: "Was unable to remove attributes from DN: cn=3Dtest1,ou=3Dusers,dc=3Dthales= ,dc=3Dcom. LDAP error, server says: Constraint violation - pwdFailureTime: no user mod= ification allowed" We've contact also guys from ldap-account-manager.org but they said they ca= n't do anything on their side and suggested to contact you. Kind regards, Mihai --_000_73687a3a63cc4dd6950d893d7e7e73e9THSONEA01HUB06Ponegrp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"><head><META HTTP-EQUIV=3D"Content-Type" CONTENT= =3D"text/html; charset=3Dus-ascii"><meta name=3DGenerator content=3D"Micros= oft Word 14 (filtered medium)"><style></style></head><body lang=3DEN-US link=3Dblue vli= nk=3Dpurple><div class=3DWordSection1>1. See below = the contents of our password policy:<o:p></o:p>= # Search scope: sub<o:p></o:p># Search filter: = (objectClass=3D*)<o:p></o:p># Total entries: 1<= o:p></o:p>#<o:p></o:p># Generated by LDAP Account Manager<o:p></o:p>(<a href=3D"http://www.ldap-account-manager.org">http://www.ldap-account-= manager.org</a>) on October 27, 2017 10:48 am # Version: 5.5<o:p></o:p>= <o:p> </o:p>versio= n: 1<o:p></o:p><o:p> </o:p># Entry 1: cn=3DpasswordDefault,ou=3Dpolicies,dc=3Dthales,dc= =3Dcom<o:p></o:p>dn: cn=3DpasswordDefault,ou=3D= policies,dc=3Dthales,dc=3Dcom<o:p></o:p>cn: pas= swordDefault<o:p></o:p>createtimestamp: 2017100= 4124029Z<o:p></o:p>creatorsname: dc=3DManager,d= c=3Dthales,dc=3Dcom<o:p></o:p>entrycsn: 2017100= 4124029.795969Z#000000#000#000000<o:p></o:p>ent= rydn: cn=3DpasswordDefault,ou=3Dpolicies,dc=3Dthales,dc=3Dcom<o:p></o:p></p= >entryuuid: f3031268-3d4c-1037-9198-453c4b052276<o:= p></o:p>hassubordinates: FALSE<o:p></o:p><p= class=3DMsoPlainText>modifiersname: dc=3DManager,dc=3Dthales,dc=3Dcom<o:p>= </o:p>modifytimestamp: 20171004124029Z<o:p></o:= p>objectclass: top<o:p></o:p>objectclass: device<o:p></o:p>objectc= lass: pwdPolicy<o:p></o:p>objectclass: pwdPolic= yChecker<o:p></o:p>pwdallowuserchange: TRUE<o:p= ></o:p>pwdattribute: userPassword<o:p></o:p></p= >pwdcheckmodule: check_password.so<o:p></o:p><p= class=3DMsoPlainText>pwdcheckquality: 2<o:p></o:p>pwdexpirewarning: 0<o:p></o:p>pwdfailurecou= ntinterval: 0<o:p></o:p>pwdgraceauthnlimit: 0<o= :p></o:p>pwdinhistory: 4<o:p></o:p>pwdlockout: TRUE<o:p></o:p>pwdl= ockoutduration: 0<o:p></o:p>pwdmaxage: 7776000<= o:p></o:p>pwdmaxfailure: 3<o:p></o:p>pwdminage: 0<o:p></o:p>pwdmin= length: 8<o:p></o:p>pwdmustchange: FALSE<o:p></= o:p>pwdsafemodify: FALSE<o:p></o:p>structuralobjectclass: device<o:p></o:p>subschemasubentry: cn=3DSubschema<o:p></o:p><o:p> </o:p>-----------------<o:p></= o:p>2. we are using the lamcms from <a href=3D"= http://www.ldap-account-manager.org">www.ldap-account-manager.org</a>. In t= he web interface there is a "Unlock account" button which we use.= I suppose they are using the php ldap_modify() method in order to remove t= he 'pwdAccountLockedTime' field. Of course, temporary modifying their sourc= es and trying to remove also the pwdFailureTime generates the following err= or: <o:p></o:p>"Was unable to remove attri= butes from DN: cn=3Dtest1,ou=3Dusers,dc=3Dthales,dc=3Dcom.<o:p></o:p><p= class=3DMsoPlainText>LDAP error, server says: Constraint violation - pwdFa= ilureTime: no user modification allowed"<o:p></o:p>We've contact also guys from ldap-account-manager.org but they sai= d they can't do anything on their side and suggested to contact you.<o:p></= o:p><o:p> </o:p><o:p> </o:p>= Kind regards,<o:p></o:p>Mihai<o:p></o:p><o:p> </o:p></div></body></html>= --_000_73687a3a63cc4dd6950d893d7e7e73e9THSONEA01HUB06Ponegrp_--

1 0

RE: (ITS#8762) Unlocking an account doesn't remove pwdFailureTime
by mihai.munteanu＠thalesgroup.com 27 Oct '17

27 Oct '17

--_002_D204E7513BE6154188ADA82EFFA18AC69B58B3FFFFTHSONEA01CMS0_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCjEuIFNlZSBhdHRhY2hlZCBhbmQgYmVsb3cgdGhlIGNvbnRlbnRzIG9mIG91ciBwYXNzd29y ZCBwb2xpY3k6DQojIFNlYXJjaCBzY29wZTogc3ViDQojIFNlYXJjaCBmaWx0ZXI6IChvYmplY3RD bGFzcz0qKQ0KIyBUb3RhbCBlbnRyaWVzOiAxDQojDQojIEdlbmVyYXRlZCBieSBMREFQIEFjY291 bnQgTWFuYWdlcg0KKGh0dHA6Ly93d3cubGRhcC1hY2NvdW50LW1hbmFnZXIub3JnKSBvbiBPY3Rv YmVyIDI3LCAyMDE3IDEwOjQ4IGFtICMgVmVyc2lvbjogNS41DQoNCnZlcnNpb246IDENCg0KIyBF bnRyeSAxOiBjbj1wYXNzd29yZERlZmF1bHQsb3U9cG9saWNpZXMsZGM9dGhhbGVzLGRjPWNvbQ0K ZG46IGNuPXBhc3N3b3JkRGVmYXVsdCxvdT1wb2xpY2llcyxkYz10aGFsZXMsZGM9Y29tDQpjbjog cGFzc3dvcmREZWZhdWx0DQpjcmVhdGV0aW1lc3RhbXA6IDIwMTcxMDA0MTI0MDI5Wg0KY3JlYXRv cnNuYW1lOiBkYz1NYW5hZ2VyLGRjPXRoYWxlcyxkYz1jb20NCmVudHJ5Y3NuOiAyMDE3MTAwNDEy NDAyOS43OTU5NjlaIzAwMDAwMCMwMDAjMDAwMDAwDQplbnRyeWRuOiBjbj1wYXNzd29yZERlZmF1 bHQsb3U9cG9saWNpZXMsZGM9dGhhbGVzLGRjPWNvbQ0KZW50cnl1dWlkOiBmMzAzMTI2OC0zZDRj LTEwMzctOTE5OC00NTNjNGIwNTIyNzYNCmhhc3N1Ym9yZGluYXRlczogRkFMU0UNCm1vZGlmaWVy c25hbWU6IGRjPU1hbmFnZXIsZGM9dGhhbGVzLGRjPWNvbQ0KbW9kaWZ5dGltZXN0YW1wOiAyMDE3 MTAwNDEyNDAyOVoNCm9iamVjdGNsYXNzOiB0b3ANCm9iamVjdGNsYXNzOiBkZXZpY2UNCm9iamVj dGNsYXNzOiBwd2RQb2xpY3kNCm9iamVjdGNsYXNzOiBwd2RQb2xpY3lDaGVja2VyDQpwd2RhbGxv d3VzZXJjaGFuZ2U6IFRSVUUNCnB3ZGF0dHJpYnV0ZTogdXNlclBhc3N3b3JkDQpwd2RjaGVja21v ZHVsZTogY2hlY2tfcGFzc3dvcmQuc28NCnB3ZGNoZWNrcXVhbGl0eTogMg0KcHdkZXhwaXJld2Fy bmluZzogMA0KcHdkZmFpbHVyZWNvdW50aW50ZXJ2YWw6IDANCnB3ZGdyYWNlYXV0aG5saW1pdDog MA0KcHdkaW5oaXN0b3J5OiA0DQpwd2Rsb2Nrb3V0OiBUUlVFDQpwd2Rsb2Nrb3V0ZHVyYXRpb246 IDANCnB3ZG1heGFnZTogNzc3NjAwMA0KcHdkbWF4ZmFpbHVyZTogMw0KcHdkbWluYWdlOiAwDQpw d2RtaW5sZW5ndGg6IDgNCnB3ZG11c3RjaGFuZ2U6IEZBTFNFDQpwd2RzYWZlbW9kaWZ5OiBGQUxT RQ0Kc3RydWN0dXJhbG9iamVjdGNsYXNzOiBkZXZpY2UNCnN1YnNjaGVtYXN1YmVudHJ5OiBjbj1T dWJzY2hlbWENCg0KLS0tLS0tLS0tLS0tLS0tLS0NCjIuIHdlIGFyZSB1c2luZyB0aGUgbGFtY21z IGZyb20gd3d3LmxkYXAtYWNjb3VudC1tYW5hZ2VyLm9yZy4gSW4gdGhlIHdlYiBpbnRlcmZhY2Ug dGhlcmUgaXMgYSAiVW5sb2NrIGFjY291bnQiIGJ1dHRvbiB3aGljaCB3ZSB1c2UuIEkgc3VwcG9z ZSB0aGV5IGFyZSB1c2luZyB0aGUgcGhwIGxkYXBfbW9kaWZ5KCkgbWV0aG9kIGluIG9yZGVyIHRv IHJlbW92ZSB0aGUgJ3B3ZEFjY291bnRMb2NrZWRUaW1lJyBmaWVsZC4gT2YgY291cnNlLCB0ZW1w b3JhcnkgbW9kaWZ5aW5nIHRoZWlyIHNvdXJjZXMgYW5kIHRyeWluZyB0byByZW1vdmUgYWxzbyB0 aGUgcHdkRmFpbHVyZVRpbWUgZ2VuZXJhdGVzIHRoZSBmb2xsb3dpbmcgZXJyb3I6IA0KIldhcyB1 bmFibGUgdG8gcmVtb3ZlIGF0dHJpYnV0ZXMgZnJvbSBETjogY249dGVzdDEsb3U9dXNlcnMsZGM9 dGhhbGVzLGRjPWNvbS4NCkxEQVAgZXJyb3IsIHNlcnZlciBzYXlzOiBDb25zdHJhaW50IHZpb2xh dGlvbiAtIHB3ZEZhaWx1cmVUaW1lOiBubyB1c2VyIG1vZGlmaWNhdGlvbiBhbGxvd2VkIg0KV2Un dmUgY29udGFjdCBhbHNvIGd1eXMgZnJvbSBsZGFwLWFjY291bnQtbWFuYWdlci5vcmcgYnV0IHRo ZXkgc2FpZCB0aGV5IGNhbid0IGRvIGFueXRoaW5nIG9uIHRoZWlyIHNpZGUgYW5kIHN1Z2dlc3Rl ZCB0byBjb250YWN0IHlvdS4NCg0KDQpLaW5kIHJlZ2FyZHMsDQpNaWhhaSAoKzQwMjEzMDMyNzMy KSANCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogTWljaGFlbCBTdHLDtmRl ciBbbWFpbHRvOm1pY2hhZWxAc3Ryb2VkZXIuY29tXSANClNlbnQ6IEZyaWRheSwgT2N0b2JlciAy NywgMjAxNyAxMTo1MyBBTQ0KVG86IE1VTlRFQU5VIE1paGFpLUFkcmlhbjsgb3BlbmxkYXAtaXRz QE9wZW5MREFQLm9yZw0KU3ViamVjdDogUmU6IChJVFMjODc2MikgVW5sb2NraW5nIGFuIGFjY291 bnQgZG9lc24ndCByZW1vdmUgcHdkRmFpbHVyZVRpbWUNCg0KbWloYWkubXVudGVhbnVAdGhhbGVz Z3JvdXAuY29tIHdyb3RlOg0KPiBTY2VuYXJpbzogDQo+IDAuIHdlIGhhdmUgY29uZmlndXJlZCB0 aGF0IGFmdGVyIDMgbG9naW4gZmFpbGVkIGF0dGVtcHRzLCB0aGUgYWNjb3VudCANCj4gdG8gYmUg bG9ja2VkLg0KPiAxLiB1c2VyIHRlc3QxIGZhaWxzIHRvIGxvZ2luIDMgdGltZXMgLT4gYWNjb3Vu dCBpcyBsb2NrZWQNCg0KUGxlYXNlIHByb3ZpZGUgdGhlIHBhc3N3b3JkIHBvbGljeSBhcyBMRElG Lg0KDQo+IDIuIGFkbWluIHVubG9ja3MgdGVzdDEncyBhY2NvdW50IGFuZCBub3RpZnkgdGVzdDEg dXNlcg0KDQpXaGljaCBleGFjdCBMREFQIG9wZXJhdGlvbiBpcyBkb25lIHdoZW4gImFkbWluIHVu bG9ja3MgdGVzdDEncyBhY2NvdW50Ii4NCkFyZSB5b3UganVzdCByZW1vdmluZyAncHdkQWNjb3Vu dExvY2tlZFRpbWUnPw0KDQpJJ20gYXNraW5nIGJlY2F1c2UgdGhlcmUgbWlnaHQgYmUgYSBtaXN1 bmRlcnN0YW5kaW5nIGhvdyB0aGF0IGlzIHN1cHBvc2VkIHRvIHdvcmsuIEluIHRoaXMgY2FzZSBp dCdzIGFuIHVzYWdlIHF1ZXN0aW9uIGJldHRlciB0byBiZSBkaXNjdXNzZWQgb24gb3BlbmxkYXAt dGVjaG5pY2FsIG1haWxpbmcgbGlzdC4NCg0KQ2lhbywgTWljaGFlbC4NCg== --_002_D204E7513BE6154188ADA82EFFA18AC69B58B3FFFFTHSONEA01CMS0_ Content-Type: application/octet-stream; name="pwdPolicy.ldif" Content-Description: pwdPolicy.ldif Content-Disposition: attachment; filename="pwdPolicy.ldif"; size=1196; creation-date="Fri, 27 Oct 2017 12:49:45 GMT"; modification-date="Fri, 27 Oct 2017 12:50:00 GMT" Content-Transfer-Encoding: base64 IyBTZWFyY2ggc2NvcGU6IHN1Yg0KIyBTZWFyY2ggZmlsdGVyOiAob2JqZWN0Q2xhc3M9KikNCiMg VG90YWwgZW50cmllczogMQ0KIw0KIyBHZW5lcmF0ZWQgYnkgTERBUCBBY2NvdW50IE1hbmFnZXIN CihodHRwOi8vd3d3LmxkYXAtYWNjb3VudC1tYW5hZ2VyLm9yZykgb24gT2N0b2JlciAyNywgMjAx NyAxMDo0OCBhbSAjIFZlcnNpb246IDUuNQ0KDQp2ZXJzaW9uOiAxDQoNCiMgRW50cnkgMTogY249 cGFzc3dvcmREZWZhdWx0LG91PXBvbGljaWVzLGRjPXRoYWxlcyxkYz1jb20NCmRuOiBjbj1wYXNz d29yZERlZmF1bHQsb3U9cG9saWNpZXMsZGM9dGhhbGVzLGRjPWNvbQ0KY246IHBhc3N3b3JkRGVm YXVsdA0KY3JlYXRldGltZXN0YW1wOiAyMDE3MTAwNDEyNDAyOVoNCmNyZWF0b3JzbmFtZTogZGM9 TWFuYWdlcixkYz10aGFsZXMsZGM9Y29tDQplbnRyeWNzbjogMjAxNzEwMDQxMjQwMjkuNzk1OTY5 WiMwMDAwMDAjMDAwIzAwMDAwMA0KZW50cnlkbjogY249cGFzc3dvcmREZWZhdWx0LG91PXBvbGlj aWVzLGRjPXRoYWxlcyxkYz1jb20NCmVudHJ5dXVpZDogZjMwMzEyNjgtM2Q0Yy0xMDM3LTkxOTgt NDUzYzRiMDUyMjc2DQpoYXNzdWJvcmRpbmF0ZXM6IEZBTFNFDQptb2RpZmllcnNuYW1lOiBkYz1N YW5hZ2VyLGRjPXRoYWxlcyxkYz1jb20NCm1vZGlmeXRpbWVzdGFtcDogMjAxNzEwMDQxMjQwMjla DQpvYmplY3RjbGFzczogdG9wDQpvYmplY3RjbGFzczogZGV2aWNlDQpvYmplY3RjbGFzczogcHdk UG9saWN5DQpvYmplY3RjbGFzczogcHdkUG9saWN5Q2hlY2tlcg0KcHdkYWxsb3d1c2VyY2hhbmdl OiBUUlVFDQpwd2RhdHRyaWJ1dGU6IHVzZXJQYXNzd29yZA0KcHdkY2hlY2ttb2R1bGU6IGNoZWNr X3Bhc3N3b3JkLnNvDQpwd2RjaGVja3F1YWxpdHk6IDINCnB3ZGV4cGlyZXdhcm5pbmc6IDANCnB3 ZGZhaWx1cmVjb3VudGludGVydmFsOiAwDQpwd2RncmFjZWF1dGhubGltaXQ6IDANCnB3ZGluaGlz dG9yeTogNA0KcHdkbG9ja291dDogVFJVRQ0KcHdkbG9ja291dGR1cmF0aW9uOiAwDQpwd2RtYXhh Z2U6IDc3NzYwMDANCnB3ZG1heGZhaWx1cmU6IDMNCnB3ZG1pbmFnZTogMA0KcHdkbWlubGVuZ3Ro OiA4DQpwd2RtdXN0Y2hhbmdlOiBGQUxTRQ0KcHdkc2FmZW1vZGlmeTogRkFMU0UNCnN0cnVjdHVy YWxvYmplY3RjbGFzczogZGV2aWNlDQpzdWJzY2hlbWFzdWJlbnRyeTogY249U3Vic2NoZW1hDQo= --_002_D204E7513BE6154188ADA82EFFA18AC69B58B3FFFFTHSONEA01CMS0_--

1 0

RE: [EXTERNAL] (ITS#8762) Unlocking an account doesn't remove pwdFailureTime
by jckidder＠aep.com 27 Oct '17

27 Oct '17

This is not a bug. pwdFailureTime is only cleared after the first successful bind. If you're = manually unlocking the user's account it can be assumed that you've gone th= rough the exercise of ensuring the user is using the proper password. Perh= aps by setting a new temporary password? If you haven't gone through that = exercise 1 attempt vs multiple attempts is not going to matter. The user i= s going to lock their account again anyway. We've just recently deployed a password self-service tool and have accounte= d for this current behavior in our help desk procedures. Our cyber securit= y team loves this behavior. JON C KIDDER | MIDDLEWARE ADMINISTRATOR LEAD JCKIDDER(a)AEP.COM | D:614.716.4970 1 RIVERSIDE PLAZA, COLUMBUS, OH 43215 -----Original Message----- From: openldap-bugs [mailto:openldap-bugs-bounces@openldap.org] On Behalf O= f mihai.munteanu(a)thalesgroup.com Sent: Friday, October 27, 2017 3:48 AM To: openldap-its(a)OpenLDAP.org Subject: [EXTERNAL] (ITS#8762) Unlocking an account doesn't remove pwdFailu= reTime This is an EXTERNAL email. STOP. THINK before you CLICK links or OPEN attac= hments. If suspicious please forward to incidents(a)aep.com for review. ********************************************************************** Full_Name: Mihai Munteanu Version: 2.4.44 OS: CentOS7 x64 URL: https://urldefense.proofpoint.com/v2/url?u=3Dftp-3A__ftp.openldap.org_= incoming_&d=3DDwIBAg&c=3DgMbiD-Q9WoaRgoXZKCrSug&r=3DWacA_KdnzU1pvF8wEQ4v1A&= m=3D3fgtnQphBlucWYzXakB6baAXEq2msUxFLlsMdi1aZQY&s=3DfE28OfhKUqMQkynWWNTkl9-= sUN8henbPip3IgOunodI&e=3D=20 Submission from: (NULL) (86.12.190.162) Scenario:=20 0. we have configured that after 3 login failed attempts, the account to be locked. 1. user test1 fails to login 3 times -> account is locked 2. admin unlocks test1's account and notify test1 user 3. user test1 tries 1 time to login using a wrong password and gets his acc= ount locked again. Expectation here: account should not be locked after first attempt of a wro= ng password, but after third attempt, as it was the case on step 1.=20 It turns out that it is locked again after first attempt due to the fact th= at on step 2, only pwdAccountLockedTime field is removed from LDAP, but not also pwdFailureTime fields. It seems pwdFailureTime is internally cleared only: - when test1 successfully authenticate (having his account unlocked) - admin changes test1's password See below my details: $>ldapsearch -x -b "cn=3Dtest1,ou=3Dusers,dc=3Dthales,dc=3Dcom" + ... pwdChangedTime: 20171027043554Z pwdFailureTime: 20171027052019.225837Z pwdFailureTime: 20171027052021.776604Z pwdFailureTime: 20171027052024.436413Z pwdAccountLockedTime: 20171027052024Z entryCSN: 20171027055105.381686Z#000000#000#000000 ... $>cat unlock.ldif: dn: cn=3Dtest1,ou=3Dusers,dc=3Dthales,dc=3Dcom changetype: modify delete: pwdAccountLockedTime - delete: pwdFailureTime $>ldapmodify -x -W -D "cn=3Dadmin,ou=3Dusers,dc=3Dthales,dc=3Dcom" -f unloc= k.ldif Enter LDAP Password:=20 modifying entry "cn=3Dtest1,ou=3Dusers,dc=3Dthales,dc=3Dcom" ldap_modify: Constraint violation (19) additional info: pwdFailureTime: no user modification allowed $>cat unlock.ldif dn: cn=3Dtest1,ou=3Dusers,dc=3Dthales,dc=3Dcom changetype: modify delete: pwdAccountLockedTime $>ldapmodify -x -W -D "cn=3Djamessmith,ou=3Dusers,dc=3Dthales,dc=3Dcom" -f = unlock.ldif Enter LDAP Password:=20 modifying entry "cn=3Dtest1,ou=3Dusers,dc=3Dthales,dc=3Dcom" $>ldapsearch -x -b "cn=3Dtest1,ou=3Dusers,dc=3Dthales,dc=3Dcom" + ... pwdChangedTime: 20171027043554Z pwdFailureTime: 20171027052019.225837Z pwdFailureTime: 20171027052021.776604Z pwdFailureTime: 20171027052024.436413Z entryCSN: 20171027055105.381686Z#000000#000#000000 ... Result: pwdAccountLockedTime is removed but pwdFailureTime is not automatic= ally removed also. Expected: since I'm not allowed to remove pwdFailureTime I would expect to = be automatically removed via removal of pwdAccountLockedTime.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs