Bug 888579

Summary: Users cannot change their passwords after password expiry change
Product: Red Hat Enterprise Linux 7 Reporter: Jesse Triplett <jtriplet>
Component: ipaAssignee: Rob Crittenden <rcritten>
Status: CLOSED DUPLICATE QA Contact: Namita Soman <nsoman>
Severity: unspecified Docs Contact:
Priority: medium    
Version: 7.0CC: dpal, jwest, mkosek, pdemmers, pep, spoore
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: ipa-3.2.1-1.el7 Doc Type: Known Issue
Doc Text:
The Identity Management server processes Kerberos Password Expiration Time field as a 32-bit integer. If Maximum Lifetime of a user password in Identity Management Password Policy is set to a value causing the resulting Kerberos Password Expiration Time timestamp to exceed 32 bits and to overflow, the passwords that are being changed are configured with an expiration time that lies in the past and are always rejected. To ensure that new user passwords are valid and can be changed properly, do not set password Maximum Lifetime in Identity Management Password Policy to values that would cause the Kerberos Password Expiration Time timestamp to exceed 32 bits; that is, passwords that would expire after 2038-01-19. At the moment, recommended values for the Maximum Lifetime field are numbers lower than 9000 days.
 Story Points: ---
Clone Of:
: 891977 (view as bug list) Environment:
Last Closed: 2014-01-29 23:02:00 UTC Type: Bug
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: 891977    
Attachments:
Description Flags
This is an sosreport from the IPA server none

Description Jesse Triplett 2012-12-18 22:25:09 UTC 
Description of problem:
After password expiry is set to 99999 users are prompted to change their passwds.  After changing their passwords and logging in next time, they find that they are asked to change the password AGAIN and that the password is the same as before the last "password change" happened.

Version-Release number of selected component (if applicable):
ipa-server-2.2.0-16.el6.x86_64

How reproducible:
Follow the steps in the video or these steps

Steps to Reproduce: (In the customer's words)
1) I create a user 
2) I check the user krbpasswordexpiration attr. and is set correctly to today's date
2) I log with this user name on one of the server 
3) After I enter the reset password 
4) System asks for the new password
5) I enter the new password and I reconfirm the password.
6) Got the message Authentication token manipulation error
7) I check the krbpasswordexpiration attr for this user and now is set to : 19011216191837Z
  
Actual results:
Users log in and are asked to reset their passwd (ie enter the current passwd, enter new passwd, confirm) On next login the customer is asked to reset passwd again except when they are asked to enter the current password it is really the password from before the first passwd reset.

Expected results:
ASked to reset password and the passwd gets reset with expiration = 9999 days

Additional info:
I am going to upload as much data as I can.
Comment 1 Jesse Triplett 2012-12-18 22:27:54 UTC 
Created attachment 665805 [details]
This is an sosreport from the IPA server

The customer at this point is just as willing to install a new box and make a replica to migrate the users to before decommisioning the current ipa server but I am not convinced that whatever configuration or buggy package that is causing this won't be carried over in the migration.
Comment 3 Dmitri Pal 2012-12-18 23:01:24 UTC 
Does it work if one sets the days to 9999 value?
I suspect something is too big and the time stamp rolls over.
Can you try with a smaller numbers?
9999 / 365 = 27 years might be sufficient enough for now.
Comment 4 Martin Kosek 2012-12-19 13:29:58 UTC 
I was finally able to reproduce the issue. The problem in my case was that I was not able to reproduce it when I had Max password lifetime set to 99999, as reported.

However, when I tried to set it to 9999, the reproduction suddenly started to work:

# ipa pwpolicy-mod --maxlife 9999
  Group: global_policy
  Max lifetime (days): 9999
  Min lifetime (hours): 1
  History size: 1
  Character classes: 0
  Min length: 8
  Max failures: 6
  Failure reset interval: 60
  Lockout duration: 600

$ ssh fbar9.lab.bos.redhat.com 
fbar9.lab.bos.redhat.com's password: 
Password expired. Change your password now.
WARNING: Your password has expired.
You must change your password now and login again!
Changing password for user fbar9.
Current Password: 
New password: 
Retype new password: 
passwd: Authentication token manipulation error
Connection to vm-060.idm.lab.bos.redhat.com closed.

# ipa user-show fbar9 --all --raw
  dn: uid=fbar9,cn=users,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com
  uid: fbar9
  givenname: Foo
  sn: bar
  cn: Foo bar
  displayname: Foo bar
  initials: Fb
  homedirectory: /home/fbar9
  gecos: Foo bar
  loginshell: /bin/sh
  krbprincipalname: fbar9.BOS.REDHAT.COM
  uidnumber: 1297400012
  gidnumber: 1297400012
  nsaccountlock: False
  has_password: True
  has_keytab: True
  ipauniqueid: 3b9d1f88-49de-11e2-b9cf-001a4a104e37
  krbextradata: AAIgvtFQa2FkbWluZEBJRE0uTEFCLkJPUy5SRURIQVQuQ09NAA==
  krblastpwdchange: 20121219131616Z
  krblastsuccessfulauth: 20121219131616Z
  krbloginfailedcount: 0
  krbpasswordexpiration: 19040330064800Z   <<<<<<<<<
  krbpwdpolicyreference: cn=global_policy,cn=IDM.LAB.BOS.REDHAT.COM,cn=kerberos,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com
  krbticketflags: 128
  memberof: cn=ipausers,cn=groups,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com
  mepmanagedentry: cn=fbar9,cn=groups,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com
  objectclass: top
  objectclass: person
  objectclass: organizationalperson
  objectclass: inetorgperson
  objectclass: inetuser
  objectclass: posixaccount
  objectclass: krbprincipalaux
  objectclass: krbticketpolicyaux
  objectclass: ipaobject
  objectclass: ipasshuser
  objectclass: ipaSshGroupOfPubKeys
  objectclass: mepOriginEntry



When I tried Dmitri's approach and set it to lower value, 5000 in my case, the password change worked:

# ipa pwpolicy-mod --maxlife 5000
  Group: global_policy
  Max lifetime (days): 5000
  Min lifetime (hours): 1
  History size: 1
  Character classes: 0
  Min length: 8
  Max failures: 6
  Failure reset interval: 60
  Lockout duration: 600

# ipa passwd fbar9
New Password: 
Enter New Password again to verify: 
---------------------------------------------------
Changed password for "fbar9.BOS.REDHAT.COM"
---------------------------------------------------

$ ssh fbar9.lab.bos.redhat.com 
fbar9.lab.bos.redhat.com's password: 
Password expired. Change your password now.
Last login: Wed Dec 19 08:19:30 2012 from balmora.brq.redhat.com
WARNING: Your password has expired.
You must change your password now and login again!
Changing password for user fbar9.
Current Password: 
New password: 
Retype new password: 
passwd: all authentication tokens updated successfully.
Connection to vm-060.idm.lab.bos.redhat.com closed.

# ipa user-show fbar9 --all --raw
  dn: uid=fbar9,cn=users,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com
  uid: fbar9
  givenname: Foo
  sn: bar
  cn: Foo bar
  displayname: Foo bar
  initials: Fb
  homedirectory: /home/fbar9
  gecos: Foo bar
  loginshell: /bin/sh
  krbprincipalname: fbar9.BOS.REDHAT.COM
  uidnumber: 1297400012
  gidnumber: 1297400012
  nsaccountlock: False
  has_password: True
  has_keytab: True
  ipauniqueid: 3b9d1f88-49de-11e2-b9cf-001a4a104e37
  krbextradata: AAL3vtFQa2FkbWluZEBJRE0uTEFCLkJPUy5SRURIQVQuQ09NAA==
  krblastpwdchange: 20121219131951Z
  krblastsuccessfulauth: 20121219131951Z
  krbloginfailedcount: 0
  krbpasswordexpiration: 20260828131951Z   <<<<<<<<<
  krbpwdpolicyreference: cn=global_policy,cn=IDM.LAB.BOS.REDHAT.COM,cn=kerberos,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com
  krbticketflags: 128
  memberof: cn=ipausers,cn=groups,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com
  mepmanagedentry: cn=fbar9,cn=groups,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com
  objectclass: top
  objectclass: person
  objectclass: organizationalperson
  objectclass: inetorgperson
  objectclass: inetuser
  objectclass: posixaccount
  objectclass: krbprincipalaux
  objectclass: krbticketpolicyaux
  objectclass: ipaobject
  objectclass: ipasshuser
  objectclass: ipaSshGroupOfPubKeys
  objectclass: mepOriginEntry


Jesse, would customer accept this workaround until we fix it?

I was also able to reproduce it in current upstream/RHEL release. I will prepare an upstream ticket.
Comment 5 Martin Kosek 2012-12-19 13:34:29 UTC 
Upstream ticket:
https://fedorahosted.org/freeipa/ticket/3312
Comment 20 Martin Kosek 2013-02-21 09:15:20 UTC 
This issue was fixed upstream:

master: 0e8a329048629f639ae64ff32e01e12a495e7763
ipa-3-1: 4d17b7217256996c51b579504f47b9d1ef037f04

ipa-kdb dricver now caps the password expiration date on the maximum date that is still processed correctly by Kerberos libraries: Jan 1, 2038.
Comment 23 Scott Poore 2014-01-29 22:01:12 UTC 
Verified.

Think this was already done in bug #891977 but, adding comment here for documentation.

Version ::

ipa-server-3.3.3-15.el7.x86_64

Results ::

[root@rhel7-4 ~]# date +%Y%m%d%H%M%S
20140129154938

[root@rhel7-4 ~]# ipa user-show testuser2 --all|grep krbpasswordexpiration
  krbpasswordexpiration: 20140129214918Z

[root@rhel7-4 ~]# ipa pwpolicy-mod --maxlife 9999
  Group: global_policy
  Max lifetime (days): 9999
  Min lifetime (hours): 1
  History size: 0
  Character classes: 0
  Min length: 8
  Max failures: 6
  Failure reset interval: 60
  Lockout duration: 600

[root@rhel7-4 ~]# ipa user-add --first=f --last=l bzuser1 --password
Password: 
Enter Password again to verify: 
--------------------
Added user "bzuser1"
--------------------
  User login: bzuser1
  First name: f
  Last name: l
  Full name: f l
  Display name: f l
  Initials: fl
  Home directory: /home/bzuser1
  GECOS: f l
  Login shell: /bin/sh
  Kerberos principal: bzuser1
  Email address: bzuser1
  UID: 763800003
  GID: 763800003
  Password: True
  Member of groups: ipausers
  Kerberos keys available: True

[root@rhel7-4 ~]# ipa user-show bzuser1 --all|grep krbpasswordexpiration
  krbpasswordexpiration: 20140129215102Z

[root@rhel7-4 ~]# date +%Y%m%d%H%M%S
20140129155117

[root@rhel7-4 ~]# ssh bzuser1@$(hostname)
bzuser1.com's password: 
Password expired. Change your password now.
WARNING: Your password has expired.
You must change your password now and login again!
Changing password for user bzuser1.
Current Password: 
New password: 
Retype new password: 
passwd: all authentication tokens updated successfully.
Connection to rhel7-4.example.com closed.

[root@rhel7-4 ~]# ipa user-show bzuser1 --all|grep krbpasswordexpiration
  krbpasswordexpiration: 20380101000000Z

[root@rhel7-4 ~]# ssh bzuser1@$(hostname)
bzuser1.com's password: 
Last login: Wed Jan 29 15:53:05 2014 from rhel7-4.example.com
Could not chdir to home directory /home/bzuser1: No such file or directory
-sh-4.2$
Comment 24 Scott Poore 2014-01-29 23:02:00 UTC 
Closing this as a duplicate of bug #891977 since additional fix applied to the version there.

*** This bug has been marked as a duplicate of bug 891977 ***