[28966] in Kerberos
Re: Tickets Longer Than Wanted?
daemon@ATHENA.MIT.EDU (Tom Yu)
Fri Jan 4 17:32:59 2008
To: John Hascall <john@iastate.edu>
From: Tom Yu <tlyu@mit.edu>
Date: Fri, 04 Jan 2008 17:32:43 -0500
In-Reply-To: <3040.1198978850@malison.ait.iastate.edu> (John Hascall's message
of "Sat, 29 Dec 2007 19:40:50 CST")
Message-ID: <ldvlk752pdg.fsf@cathode-dark-space.mit.edu>
MIME-Version: 1.0
Cc: kerberos@mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
>>>>> "John" == John Hascall <john@iastate.edu> writes:
John> Given the following code snippet:
krb5_creds rq;
time_t now = time(NULL);
memset(&rq, 0, sizeof(rq));
rq.times.starttime = now;
rq.times.endtime = now + 1024;
rq.client = iasc->sc_k5_me;
rq.server = server;
k5_err = krb5_get_in_tkt_with_keytab(iasc->sc_k5_context, 0,
NULL, NULL, NULL,
iasc-sc_k5_keytab,
NULL, &rq, NULL);
John> Why am I getting tickets with a 1 day (86400 second) lifetime?
John> (I was trying to test with a short lifetime to see if some
John> ticket-renewing code was working correctly and waiting a day
John> to do each test is hopeless).
The krb5_get_in_tkt functions are deprecated; please use
krb5_get_init_creds functions instead. Also, what release are you
running? Some of the code in krb5_get_in_tkt_with_keytab() has
changed over time, possibly fixing bugs affecting your problem. I
believe that there was a bug in krb5-1.3 affecting
krb5_get_in_tkt_with_keytab() in exactly this way.
If you are seeing this behavior with a recent release, we would
appreciate hearing more details.
Some alternatives may include setting the KDC ticket lifetime for one
particular principal that you are testing.
---Tom
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
