Time of new TGT from krb5_get_init_creds_password
csimpson at csl.co.uk
Sun Mar 25 07:54:43 EDT 2007
I've been having a problem with a gnome app called krb5-auth-diag.
This monitors your TGT for expiry and then brings up a dialog that
prompts for a new password. This normally works fine, however if the
user should get this prompt when they are not present, it sits there waiting
for the password which could be longer than the new TGT interval say overnight.
When they enter the new password it gets a TGT that is valid from the
time the password prompt is given. So they immediately get an invalid TGT.
Quite confusing for users.
I traced this down to a call to krb5_get_init_creds_password that is
called with the gnome window being the prompter function passed to it.
I looked further into this and it turns out kinit behaves this way too.
Obviously not a huge problem for it as it isn't run over a long period of
So, if I have shell1 and shell2 on different terminals.
Password for csimpson at UNIX.CSL.CO.UK:
Sun Mar 25 12:41:22 BST 2007
(wait for a little while)
Sun Mar 25 12:42:44 BST 2007
(type password into kinit on shell1)
Ticket cache: FILE:/tmp/krb5cc_2000_UAdQxX
Default principal: csimpson at UNIX.CSL.CO.UK
Valid starting Expires Service principal
03/25/07 12:41:08 03/25/07 22:41:08 krbtgt/UNIX.CSL.CO.UK at UNIX.CSL.CO.UK
renew until 04/01/07 12:41:08
So I have a TGT valid from the time it prompted and not now. So I presuming
that krb5_get_init_creds_password goes and gets the TGT before it asks for
the password. I suppose there are probably valid reasons for this like
checking the principal exists or whether the password has expired before
But how should TGT monitors handle this? Or can you persuade
krb5_get_init_creds_password to go and get a new TGT if a long time has
passed or probably better the TGT it's decrypted with the password is
Colin Simpson - csimpson at csl.co.uk
Concept Systems Ltd
More information about the krbdev