kinit -S and krb 1.6
Mark Phalan
Mark.Phalan at Sun.COM
Mon Jul 30 13:00:26 EDT 2007
I've been syncing the client-side referrals code from 1.6 to Solaris
Nevada.
During testing I came arross an interesting problem.
Unless the krb5.conf file is properly populated (and no fallbacks are
being used) "kinit -S" is essentially rendered useless.
e.g
$ kinit -S host/zup.czech.sun.com mark
-> stores host/zup.czech.sun.com at SUN.COM in the cred-cache
$ ssh zup.czech.sun.com
-> looks for host/zup.czech.sun.com@ in the cred-cache and fails.
I've verified that is what happens with the MIT code (1.6.2).
A possible fix might be to modify krb5_get_init_creds() so that if a
service ticket is requested and the specified server principal has an
empty realm then cache the server with the empty realm rather than the
server with the client realm.
$ kinit -S host/zup.czech.sun.com@ mp153739
$ ssh zup.czech.sun.com
will now work (in a fallback environment but fail in a non-fallback
environment)
but
$ kinit -S host/zup.czech.sun.com mp153739
$ ssh zup.czech.sun.com
will still fail.
Another possible solution (from Nico) is to always cache both forms of
the server principal (with and without the realm) when getting an
initial non-TGT ticket, this should always work.
The fundamental problem is that its not known how the service name
passed to krb5_get_init_creds() was generated and hence its not clear
how to cache the resulting principal - with or without the realm.
in_tkt_service may have been generated from a principal which had been
generated with sname_to_princ() or may not even be a host based
principal.
This problem also shows its head in the way our (Solaris) kadmin works.
It gets an initial service ticket which is cached in a memory cache but
then cannot find it as the server realm names don't match ("" != REALM).
-Mark
More information about the krbdev
mailing list