get_cred starting realm

[Nico Williams]

I should also add that every case I know of today where an application
initializes a ccache (with any implementation, Heimdal, MIT, GNU, Java)
the first local TGT stored *is* the TGT that is "intended" as the one to
use for starting TGS requests (for that realm, certainly, and for any
TGS clients that support referrals chasing from a "home" realm).

KRB-CRED supports forwarding multiple tickets, but in practice we only
ever forward a single TGT.  And kinit-like applications generally only
store the one TGT they fetch.

The effect is that the first local TGT stored after initializing is
always (today) the TGT that's intended as the starting TGT.

There may be (there are) ccache copy/refresh applications that
initialize a ccache and store refreshed versions of all tickets found
in the original ccache.  Typically such applications iterate through the
source ccache, and they will tend to find the "intended" starting TGT as
the first TGT (in most ccache types).  And, of course, if the
start-realm ccconfig is present in the source ccache, then it will be
preserved.

So in practice the heuristic I implemented will interop correctly with
implementations that don't implement the start-realm ccconfig.

We should update applications to store an explicit start-realm ccconfig
when that would be different from the heuristic (or even always, when it
is known).  In practice the default heuristic works for kinit and
gss_acquire_cred_with_password() and so on, so no applications will need
modification initially.

Nico
--