Possible kinit -R bug rhel 7.3 pkg 1.14.1-27.el7_3 and a few questions

[Hostetler,Alex]

> Releases 1.12 through 1.15
    will not issue "trivially renewable tickets", where renewable endtime
    doesn't exceed ticket endtime; instead it will issue a non-renewable
    ticket.  The forthcoming release 1.16 will go back to issuing trivially
    renewable tickets.

I think this may answer all my questions, we were previously using 1.10.3-33.1.sf1257154.el6 and jumped up to 1.14.  But I’ll try to explain the issues a bit better just so I’m clear.


11:02:22 $ kinit test/bdatadevkdc01.northamerica.net at realm
Password for test/bdatadevkdc01.northamerica.net at realm:

11:02:40 $ sleep 140; kinit -R; klist -ef; sleep 140; kinit -R; klist -ef
Ticket cache: FILE:/tmp/krb5cc_17105570
Default principal: test/bdatadevkdc01.northamerica.net at realm

Valid starting       Expires              Service principal
10/16/2017 11:05:05  10/16/2017 11:07:05  krbtgt/realm at realm
renew until 10/16/2017 11:08:39, Flags: FRIT
Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96
Ticket cache: FILE:/tmp/krb5cc_17105570
Default principal: test/bdatadevkdc01.northamerica.net at realm


Valid starting       Expires              Service principal
10/16/2017 11:07:27  10/16/2017 11:08:39  krbtgt/realm at realm
Flags: FRIT, Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96


11:07:27 $ kinit -R
kinit: Ticket expired while renewing credentials

-----> Here is where our packages differ, with 1.14 we get a ticket expired, with 1.10.3-33.1.sf1257154.el6, we would just see the valid starting date get updated.
Another thing that is different between the two versions is the lack of a renew until time on the klist above this kinit –R. It still has a renewable flag, which confused me a bit.


11:07:51 $ klist -ef
Ticket cache: FILE:/tmp/krb5cc_17105570
Default principal: test/bdatadevkdc01.northamerica.net at realm

Valid starting       Expires              Service principal
10/16/2017 11:07:27  10/16/2017 11:08:39  krbtgt/realm at realm
Flags: FRIT, Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96

My third question was around the above, we still see the ticket and it looks like it’s within the valid times, but above the ticket expired on the above kinit –R.  This is reflected in our env and the ticket no longer functions, but has presented issues with our automation.  We’ve worked around those issues now, so this is mostly for my understanding.

I believe both of these questions are explained by the “trivially renewable tickets” and links you posted.

Thank you so much! I’ve had a support case open with redhat about these issues for 2+ months and it didn’t get anywhere.

Alex H.


On 10/16/17, 10:43 AM, "Greg Hudson" <ghudson at mit.edu> wrote:

    On 10/16/2017 11:03 AM, Hostetler,Alex wrote:
    > Here the ticket lifetime is 2 mins, renew time is 6 mins.  We sleep for 140 seconds and are still able to renew the ticket anyway.  I believe this is a bug.

    Because the client and KDC clocks might drift, the KDC applies a grace
    period to ticket expiration, defaulting to five minutes.  I think that's
    what you are seeing here, as the ticket has only been expired for 20
    seconds in this scenario.

    > Similar situation.  Ticket lifetime is 2 mins, renewable for 6.  When we get to the 5th min of the renew until time, where if we were to kinit –R again the expiration date would be outside of that renew until time, should the ticket expire or should the valid starting time just be updated and the expiration time capped?  We had a patched package that did things the latter way and the regular 1.14 packages that do it the former.

    I can't figure out what "5th min of the renew until time" means here.
    Are you talking about five minutes after the initial ticket issuance
    time, or seven?  When you say "lifetime is 2 mins, renewable for 6", is
    the renewable end time six minutes after the initial ticket issuance
    time (what I would expect), or eight?  I'm also not sure what you mean
    by "should the ticket expire?"

    Although I don't understand the question, I can say there have been some
    changes in KDC behavior around this area.  Releases 1.12 through 1.15
    will not issue "trivially renewable tickets", where renewable endtime
    doesn't exceed ticket endtime; instead it will issue a non-renewable
    ticket.  The forthcoming release 1.16 will go back to issuing trivially
    renewable tickets.

    https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fkrbdev.mit.edu%2Frt%2FTicket%2FDisplay.html%3Fid%3D7661&data=02%7C01%7CAlex.Hostetler%40cerner.com%7Cff7d917014ca4fb6e1ba08d514aac68a%7Cfbc493a80d244454a815f4ca58e8c09d%7C0%7C0%7C636437646064443994&sdata=Pir0pynTpeB%2FgDsqNEkBAYCBaJszf%2BJaEHS6T30FvdU%3D&reserved=0
    https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fkrbdev.mit.edu%2Frt%2FTicket%2FDisplay.html%3Fid%3D8609&data=02%7C01%7CAlex.Hostetler%40cerner.com%7Cff7d917014ca4fb6e1ba08d514aac68a%7Cfbc493a80d244454a815f4ca58e8c09d%7C0%7C0%7C636437646064443994&sdata=MaLgwzd%2BgGyu0MFraiejQFdQtIYv3xeyPTIDqxK2uUM%3D&reserved=0

    > This may be answered in the above, but when we kinit –R in a situation like the second problem, at the end of the renew until time so the ticket lifetime would put it outside of that window.  We see the ticket expire in 1.14, but when doing a klist the ticket still looks valid since it shows it within the valid starting time and expiration date.  The ticket no longer functions – as expected from the output of kinit –R, is the expired ticket displayed in any way to klist?

    I don't think the KDC should ever issue a ticket which is already
    expired.  I'd like to see more specifics about this case.




CONFIDENTIALITY NOTICE This message and any included attachments are from Cerner Corporation and are intended only for the addressee. The information contained in this message is confidential and may constitute inside or non-public information under international, federal, or state securities laws. Unauthorized forwarding, printing, copying, distribution, or use of such information is strictly prohibited and may be unlawful. If you are not the addressee, please promptly delete this message and notify the sender of the delivery error by e-mail or you may call Cerner's corporate offices in Kansas City, Missouri, U.S.A at (+1) (816)221-1024.