Full_Name: Dan Cushing Version: 2.3.36 OS: Solaris 9 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (71.76.187.82) When running OpenLDAP with the ppolicy overlay, the modifyTimestamp for a user entry is updated if the user attempts to login (bind) with an incorrect password. This is happening because the password lockout feature is enabled and the operational attribute 'pwdFailureTime' is being updated. It seems like this results in a misleading modifyTimestamp. Is it intended that the modifyTimestamp attribute be updated when operational attributes are updated? To reproduce the issue, compile with the ppolicy overlay and enable password lockout. Below I've included the entries for a minimal policy.ldif file that I tested with. Then perform the following actions. 1) As the directory administrator execute the following search: ldapsearch -x -D "cn=Manager,o=testorg.com" -w password -b o=testorg.com uid=testuser pwdFailureTime modifyTimestamp. This will return something like "modifyTimestamp: 20070705142825Z" 2) As testuser execute the following search: ldapsearch -x -D "uid=testuser,o=testorg.com" -w correctPassword -b o=testorg.com uid=testuser modifyTimestamp. This will also return something like "modifyTimestamp: 20070705142825Z" 3) As testuser execute the following search (note the INCORRECT password): ldapsearch -x -D "uid=testuser,o=testorg.com" -w WRONGPassword -b o=testorg.com uid=testuser modifyTimestamp. This will also return something like "ldap_bind: Invalid credentials (49)" 4) As the directory administrator execute the following search: ldapsearch -x -D "cn=Manager,o=testorg.com" -w password -b o=testorg.com uid=testuser pwdFailureTime modifyTimestamp. This will return something like "pwdFailureTime: 20070705144735Z modifyTimestamp: 20070705144735Z". Note that the 'pwdFailureTime attribute has been created and the 'modifyTimestamp' attribute has been updated to the time that the bind attempt failed. Contents of my Standard policy file are ... dn: cn=Standard, ou=Policies, o=testorg.com pwdLockout: TRUE pwdMaxFailure: 3 objectClass: top objectClass: device objectClass: pwdPolicy pwdFailureCountInterval: 120 pwdLockoutDuration: 3600 cn: Standard pwdAttribute: userPassword
dan.cushing@netideasinc.com wrote: > Full_Name: Dan Cushing > Version: 2.3.36 > OS: Solaris 9 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (71.76.187.82) > > > When running OpenLDAP with the ppolicy overlay, the modifyTimestamp for a user > entry is updated if the user attempts to login (bind) with an incorrect > password. This is happening because the password lockout feature is enabled and > the operational attribute 'pwdFailureTime' is being updated. It seems like this > results in a misleading modifyTimestamp. Is it intended that the > modifyTimestamp attribute be updated when operational attributes are updated? Hadn't really thought about it before. We can certainly avoid this though. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
changed notes changed state Open to Test moved from Incoming to Software Bugs
I'd defer to those with more expertise, but my vote is to avoid changing the modifyTimestamp attribute. That attribute should be updated only when an ldapmodify operation is performed. I'm not familiar with the specifications, and perhaps this isn't addressed there. My intuition suggests that it shouldn't be modified by operations that are not directly under the control of the user or administrator. Dan Howard Chu wrote: > dan.cushing@netideasinc.com wrote: >> Full_Name: Dan Cushing >> Version: 2.3.36 >> OS: Solaris 9 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (71.76.187.82) >> >> >> When running OpenLDAP with the ppolicy overlay, the modifyTimestamp >> for a user >> entry is updated if the user attempts to login (bind) with an incorrect >> password. This is happening because the password lockout feature is >> enabled and >> the operational attribute 'pwdFailureTime' is being updated. It >> seems like this >> results in a misleading modifyTimestamp. Is it intended that the >> modifyTimestamp attribute be updated when operational attributes are >> updated? > > Hadn't really thought about it before. We can certainly avoid this > though. -- This electronic transmission is strictly confidential to NetIDEAS, Inc. and intended solely for the addressee. It may contain information, which is covered by legal, professional, or other privilege. If you are not the intended addressee, or someone authorized by the intended addressee to receive transmissions on the behalf of the addressee, you must not retain, disclose in any form, copy or take any action in reliance on this transmission. If you have received this transmission in error, please notify us as soon as possible and destroy this message.
Dan Cushing wrote: > I'd defer to those with more expertise, but my vote is to avoid changing > the modifyTimestamp attribute. That attribute should be updated only > when an ldapmodify operation is performed. > > I'm not familiar with the specifications, and perhaps this isn't > addressed there. My intuition suggests that it shouldn't be modified by > operations that are not directly under the control of the user or > administrator. Already fixed in CVS HEAD and RE23, please test. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
hyc@symas.com wrote: > Dan Cushing wrote: >> I'd defer to those with more expertise, but my vote is to avoid changing >> the modifyTimestamp attribute. That attribute should be updated only >> when an ldapmodify operation is performed. >> >> I'm not familiar with the specifications, and perhaps this isn't >> addressed there. My intuition suggests that it shouldn't be modified by >> operations that are not directly under the control of the user or >> administrator. > > Already fixed in CVS HEAD and RE23, please test. I'll note that this change will prevent these operational attributes from being replicated in many cases. Of course, given that the replication behavior of these attributes is currently undefined, it may not be a problem right now. Down the road, I don't know. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
changed notes
changed notes changed state Test to Closed
moved from Software Bugs to Archive.Software Bugs
rejected, see -devel