Full_Name: Mihai Munteanu Version: 2.4.44 OS: CentOS7 x64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (86.12.190.162) Scenario: 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 account locked again. Expectation here: account should not be locked after first attempt of a wrong password, but after third attempt, as it was the case on step 1. It turns out that it is locked again after first attempt due to the fact that 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=test1,ou=users,dc=thales,dc=com" + ... pwdChangedTime: 20171027043554Z pwdFailureTime: 20171027052019.225837Z pwdFailureTime: 20171027052021.776604Z pwdFailureTime: 20171027052024.436413Z pwdAccountLockedTime: 20171027052024Z entryCSN: 20171027055105.381686Z#000000#000#000000 ... $>cat unlock.ldif: dn: cn=test1,ou=users,dc=thales,dc=com changetype: modify delete: pwdAccountLockedTime - delete: pwdFailureTime $>ldapmodify -x -W -D "cn=admin,ou=users,dc=thales,dc=com" -f unlock.ldif Enter LDAP Password: modifying entry "cn=test1,ou=users,dc=thales,dc=com" ldap_modify: Constraint violation (19) additional info: pwdFailureTime: no user modification allowed $>cat unlock.ldif dn: cn=test1,ou=users,dc=thales,dc=com changetype: modify delete: pwdAccountLockedTime $>ldapmodify -x -W -D "cn=jamessmith,ou=users,dc=thales,dc=com" -f unlock.ldif Enter LDAP Password: modifying entry "cn=test1,ou=users,dc=thales,dc=com" $>ldapsearch -x -b "cn=test1,ou=users,dc=thales,dc=com" + ... 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 automatically removed also. Expected: since I'm not allowed to remove pwdFailureTime I would expect to be automatically removed via removal of pwdAccountLockedTime.
mihai.munteanu@thalesgroup.com wrote: > Scenario: > 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 Please provide the password policy as LDIF. > 2. admin unlocks test1's account and notify test1 user Which exact LDAP operation is done when "admin unlocks test1's account". Are you just removing 'pwdAccountLockedTime'? I'm asking because there might be a misunderstanding how that is supposed to work. In this case it's an usage question better to be discussed on openldap-technical mailing list. Ciao, Michael.
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 through the exercise of ensuring the user is using the proper password. Perhaps 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 is going to lock their account again anyway. We've just recently deployed a password self-service tool and have accounted for this current behavior in our help desk procedures. Our cyber security team loves this behavior. JON C KIDDER | MIDDLEWARE ADMINISTRATOR LEAD JCKIDDER@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 Of mihai.munteanu@thalesgroup.com Sent: Friday, October 27, 2017 3:48 AM To: openldap-its@OpenLDAP.org Subject: [EXTERNAL] (ITS#8762) Unlocking an account doesn't remove pwdFailureTime This is an EXTERNAL email. STOP. THINK before you CLICK links or OPEN attachments. If suspicious please forward to incidents@aep.com for review. ********************************************************************** Full_Name: Mihai Munteanu Version: 2.4.44 OS: CentOS7 x64 URL: https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.openldap.org_incoming_&d=DwIBAg&c=gMbiD-Q9WoaRgoXZKCrSug&r=WacA_KdnzU1pvF8wEQ4v1A&m=3fgtnQphBlucWYzXakB6baAXEq2msUxFLlsMdi1aZQY&s=fE28OfhKUqMQkynWWNTkl9-sUN8henbPip3IgOunodI&e= Submission from: (NULL) (86.12.190.162) Scenario: 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 account locked again. Expectation here: account should not be locked after first attempt of a wrong password, but after third attempt, as it was the case on step 1. It turns out that it is locked again after first attempt due to the fact that 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=test1,ou=users,dc=thales,dc=com" + ... pwdChangedTime: 20171027043554Z pwdFailureTime: 20171027052019.225837Z pwdFailureTime: 20171027052021.776604Z pwdFailureTime: 20171027052024.436413Z pwdAccountLockedTime: 20171027052024Z entryCSN: 20171027055105.381686Z#000000#000#000000 ... $>cat unlock.ldif: dn: cn=test1,ou=users,dc=thales,dc=com changetype: modify delete: pwdAccountLockedTime - delete: pwdFailureTime $>ldapmodify -x -W -D "cn=admin,ou=users,dc=thales,dc=com" -f unlock.ldif Enter LDAP Password: modifying entry "cn=test1,ou=users,dc=thales,dc=com" ldap_modify: Constraint violation (19) additional info: pwdFailureTime: no user modification allowed $>cat unlock.ldif dn: cn=test1,ou=users,dc=thales,dc=com changetype: modify delete: pwdAccountLockedTime $>ldapmodify -x -W -D "cn=jamessmith,ou=users,dc=thales,dc=com" -f unlock.ldif Enter LDAP Password: modifying entry "cn=test1,ou=users,dc=thales,dc=com" $>ldapsearch -x -b "cn=test1,ou=users,dc=thales,dc=com" + ... 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 automatically removed also. Expected: since I'm not allowed to remove pwdFailureTime I would expect to be automatically removed via removal of pwdAccountLockedTime.
1. See attached and below the contents of our password policy: # Search scope: sub # Search filter: (objectClass=*) # Total entries: 1 # # Generated by LDAP Account Manager (http://www.ldap-account-manager.org) on October 27, 2017 10:48 am # Version: 5.5 version: 1 # Entry 1: cn=passwordDefault,ou=policies,dc=thales,dc=com dn: cn=passwordDefault,ou=policies,dc=thales,dc=com cn: passwordDefault createtimestamp: 20171004124029Z creatorsname: dc=Manager,dc=thales,dc=com entrycsn: 20171004124029.795969Z#000000#000#000000 entrydn: cn=passwordDefault,ou=policies,dc=thales,dc=com entryuuid: f3031268-3d4c-1037-9198-453c4b052276 hassubordinates: FALSE modifiersname: dc=Manager,dc=thales,dc=com 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=Subschema ----------------- 2. we are using the lamcms from www.ldap-account-manager.org. In the 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 the 'pwdAccountLockedTime' field. Of course, temporary modifying their sources and trying to remove also the pwdFailureTime generates the following error: "Was unable to remove attributes from DN: cn=test1,ou=users,dc=thales,dc=com. LDAP error, server says: Constraint violation - pwdFailureTime: no user modification allowed" We've contact also guys from ldap-account-manager.org but they said they can't do anything on their side and suggested to contact you. Kind regards, Mihai (+40213032732) -----Original Message----- From: Michael Ströder [mailto:michael@stroeder.com] Sent: Friday, October 27, 2017 11:53 AM To: MUNTEANU Mihai-Adrian; openldap-its@OpenLDAP.org Subject: Re: (ITS#8762) Unlocking an account doesn't remove pwdFailureTime mihai.munteanu@thalesgroup.com wrote: > Scenario: > 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 Please provide the password policy as LDIF. > 2. admin unlocks test1's account and notify test1 user Which exact LDAP operation is done when "admin unlocks test1's account". Are you just removing 'pwdAccountLockedTime'? I'm asking because there might be a misunderstanding how that is supposed to work. In this case it's an usage question better to be discussed on openldap-technical mailing list. Ciao, Michael.
1. See below the contents of our password policy: # Search scope: sub # Search filter: (objectClass=*) # Total entries: 1 # # Generated by LDAP Account Manager (http://www.ldap-account-manager.org) on October 27, 2017 10:48 am # Version: 5.5 version: 1 # Entry 1: cn=passwordDefault,ou=policies,dc=thales,dc=com dn: cn=passwordDefault,ou=policies,dc=thales,dc=com cn: passwordDefault createtimestamp: 20171004124029Z creatorsname: dc=Manager,dc=thales,dc=com entrycsn: 20171004124029.795969Z#000000#000#000000 entrydn: cn=passwordDefault,ou=policies,dc=thales,dc=com entryuuid: f3031268-3d4c-1037-9198-453c4b052276 hassubordinates: FALSE modifiersname: dc=Manager,dc=thales,dc=com 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=Subschema ----------------- 2. we are using the lamcms from www.ldap-account-manager.org<http://www.ldap-account-manager.org>. In the 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 the 'pwdAccountLockedTime' field. Of course, temporary modifying their sources and trying to remove also the pwdFailureTime generates the following error: "Was unable to remove attributes from DN: cn=test1,ou=users,dc=thales,dc=com. LDAP error, server says: Constraint violation - pwdFailureTime: no user modification allowed" We've contact also guys from ldap-account-manager.org but they said they can't do anything on their side and suggested to contact you. Kind regards, Mihai
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 after 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 user can use the password to authenticate. This scenario contradicts the definition 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 may not be used to authenticate after a specified number of consecutive failed 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 test1 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 authentication which contradicts the definition of pwdLockout field. Kind regards, Mihai (+40213032732) -----Original Message----- From: Jon C Kidder [mailto:jckidder@aep.com] Sent: Friday, October 27, 2017 2:46 PM To: MUNTEANU Mihai-Adrian; openldap-its@OpenLDAP.org Subject: RE: [EXTERNAL] (ITS#8762) Unlocking an account doesn't remove pwdFailureTime 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 through the exercise of ensuring the user is using the proper password. Perhaps 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 is going to lock their account again anyway. We've just recently deployed a password self-service tool and have accounted for this current behavior in our help desk procedures. Our cyber security team loves this behavior. JON C KIDDER | MIDDLEWARE ADMINISTRATOR LEAD JCKIDDER@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 Of mihai.munteanu@thalesgroup.com Sent: Friday, October 27, 2017 3:48 AM To: openldap-its@OpenLDAP.org Subject: [EXTERNAL] (ITS#8762) Unlocking an account doesn't remove pwdFailureTime This is an EXTERNAL email. STOP. THINK before you CLICK links or OPEN attachments. If suspicious please forward to incidents@aep.com for review. ********************************************************************** Full_Name: Mihai Munteanu Version: 2.4.44 OS: CentOS7 x64 URL: https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.openldap.org_incoming_&d=DwIBAg&c=gMbiD-Q9WoaRgoXZKCrSug&r=WacA_KdnzU1pvF8wEQ4v1A&m=3fgtnQphBlucWYzXakB6baAXEq2msUxFLlsMdi1aZQY&s=fE28OfhKUqMQkynWWNTkl9-sUN8henbPip3IgOunodI&e= Submission from: (NULL) (86.12.190.162) Scenario: 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 account locked again. Expectation here: account should not be locked after first attempt of a wrong password, but after third attempt, as it was the case on step 1. It turns out that it is locked again after first attempt due to the fact that 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=test1,ou=users,dc=thales,dc=com" + ... pwdChangedTime: 20171027043554Z pwdFailureTime: 20171027052019.225837Z pwdFailureTime: 20171027052021.776604Z pwdFailureTime: 20171027052024.436413Z pwdAccountLockedTime: 20171027052024Z entryCSN: 20171027055105.381686Z#000000#000#000000 ... $>cat unlock.ldif: dn: cn=test1,ou=users,dc=thales,dc=com changetype: modify delete: pwdAccountLockedTime - delete: pwdFailureTime $>ldapmodify -x -W -D "cn=admin,ou=users,dc=thales,dc=com" -f unlock.ldif Enter LDAP Password: modifying entry "cn=test1,ou=users,dc=thales,dc=com" ldap_modify: Constraint violation (19) additional info: pwdFailureTime: no user modification allowed $>cat unlock.ldif dn: cn=test1,ou=users,dc=thales,dc=com changetype: modify delete: pwdAccountLockedTime $>ldapmodify -x -W -D "cn=jamessmith,ou=users,dc=thales,dc=com" -f unlock.ldif Enter LDAP Password: modifying entry "cn=test1,ou=users,dc=thales,dc=com" $>ldapsearch -x -b "cn=test1,ou=users,dc=thales,dc=com" + ... 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 automatically removed also. Expected: since I'm not allowed to remove pwdFailureTime I would expect to be automatically removed via removal of pwdAccountLockedTime.
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] Sent: Friday, October 27, 2017 2:46 PM To: MUNTEANU Mihai-Adrian; openldap-its@OpenLDAP.org Subject: RE: [EXTERNAL] (ITS#8762) Unlocking an account doesn't remove pwdFailureTime 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 through the exercise of ensuring the user is using the proper password. Perhaps 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 is going to lock their account again anyway. We've just recently deployed a password self-service tool and have accounted for this current behavior in our help desk procedures. Our cyber security team loves this behavior. JON C KIDDER | MIDDLEWARE ADMINISTRATOR LEAD JCKIDDER@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 Of mihai.munteanu@thalesgroup.com Sent: Friday, October 27, 2017 3:48 AM To: openldap-its@OpenLDAP.org Subject: [EXTERNAL] (ITS#8762) Unlocking an account doesn't remove pwdFailureTime This is an EXTERNAL email. STOP. THINK before you CLICK links or OPEN attachments. If suspicious please forward to incidents@aep.com for review. ********************************************************************** Full_Name: Mihai Munteanu Version: 2.4.44 OS: CentOS7 x64 URL: https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.openldap.org_incoming_&d=DwIBAg&c=gMbiD-Q9WoaRgoXZKCrSug&r=WacA_KdnzU1pvF8wEQ4v1A&m=3fgtnQphBlucWYzXakB6baAXEq2msUxFLlsMdi1aZQY&s=fE28OfhKUqMQkynWWNTkl9-sUN8henbPip3IgOunodI&e= Submission from: (NULL) (86.12.190.162) Scenario: 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 account locked again. Expectation here: account should not be locked after first attempt of a wrong password, but after third attempt, as it was the case on step 1. It turns out that it is locked again after first attempt due to the fact that 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=test1,ou=users,dc=thales,dc=com" + ... pwdChangedTime: 20171027043554Z pwdFailureTime: 20171027052019.225837Z pwdFailureTime: 20171027052021.776604Z pwdFailureTime: 20171027052024.436413Z pwdAccountLockedTime: 20171027052024Z entryCSN: 20171027055105.381686Z#000000#000#000000 ... $>cat unlock.ldif: dn: cn=test1,ou=users,dc=thales,dc=com changetype: modify delete: pwdAccountLockedTime - delete: pwdFailureTime $>ldapmodify -x -W -D "cn=admin,ou=users,dc=thales,dc=com" -f unlock.ldif Enter LDAP Password: modifying entry "cn=test1,ou=users,dc=thales,dc=com" ldap_modify: Constraint violation (19) additional info: pwdFailureTime: no user modification allowed $>cat unlock.ldif dn: cn=test1,ou=users,dc=thales,dc=com changetype: modify delete: pwdAccountLockedTime $>ldapmodify -x -W -D "cn=jamessmith,ou=users,dc=thales,dc=com" -f unlock.ldif Enter LDAP Password: modifying entry "cn=test1,ou=users,dc=thales,dc=com" $>ldapsearch -x -b "cn=test1,ou=users,dc=thales,dc=com" + ... 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 automatically removed also. Expected: since I'm not allowed to remove pwdFailureTime I would expect to be automatically removed via removal of pwdAccountLockedTime.
I can't speak on behalf of the project but my position has not changed. If we pursue your interpretation of the standard to a logical conclusion then once the account is locked the user can never authenticate again. That is not the intent. The goal of any lockout mechanism is to make brute force password guessing impractical. They keyword here is guessing. How many attempts should your users have to legitimately guess their password? If your users don't know their password then they need to change it anyway. If your users can't remember the password they just changed then you have problems you can't address in code. If you want to give your users more than 3 attempts to guess their password then set pwdMaxFailure to that value. Don't set it to a lower value and then manually unlock their accounts multiple times. Unlocking a user's account so that they can continue to guess their password adds no value. JON C KIDDER | MIDDLEWARE ADMINISTRATOR LEAD JCKIDDER@AEP.COM | D:614.716.4970 1 RIVERSIDE PLAZA, COLUMBUS, OH 43215 -----Original Message----- From: MUNTEANU Mihai-Adrian [mailto:mihai.munteanu@thalesgroup.com] Sent: Tuesday, October 31, 2017 3:57 AM To: Jon C Kidder; openldap-its@OpenLDAP.org Subject: RE: [EXTERNAL] (ITS#8762) Unlocking an account doesn't remove pwdFailureTime Hello Jon, Have you reconsidered your resolution after my last comment related to the password policy described in https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dbehera-2Dldap-2Dpassword-2Dpolicy-2D10&d=DwIFAg&c=gMbiD-Q9WoaRgoXZKCrSug&r=WacA_KdnzU1pvF8wEQ4v1A&m=UitaRrJCJvbTRkNKnAG1MUsggW9F3FGUn7Nufv__g0U&s=xO5WwTWeNQanNDEj4KkwiizlVWEJDjYkkfXMVAglLZM&e= ? Thanks, Kind regards, Mihai -----Original Message----- From: Jon C Kidder [mailto:jckidder@aep.com] Sent: Friday, October 27, 2017 2:46 PM To: MUNTEANU Mihai-Adrian; openldap-its@OpenLDAP.org Subject: RE: [EXTERNAL] (ITS#8762) Unlocking an account doesn't remove pwdFailureTime 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 through the exercise of ensuring the user is using the proper password. Perhaps 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 is going to lock their account again anyway. We've just recently deployed a password self-service tool and have accounted for this current behavior in our help desk procedures. Our cyber security team loves this behavior. JON C KIDDER | MIDDLEWARE ADMINISTRATOR LEAD JCKIDDER@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 Of mihai.munteanu@thalesgroup.com Sent: Friday, October 27, 2017 3:48 AM To: openldap-its@OpenLDAP.org Subject: [EXTERNAL] (ITS#8762) Unlocking an account doesn't remove pwdFailureTime This is an EXTERNAL email. STOP. THINK before you CLICK links or OPEN attachments. If suspicious please forward to incidents@aep.com for review. ********************************************************************** Full_Name: Mihai Munteanu Version: 2.4.44 OS: CentOS7 x64 URL: https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.openldap.org_incoming_&d=DwIBAg&c=gMbiD-Q9WoaRgoXZKCrSug&r=WacA_KdnzU1pvF8wEQ4v1A&m=3fgtnQphBlucWYzXakB6baAXEq2msUxFLlsMdi1aZQY&s=fE28OfhKUqMQkynWWNTkl9-sUN8henbPip3IgOunodI&e= Submission from: (NULL) (86.12.190.162) Scenario: 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 account locked again. Expectation here: account should not be locked after first attempt of a wrong password, but after third attempt, as it was the case on step 1. It turns out that it is locked again after first attempt due to the fact that 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=test1,ou=users,dc=thales,dc=com" + ... pwdChangedTime: 20171027043554Z pwdFailureTime: 20171027052019.225837Z pwdFailureTime: 20171027052021.776604Z pwdFailureTime: 20171027052024.436413Z pwdAccountLockedTime: 20171027052024Z entryCSN: 20171027055105.381686Z#000000#000#000000 ... $>cat unlock.ldif: dn: cn=test1,ou=users,dc=thales,dc=com changetype: modify delete: pwdAccountLockedTime - delete: pwdFailureTime $>ldapmodify -x -W -D "cn=admin,ou=users,dc=thales,dc=com" -f unlock.ldif Enter LDAP Password: modifying entry "cn=test1,ou=users,dc=thales,dc=com" ldap_modify: Constraint violation (19) additional info: pwdFailureTime: no user modification allowed $>cat unlock.ldif dn: cn=test1,ou=users,dc=thales,dc=com changetype: modify delete: pwdAccountLockedTime $>ldapmodify -x -W -D "cn=jamessmith,ou=users,dc=thales,dc=com" -f unlock.ldif Enter LDAP Password: modifying entry "cn=test1,ou=users,dc=thales,dc=com" $>ldapsearch -x -b "cn=test1,ou=users,dc=thales,dc=com" + ... 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 automatically removed also. Expected: since I'm not allowed to remove pwdFailureTime I would expect to be automatically removed via removal of pwdAccountLockedTime.
Hello, I support Mihai view of the spec. Even if it please Jon use case, current behavior could be view as inconsistent with the spec, and more generally is inconsistent with commonly meet password policy systems. From a security point of view one attempt or tree (or five or ...) after the "unlock" is the same, brute force attempts are defeated. From a support/service desk point of view, this is not the same game. A commonly sane "pwMaxFailure" of 3 is good for daily fingling errors. But for holiday returns, one unlock for tree more attempts is often necessary and sufficient before the "heavy" password change process. In case of malicious attempts, we only one "by design" attempt after unlock, you just get DoS amplification and force a endless password change process for the user before the admins fix the source of the locking (real malicious source of attempts or not). If the project agree with John view of the interpretation of the actual implemented spec (which is not the latest published one), it could be documented with one liner in the ppolicy overlay doc. Emmanuel. PS: even is the email address say otherwise, I'm not in the same (sub)entity as Mihai and did not know Mihai before this ITS.
Ondrej, Since you are handling the draft 10 ppolicy work, please note one way or the other whether this is a bug that needs fixing or a misinterpretation of the RFC. Thanks!
I have created a patchset that attempts to address this and other ppolicy related issues here: https://git.openldap.org/openldap/openldap/-/merge_requests/77 Please review, test and let me know if this addresses the issue and if you have any other comments.
• 49504c16 by Ondřej Kuzník at 2020-07-03T20:42:14+00:00 Fix whitespace in ppolicy.c • 3e0447f4 by Ondřej Kuzník at 2020-07-03T20:42:14+00:00 ITS#7089 Skip lockout checks/modifications if password attribute missing • 3ec005a0 by Ondřej Kuzník at 2020-07-03T20:42:14+00:00 ITS#7788 Report if there is a policy that applies • 0b6ac3fd by Ondřej Kuzník at 2020-07-03T20:42:14+00:00 ITS#7788 Skip lockout processing if no policy applies • a030aacc by Ondřej Kuzník at 2020-07-03T20:42:14+00:00 ITS#7788 Allow pwdFailureTime tracking be disabled in policy • 376d5d65 by Ondřej Kuzník at 2020-07-03T20:42:14+00:00 ITS#7084 ACL of 'manage' gives pasword administrator access Password administrators can bypass safeModify, password quality checks and trigger reset if policy instructs the server to. • e05c09b9 by Ondřej Kuzník at 2020-07-03T20:42:14+00:00 ITS#8762 Clear pwdFailureTime on unlock • 5bf16496 by Ondřej Kuzník at 2020-07-03T20:42:14+00:00 ITS#7084, ITS#7089, ITS#7788 Update test to account for new functionality