Bug 971303

We should probably update ipa-pwd-extop to set krbpasswordexpiration one second in the past instead of current time. Simo/Rob, any objections?

In any case, I will create a ticket as this behavior is not correct.

Upstream ticket:
https://fedorahosted.org/freeipa/ticket/3696

Given kerberos allows for clock skews of 5 minutes, we could use that as a 'standard' skew and set the expiration back 5 minutes. This would certainly avoid any race and also tools running on a different machine directly checking the expiartion time attribute for whatever reason (monitoring, notifying, ...) would not be fooled.

However putting it back even just 1 second is fine by me.

Good idea, 5 minutes sounds fine. I will update the upstream ticket.

What I wonder is -- if the expiration is set as YYYY-MM-DD HH:MI:SS, does it mean it expires at HH:MI:SS.000000, or at HH:MI:SS.999999? Isn't the expiry check which is wrong (using possibly something like "greater than", when it should be using "grater or equal")?

Excellent point Jan.

We do never check for equality in our expiration time checks, neither for password expiration nor for account expiration.

So you are correct that the current bug could be strictly solved by a >= or <= instead of the current > or <

This is also a valid solution to this bug.

We found out that this Bugzilla is a duplicate of upstream ticket https://fedorahosted.org/freeipa/ticket/1064. Upstream commit:
master: bf77679909c3d73aea77f3ededd8d84e3c045d44

As this is not a critical issue, I do not think it needs to be fixed in RHEL-6.

Moving to RHEL-7.0 where it will be fixed as part of IPA package rebase.

Moving to POST, this is fixed upstream:
master: bf77679909c3d73aea77f3ededd8d84e3c045d44

Verified against ipa-server-3.3.3-12.el7.x86_64

[root@zippyvm8 ~]# date
Wed Jan 29 17:27:11 EST 2014
[root@zippyvm8 ~]# ( echo initpass ; echo initpass ) | ipa user-add $GUSER --first X --last Y --password
ipa: ERROR: user with name "newguser" already exists
[root@zippyvm8 ~]# echo fk8hAfT7i | kinit $GUSER
Password for newguser: 
kinit: Password incorrect while getting initial credentials
[root@zippyvm8 ~]# klist
Ticket cache: KEYRING:persistent:0:0
Default principal: admin

Valid starting       Expires              Service principal
01/29/2014 17:26:29  01/30/2014 17:25:42  HTTP/zippyvm8.idm.lab.eng.rdu2.redhat.com
01/29/2014 17:25:45  01/30/2014 17:25:42  krbtgt/EXAMPLE.COM
[root@zippyvm8 ~]# date;
Wed Jan 29 17:27:12 EST 2014

To be automated.

I believe the original script that I used to verify wasn't quite correct to verify this bug with. 

This time, I attempted to kinit as the user with the original password that admin set for the user. If this bug is correct, then the kinit should ask for a new password. It does. 

Bug still verified. 

[root@ipaqa64vmb ~]# date;( echo initpass ; echo initpass ) | ipa user-add $GUSER --first X --last Y --password; kdestroy; echo initpass | kinit $GUSER; date
Tue Feb 25 13:05:10 EST 2014
---------------------
Added user "newguser"
---------------------
  User login: newguser
  First name: X
  Last name: Y
  Full name: X Y
  Display name: X Y
  Initials: XY
  Home directory: /home/newguser
  GECOS: X Y
  Login shell: /bin/sh
  Kerberos principal: newguser
  Email address: newguser
  UID: 1998800003
  GID: 1998800003
  Password: True
  Member of groups: ipausers
  Kerberos keys available: True
Password for newguser: 
Password expired.  You must change it now.
Enter new password: 
kinit: Cannot read password while getting initial credentials
Tue Feb 25 13:05:10 EST 2014

Thanks, this is closer to valid verification (you received the key error message "Password expired.  You must change it now.").

I assume you intentionally pass the insufficient data for kinit with expired passwords so that it fails:

Password for newguser: 
Password expired.  You must change it now.
Enter new password: 
kinit: Cannot read password while getting initial credentials

Note that to kinit properly even with expired passwords, you would need to run:

# echo -e 'initpass\nnew_pwd123\nnew_pwd123' | kinit newguser

... to also verify that the expiration password change completes.

I may need to unverify this bug. 

In comment #4 and comment #5, it looks like a decision was made to set the expiry time back 5 min from when the password is set by the admin. 

In this example, I set the password for $tuser, then, I expect that the expiration time for that user would be this time minus 5 min. So, I set the clock back 3 min, and then kinit as the user. This works. 

[root@nocp7 ~]# date; echo 'passwd' | ipa passwd $tuser
Tue Feb 25 16:09:10 EST 2014
-----------------------------------------
Changed password for "lljk"
-----------------------------------------

[root@nocp7 ~]# kdestroy 
[root@nocp7 ~]# date -s '3 minutes ago'
Tue Feb 25 16:06:28 EST 2014
[root@nocp7 ~]# kinit $tuser
Password for lljk: 
Warning: Your password will expire in less than one hour on Tue 25 Feb 2014 04:09:10 PM EST


The password expiration time is set to the same time as when the password was set (Tue Feb 25 16:09:10 EST 2014), but shouldn't the expiration time be set to 5 min earlier as per comment #4 and #5?

The time isn't set back 5 minutes, it is set back 1 second:

--- a/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipapwd_common.c
+++ b/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipapwd_common.c
@@ -640,6 +640,12 @@ int ipapwd_CheckPolicy(struct ipapwd_data *data)
          * force a password change on the next login.
          * But not if Directory Manager */
         if (data->changetype == IPA_CHANGETYPE_ADMIN) {
+            /* The expiration date needs to be older than the current time
+             * otherwise the KDC may not immediately register the password
+             * as expired. The last password change needs to match the
+             * password expiration otherwise minlife issues will arise.
+             */
+            data->timeNow -= 1;
             data->expireTime = data->timeNow;
         }

I will alter the automated test to verify the expiration time is set to 1 second instead of 300 seconds.

This request was resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you have further questions about the request.