Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 557724

Summary:	passwordexpirationtime is 1h less than setup
Product:	[Retired] 389	Reporter:	Thomas Blanchin <tblanchin>
Component:	Security - Password Policy	Assignee:	Rich Megginson <rmeggins>
Status:	CLOSED WORKSFORME	QA Contact:	Chandrasekar Kannan <ckannan>
Severity:	low	Docs Contact:
Priority:	medium
Version:	7.1	CC:	benl, jgalipea, nhosoi
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-03-30 16:21:45 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	512820, 690319

Description Thomas Blanchin 2010-01-22 11:30:06 UTC

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 ?

Comment 2 Jenny Severance 2010-10-22 17:07:29 UTC

per bug triage 10/21/2010, targeting DS future and priority low

Comment 3 Noriko Hosoi 2011-03-30 00:13:50 UTC

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.

Comment 4 Martin Kosek 2012-01-04 13:40:50 UTC

Upstream ticket:
https://fedorahosted.org/389/ticket/93