> 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@realm
Password for test/bdatadevkdc01.northamerica.net@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@realm
Valid starting Expires Service principal
10/16/2017 11:05:05 10/16/2017 11:07:05 krbtgt/realm@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@realm
Valid starting Expires Service principal
10/16/2017 11:07:27 10/16/2017 11:08:39 krbtgt/realm@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@realm
Valid starting Expires Service principal
10/16/2017 11:07:27 10/16/2017 11:08:39 krbtgt/realm@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" <[email protected]> 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.
________________________________________________
Kerberos mailing list [email protected]
https://mailman.mit.edu/mailman/listinfo/kerberos
