Red Hat Bugzilla – Bug 557724
passwordexpirationtime is 1h less than setup
Last modified: 2015-01-04 18:41:13 EST
Description of problem: If you setup a password policy (subtree in my case) with a passwordmaxage = x, and then change the password of a user, it will have a passwordexpirationtime = x - 3600. For example, passwordmaxage setup to 1day from the console would actually reflect a passwordexpirationtime in 23 hours. Version-Release number of selected component (if applicable): Directory server 1.2.2 Console framework 1.1.3 How reproducible: Steps to Reproduce: 1. Create a subtree password policy 2. Set "Password expires after 1 day" 3. Change the password of a user under this subtree 4. Check this user advanced properties Actual results: The passwordexpirationtime will be approximately "now + 23h" Expected results: The passwordexpirationtime should be "now + 1day" Additional info: Maybe it's a problem in the timezones. I have my timezone setup to Europe/Paris, which is GMT+1 ... could it be the reason ?
per bug triage 10/21/2010, targeting DS future and priority low
I could not reproduce the problem. Set 1 day to passwordMaxAge. dn: cn=cn\3DnsPwPolicyEntry\2Cou\3DPeople\2Cdc\3Dexample\2Cdc\3Dcom,cn=nsPwPol icyContainer,ou=People,dc=example,dc=com passwordMaxAge: 86400 Modify a password of a test user, then search the user's passwordExpirationTime and modifyTimestamp: $ ldapsearch ... -b "uid=tuser0,ou=people,dc=example,dc=com" "(uid=*)" passwordExpirationTime modifyTimestamp dn: uid=tuser0,ou=People,dc=example,dc=com passwordExpirationTime: 20110330234522Z modifyTimestamp: 20110329234522Z The passwordExpirationTime (2011/03/30-23:45:22) is 1 day ahead of modifyTimeStamp (2011/03/29-23:45:22). Please note that the passwordExpirationTime is calculated without any knowledge about the timezone.
Upstream ticket: https://fedorahosted.org/389/ticket/93