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