openldap-bugs October 2017

openldap-bugs@openldap.org

29 participants
41 discussions

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

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

27 Oct '17

mihai.munteanu(a)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 0

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

27 Oct '17

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.

1 0

Re: (ITS#8760) LMDB: seg fault on opening a new database
by hyc＠symas.com 26 Oct '17

26 Oct '17

github(a)nicwatson.org wrote: > Full_Name: Nic Watson > Version: LMDB 0.9.21 > OS: Ubuntu 16.04.3 LTS > URL: https://gist.github.com/jnwatson/86b43b0515fe552a087d741d4ab43922 > Submission from: (NULL) (108.56.136.246) > > > See the URL for the minimal C program to reproduce the crash and the gdb > backtrace. > > LMDB will seg fault in mdb_dbi_open when creating a new database if the > environment was opened read-only. Thanks for the report, but this doesn't seem like a bug. Trying to create something when the environment was opened read-only is clearly a misuse of the API, and SEGVs are expected when the API is misused. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#8761) Comment for SLAPD_OVER_RETCODE define in portable.h is incorrect
by metzen＠gmail.com 23 Oct '17

23 Oct '17

Full_Name: Matt McDonald Version: OS: URL: Submission from: (NULL) (2601:282:b01:175b:359:7f8e:53e6:7341) The comment for the SLAPD_OVER_RETCODE entry in include/portable.hin incorrectly describes it as the "Referential Integrity" overlay, when it should indicate the "return code" overlay. diff --git a/include/portable.hin b/include/portable.hin index 3b17ccf04..3e340b6c7 100644 --- a/include/portable.hin +++ b/include/portable.hin @@ -1020,7 +1020,7 @@ /* define for Referential Integrity overlay */ #undef SLAPD_OVER_REFINT -/* define for Referential Integrity overlay */ +/* define for return code overlay */ #undef SLAPD_OVER_RETCODE /* define for Rewrite/Remap overlay */

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs October 2017