Bug 985956 - kinit does not work when the client time is more than one day behind the server time
kinit does not work when the client time is more than one day behind the serv...
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: krb5 (Show other bugs)
7.0
Unspecified Unspecified
medium Severity medium
: beta
: ---
Assigned To: Nalin Dahyabhai
David Spurek
:
Depends On: 961221
Blocks: 917658
  Show dependency treegraph
 
Reported: 2013-07-18 11:12 EDT by Patrik Kis
Modified: 2015-03-02 00:27 EST (History)
5 users (show)

See Also:
Fixed In Version: krb5-1.11.3-4.el7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 961221
Environment:
Last Closed: 2014-06-13 07:51:14 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Patrik Kis 2013-07-18 11:12:22 EDT
This bugfix was not yet ported to RHEL-7.

0 [root@rhel7 ~ ]# rpm -qa krb5\*
krb5-server-1.11.2-5.el7.x86_64
krb5-workstation-1.11.2-5.el7.x86_64
krb5-debuginfo-1.11.2-5.el7.x86_64
krb5-libs-1.11.2-5.el7.x86_64
0 [root@rhel7 ~ ]# 
0 [root@rhel7 ~ ]# date
Thu Jul 18 17:05:27 CEST 2013
0 [root@rhel7 ~ ]# echo Pass2012! | kinit Amy-admin@SECURITY.BASEOS.QE; klist; kdestroy
Password for Amy-admin@SECURITY.BASEOS.QE: 
Ticket cache: DIR::/run/user/0/krb5cc/tktBZ2uxt
Default principal: Amy-admin@SECURITY.BASEOS.QE

Valid starting       Expires              Service principal
07/18/2013 11:08:39  07/18/2013 21:08:39  krbtgt/SECURITY.BASEOS.QE@SECURITY.BASEOS.QE
	renew until 07/25/2013 11:08:39
0 [root@rhel7 ~ ]# date 07171605
Wed Jul 17 16:05:00 CEST 2013
0 [root@rhel7 ~ ]# echo Pass2012! | kinit Amy-admin@SECURITY.BASEOS.QE; klist; kdestroy
Password for Amy-admin@SECURITY.BASEOS.QE: 
Ticket cache: DIR::/run/user/0/krb5cc/tktp15Cdh
Default principal: Amy-admin@SECURITY.BASEOS.QE

Valid starting       Expires              Service principal
07/18/2013 11:09:35  07/18/2013 16:05:01  krbtgt/SECURITY.BASEOS.QE@SECURITY.BASEOS.QE
	renew until 07/24/2013 16:05:01
0 [root@rhel7 ~ ]# 
0 [root@rhel7 ~ ]# 
0 [root@rhel7 ~ ]# 
0 [root@rhel7 ~ ]# date 07171005
Wed Jul 17 10:05:00 CEST 2013
0 [root@rhel7 ~ ]# echo Pass2012! | kinit Amy-admin@SECURITY.BASEOS.QE; klist; kdestroy
Password for Amy-admin@SECURITY.BASEOS.QE: 
kinit: Requested effective lifetime is negative or too short while getting initial credentials
klist: No credentials cache found (ticket cache DIR::/run/user/0/krb5cc/tktp15Cdh)
kdestroy: No credentials cache found while destroying cache
0 [root@rhel7 ~ ]# 


+++ This bug was initially created as a clone of Bug #961221 +++
Comment 1 Nalin Dahyabhai 2013-07-19 16:57:30 EDT
The most recent rebase should incorporate a backported version of the fix for this.
Comment 2 David Spurek 2013-08-06 09:54:45 EDT
Hi, bug is not fixed correctly. When I set time day,week or month ahead the server time, then I can get ticket and use it with gssapi (ldapsearch+gssapi).

When I set time day,week or month behind the server time then I can get the ticket, but it doesn't work with gssapi.

detailed output:
--------
server:
[test]date
Tue Aug  6 09:51:39 EDT 2013

--------
client:
[test]date
Tue Jul 30 09:48:02 EDT 2013

[test]klist
Ticket cache: DIR::/run/user/0/krb5cc/tktSymuNo
Default principal: Ariel@EXAMPLE.COM

Valid starting       Expires              Service principal
08/06/2013 09:52:41  07/31/2013 09:48:23  krbtgt/EXAMPLE.COM@EXAMPLE.COM
	renew until 08/06/2013 09:48:23


[test]ldapsearch -Y GSSAPI -H ldap://ibm-p750e-02-lp2.rhts.eng.bos.redhat.com -b dc=example,dc=com '(objectclass=*)'
SASL/GSSAPI authentication started
ldap_sasl_interactive_bind_s: Local error (-2)
	additional info: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure.  Minor code may provide more information (Ticket expired)
Comment 3 David Spurek 2013-08-06 09:56:04 EDT
Additional comment to #2

tested with version:

[test]rpm -q krb5-server
krb5-server-1.11.3-4.el7.ppc64
Comment 4 Nalin Dahyabhai 2013-08-06 10:20:00 EDT
I think we need more information about your topology here.  Is your directory server also your KDC?  If not, which server's time was noted, and what was the time on the other one?
Comment 5 Patrik Kis 2013-08-06 10:30:39 EDT
(In reply to Nalin Dahyabhai from comment #4)
> I think we need more information about your topology here.  Is your
> directory server also your KDC?  If not, which server's time was noted, and
> what was the time on the other one?

Yes, the KDC and the directory server are running on the same machine and have the same time.
David, can you please confirm that?
Comment 6 David Spurek 2013-08-06 10:33:38 EDT
I use KDC and openldap server on the same machine and they have the same time.
Comment 7 Nalin Dahyabhai 2013-08-06 11:53:34 EDT
What are the versions of the krb5 packages on the client?  I pointed a client with 1.11.3-6.el7 at an IPA server running on 6.4 with the clock skewed both backward and forward by more than a week, and didn't encounter this problem either time.
Comment 8 Patrik Kis 2013-08-07 10:58:38 EDT
(In reply to Nalin Dahyabhai from comment #7)
> What are the versions of the krb5 packages on the client?  I pointed a
> client with 1.11.3-6.el7 at an IPA server running on 6.4 with the clock
> skewed both backward and forward by more than a week, and didn't encounter
> this problem either time.

On booth client and server there is 1.11.3-6.el7 installed.
It seems that the problem is how the service ticket expiration is counted. Please check the test below. The time when the service stop working is exactly one day, the dame time as the ticket validity period.

SERVER:
The server (kdc and directory server) time was at the beginning the test:
# date
Wed Aug  7 16:54:05 CEST 2013


CLIENT:
The test finished within few second.

# date 08061655
Tue Aug  6 16:55:00 CEST 2013
# echo Ar1€lKRBp@ss |kinit Ariel
Password for Ariel@EXAMPLE.COM: 
# ldapsearch -Y GSSAPI -H ldap://rhel7.pkis.net -b dc=example,dc=com '(objectclass=*)'
SASL/GSSAPI authentication started
SASL username: Ariel@EXAMPLE.COM
SASL SSF: 56

... snip ...

# numResponses: 7
# numEntries: 6
# klist 
Ticket cache: DIR::/run/user/0/krb5cc/tktKcGL0g
Default principal: Ariel@EXAMPLE.COM

Valid starting       Expires              Service principal
08/07/2013 16:54:29  08/08/2013 16:54:29  krbtgt/EXAMPLE.COM@EXAMPLE.COM
	renew until 08/07/2013 16:54:29
08/07/2013 16:54:30  08/08/2013 16:54:29  ldap/rhel7.pkis.net@EXAMPLE.COM
	renew until 08/07/2013 16:54:29
# 
# 
# 
# kdestroy 
# 
# 
# date 08061654
Tue Aug  6 16:54:00 CEST 2013
# echo Ar1€lKRBp@ss |kinit Ariel
Password for Ariel@EXAMPLE.COM: 
# ldapsearch -Y GSSAPI -H ldap://rhel7.pkis.net -b dc=example,dc=com '(objectclass=*)'
SASL/GSSAPI authentication started
ldap_sasl_interactive_bind_s: Local error (-2)
	additional info: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure.  Minor code may provide more information (Ticket expired)
# klist 
Ticket cache: DIR::/run/user/0/krb5cc/tkt014udC
Default principal: Ariel@EXAMPLE.COM

Valid starting       Expires              Service principal
08/07/2013 16:54:40  08/07/2013 16:54:03  krbtgt/EXAMPLE.COM@EXAMPLE.COM
	renew until 08/07/2013 16:54:40
08/07/2013 16:54:43  08/07/2013 16:54:03  ldap/rhel7.pkis.net@EXAMPLE.COM
	renew until 08/07/2013 16:54:40
#
Comment 9 Nalin Dahyabhai 2013-09-19 12:00:33 EDT
Is your KDC set up so that the client requires preauthentication?  This is necessary in order to allow the client to use the time that the KDC reports along with the preauth-required error.
Comment 10 Patrik Kis 2013-09-20 04:49:45 EDT
(In reply to Nalin Dahyabhai from comment #9)
> Is your KDC set up so that the client requires preauthentication?  This is
> necessary in order to allow the client to use the time that the KDC reports
> along with the preauth-required error.

It isn't using preauth; that was it! By setting preauth for the client principal it started to work. Thanks.

Changing the status to ON_QA so we can verify this feature on all architectures.
Comment 13 Ludek Smid 2014-06-13 07:51:14 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.