Bug 961221 - Set time on client more than one day backwards from AD server not works well
Summary: Set time on client more than one day backwards from AD server not works well
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: krb5
Version: 19
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: ---
Assignee: Nalin Dahyabhai
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 949853 985956
TreeView+ depends on / blocked
 
Reported: 2013-05-09 07:36 UTC by David Spurek
Modified: 2015-03-02 05:27 UTC (History)
8 users (show)

Fixed In Version: krb5-1.11.3-1.fc19
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 985956 (view as bug list)
Environment:
Last Closed: 2013-06-12 17:11:09 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description David Spurek 2013-05-09 07:36:06 UTC
Description of problem:
Set day on client more than a day forwards against AD server not works well.
Kinit pass without error message, klist shows the same Valid starting       Expires dates.
Date on AD is 'Sun May 9 03:16:12 EDT 2013'.

[root@dspurek ~]# date
Sun May 12 03:16:12 EDT 2013
[root@dspurek ~]# kinit Amy.QE
Password for Amy.QE: 
[root@dspurek ~]# klist
Ticket cache: DIR::/run/user/0/krb5cc/tktQIf2k5
Default principal: Amy.QE

Valid starting       Expires              Service principal
05/09/2013 03:19:23  05/09/2013 13:19:23  krbtgt/SECURITY.BASEOS.QE.QE
	renew until 05/16/2013 03:19:23


When I set day on client more than a day backwards, then kinit fail with error message. 

[root@dspurek ~]# date 
Wed May  8 03:15:50 EDT 2013
[root@dspurek ~]# kinit Amy.QE
Password for Amy.QE: 
kinit: Requested effective lifetime is negative or too short while getting initial credentials


Version-Release number of selected component (if applicable):
krb5-libs-1.11.2-4.fc19

How reproducible:
always

Steps to Reproduce:
1.Set day on client more than a day forwards against AD
2.try kinit
3.
  
Actual results:
kinit pass without error, but 

Expected results:
kinit should finish with some kind of error message

Additional info:

Comment 1 David Spurek 2013-05-09 07:49:46 UTC
[root@dspurek ~]# KRB5_TRACE=/dev/stderr kinit Amy.QE
[1977] 1368344715.144984: Resolving unique ccache of type DIR
[1977] 1368344715.145386: Getting initial credentials for Amy.QE
[1977] 1368344715.145723: Sending request (196 bytes) to SECURITY.BASEOS.QE
[1977] 1368344715.149257: Resolving hostname dc.security.baseos.qe.
[1977] 1368344715.151743: Sending initial UDP request to dgram 10.34.36.170:88
[1977] 1368344715.153998: Received answer from dgram 10.34.36.170:88
[1977] 1368344715.154913: Response was not from master KDC
[1977] 1368344715.155093: Received error from KDC: -1765328359/Additional pre-authentication required
[1977] 1368344715.155323: Processing preauth types: 16, 15, 19, 2
[1977] 1368344715.155647: Selected etype info: etype aes256-cts, salt "SECURITY.BASEOS.QEAmy", params ""
Password for Amy.QE: 
[1977] 1368344719.773727: AS key obtained for encrypted timestamp: aes256-cts/CE4D
[1977] 1368344719.773956: Encrypted timestamp (for 1368085718.741404): plain 301AA011180F32303133303530393037343833385AA10502030B501C, encrypted 25D28630AEF3A3CE27455904F21722E711B2B857B49B1323B977C66FCE0E0BEC7CB6C1EEFF30B8FC019F4922305EEEFAF3213D58D1A40C82
[1977] 1368344719.774108: Preauth module encrypted_timestamp (2) (flags=1) returned: 0/Success
[1977] 1368344719.774203: Produced preauth for next request: 2
[1977] 1368344719.774419: Sending request (276 bytes) to SECURITY.BASEOS.QE
[1977] 1368344719.776516: Resolving hostname dc.security.baseos.qe.
[1977] 1368344719.777740: Sending initial UDP request to dgram 10.34.36.170:88
[1977] 1368344719.779702: Received answer from dgram 10.34.36.170:88
[1977] 1368344719.780683: Response was not from master KDC
[1977] 1368344719.780828: Processing preauth types: 19
[1977] 1368344719.780902: Selected etype info: etype aes256-cts, salt "SECURITY.BASEOS.QEAmy", params ""
[1977] 1368344719.780980: Produced preauth for next request: (empty)
[1977] 1368344719.781130: AS key determined by preauth: aes256-cts/CE4D
[1977] 1368344719.781289: Decrypted AS reply; session key is: aes256-cts/E1FE
[1977] 1368344719.781380: FAST negotiation: unavailable
[1977] 1368344719.781521: Initializing DIR::/run/user/0/krb5cc/tkt79CGND with default princ Amy.QE
[1977] 1368344719.783869: Removing Amy.QE -> krbtgt/SECURITY.BASEOS.QE.QE from DIR::/run/user/0/krb5cc/tkt79CGND
[1977] 1368344719.783976: Storing Amy.QE -> krbtgt/SECURITY.BASEOS.QE.QE in DIR::/run/user/0/krb5cc/tkt79CGND
[1977] 1368344719.784175: Storing config in DIR::/run/user/0/krb5cc/tkt79CGND for krbtgt/SECURITY.BASEOS.QE.QE: pa_type: 2
[1977] 1368344719.784302: Removing Amy.QE -> krb5_ccache_conf_data/pa_type/krbtgt\/SECURITY.BASEOS.QE\@SECURITY.BASEOS.QE@X-CACHECONF: from DIR::/run/user/0/krb5cc/tkt79CGND
[1977] 1368344719.784410: Storing Amy.QE -> krb5_ccache_conf_data/pa_type/krbtgt\/SECURITY.BASEOS.QE\@SECURITY.BASEOS.QE@X-CACHECONF: in DIR::/run/user/0/krb5cc/tkt79CGND
[root@dspurek ~]# klist
Ticket cache: DIR::/run/user/0/krb5cc/tkt79CGND
Default principal: Amy.QE

Valid starting       Expires              Service principal
05/09/2013 03:48:39  05/09/2013 13:48:39  krbtgt/SECURITY.BASEOS.QE.QE
	renew until 05/16/2013 03:48:39

Comment 2 Kaushik Banerjee 2013-05-09 08:01:43 UTC
I also hit this issue when my clock was set 2 days behind:

[1676] 1367899212.891708: Getting initial credentials for Administrator
[1676] 1367899212.892128: Sending request (190 bytes) to SSSDAD.COM
[1676] 1367899212.894928: Resolving hostname pluto.sssdad.com.
[1676] 1367899212.896255: Sending initial UDP request to dgram 10.65.206.100:88
[1676] 1367899212.897295: Received answer from dgram 10.65.206.100:88
[1676] 1367899212.898295: Response was not from master KDC
[1676] 1367899212.898507: Received error from KDC: -1765328359/Additional pre-authentication required
[1676] 1367899212.898729: Processing preauth types: 16, 15, 19, 2
[1676] 1367899212.898928: Selected etype info: etype rc4-hmac, salt "", params ""
Password for Administrator:
[1676] 1367899216.620275: AS key obtained for encrypted timestamp: rc4-hmac/A247
[1676] 1367899216.620361: Encrypted timestamp (for 1368085520.110017): plain 301AA011180F32303133303530393037343532305AA105020301ADC1, encrypted DA6E5EA3D56886D8CFA5FC6D78011F8FD734292CE1920C905B09383B651DFDA48AF8EE950722796092F8D7E444C98606B6F40AE1
[1676] 1367899216.620424: Preauth module encrypted_timestamp (2) (flags=1) returned: 0/Success
[1676] 1367899216.620434: Produced preauth for next request: 2
[1676] 1367899216.620463: Sending request (266 bytes) to SSSDAD.COM
[1676] 1367899216.622219: Resolving hostname pluto.sssdad.com.
[1676] 1367899216.623462: Sending initial UDP request to dgram 10.65.206.100:88
[1676] 1367899216.624689: Received answer from dgram 10.65.206.100:88
[1676] 1367899216.625597: Response was not from master KDC
[1676] 1367899216.625765: Received error from KDC: -1765328373/Requested effective lifetime is negative or too short
[1676] 1367899216.625939: Preauth tryagain input types: 16, 15, 19, 2
[1676] 1367899216.626191: Retrying AS request with master KDC
[1676] 1367899216.626412: Getting initial credentials for Administrator
[1676] 1367899216.626645: Sending request (190 bytes) to SSSDAD.COM (master)
kinit: Requested effective lifetime is negative or too short while getting initial credentials

Comment 3 Patrik Kis 2013-05-09 09:53:37 UTC
I think klist, when shows the ticket validity and expiration time, it should recount it to local time. The local user does not know/care that there is a time difference between the server and client.
Now klist shows the time from server.


[root@pkisf19 ~]# date
Thu May  9 11:50:14 CEST 2013
[root@pkisf19 ~]# kdestroy; kinit Bender.QE; klist 
Password for Bender.QE: 
Ticket cache: DIR::/run/user/0/krb5cc/tkt198nJk
Default principal: Bender.QE

Valid starting       Expires              Service principal
05/09/2013 11:50:06  05/09/2013 21:50:06  krbtgt/AD.BASEOS.QE.QE
	renew until 05/16/2013 11:50:06
[root@pkisf19 ~]# 
[root@pkisf19 ~]# 
[root@pkisf19 ~]# date -s "Fri May 11 11:50:08 CEST 2013"
Sat May 11 11:50:08 CEST 2013
[root@pkisf19 ~]# date
Sat May 11 11:50:10 CEST 2013
[root@pkisf19 ~]# kdestroy; echo 'Pass2012!' | kinit Bender.QE; klist 
Password for Bender.QE: 
Ticket cache: DIR::/run/user/0/krb5cc/tkt47x2eN
Default principal: Bender.QE

Valid starting       Expires              Service principal
05/09/2013 11:51:15  05/09/2013 21:51:15  krbtgt/AD.BASEOS.QE.QE
	renew until 05/16/2013 11:51:15
[root@pkisf19 ~]#

Comment 4 Karel Srot 2013-05-09 10:53:59 UTC
(In reply to comment #3)
> I think klist, when shows the ticket validity and expiration time, it should
> recount it to local time. 

I think that server time is what (in the end) matters the most. But there should be a way do find out that the server/client time differs and maybe a way how to get the validity with respect to client/server time.

Also, there should be probably a timezone info. 

And both time/timezone details should be explained in the man page.

Comment 5 Stef Walter 2013-05-22 16:15:47 UTC
Patch upstream for the error above: http://mailman.mit.edu/pipermail/krbdev/2013-May/011567.html

Comment 6 Stef Walter 2013-06-12 16:04:24 UTC
Patches available upstream:

commit 73cec24defdc9bf203a39f2e1059ec74e5a32dd9
Author: Greg Hudson <ghudson>
Date:   Sun Jun 2 01:22:38 2013 -0400

    Use KDC clock skew for AS-REQ timestamps
    
    Calculate request timestamps each time we encode a request, and use
    the adjusted current time when calculating them, including adjustments
    resulting from preauth-required errors early in the AS exchange.
    
    As a side effect, this reverts one of the changes in commit
    37b0e55e21926c7875b7176e24e13005920915a6 (#7063); we will once again
    use the time adjustment from any ccache we read before the AS
    exchange, if we don't have a more specific adjustment from a
    preauth-required error.
    
    Based on a patch from Stef Walter.
    
    ticket: 7657 (new)

commit f2600131fb358339ceccecb1c80af7d471c0501b
Author: Greg Hudson <ghudson>
Date:   Sun Jun 2 00:31:04 2013 -0400

    Refactor AS-REQ nonce and timestamp handling
    
    Create helper functions to set the request nonce and to set the
    request timestamp.  Don't bother picking a nonce in
    restart_init_creds_loop since we will just pick a new one in
    init_creds_step_request.  Create a library-internal function to get
    the current time with possible adjustment from a preauth-required
    error.  Only set ctx->request_time in one place (just before encoding
    each request).  Remove unused parameters from stash_as_reply.
    
    Partially based on a patch from Stef Walter.

Comment 7 Stef Walter 2013-06-12 17:10:50 UTC
Thanks for backporting these patches Nalin. 

https://admin.fedoraproject.org/updates/FEDORA-2013-9820/krb5-1.11.3-1.fc19

Set date forwards and backwards on domain server, and tested that things work without failure.

Set date back on domain server:

$ kinit Administrator.LAN
Password for Administrator.LAN: 
$ klist
Ticket cache: DIR::/run/user/1000/krb5cc_709da4600242217bc33ef4f251b7fd00/tkt2Yb105
Default principal: Administrator.LAN

Valid starting       Expires              Service principal
09.06.2013 19:05:59  10.06.2013 05:05:59  krbtgt/BORG.THEWALTER.LAN.LAN
	renew until 16.06.2013 19:05:55
09.06.2013 19:06:28  10.06.2013 05:05:59  ldap/win-fi8gnnit6cj.borg.thewalter.lan.LAN
	renew until 16.06.2013 19:05:55
$ ldapwhoami -H ldap://win-fi8gnnit6cj.borg.thewalter.lan -Y GSSAPI 
SASL/GSSAPI authentication started
SASL username: Administrator.LAN
SASL SSF: 56
SASL data security layer installed.
u:BORG\Administrator

And then forward:

$ kinit Administrator.LAN
Password for Administrator.LAN: 
$ klist
Ticket cache: DIR::/run/user/1000/krb5cc_709da4600242217bc33ef4f251b7fd00/tkt2Yb105
Default principal: Administrator.LAN

Valid starting       Expires              Service principal
23.06.2013 19:06:59  24.06.2013 05:06:59  krbtgt/BORG.THEWALTER.LAN.LAN
	renew until 30.06.2013 19:06:55
$ ldapwhoami -H ldap://win-fi8gnnit6cj.borg.thewalter.lan -Y GSSAPI 
SASL/GSSAPI authentication started
SASL username: Administrator.LAN
SASL SSF: 56
SASL data security layer installed.
u:BORG\Administrator


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