Windows KDC - Delegation Option

[Greg Hudson]

On 04/25/2014 07:16 PM, Ben H wrote:
> Is there some way to show a mapping that these two tickets are really
> identical?

In theory it would be possible to checksum the tickets and tell that
they are the same, but list doesn't know how to do this.

> Is the empty realm display really necessary once we have achieved the
> realm name?  Why do we continue to show it if we have already received
> the realm?

Displaying the entry may not be necessary, but caching it without the
realm is necessary to avoid repeating the TGS request the next time we
try to contact the remote host.  klist is just displaying the entries in
the cache.

> Is it possible to avoid this situation by a more thorough configuration
> of krb5.conf?

Sure, you can add a [domain_realm] entry matching the remote host.  See
http://web.mit.edu/kerberos/krb5-latest/doc/admin/conf_files/krb5_conf.html#domain-realm

> Why would the client be unable to determine the remote realm if I am
> specifying a FQDN (i.e. shouldn't it assume the realm?)

We have a fallback heuristic that f.q.d.n is in the realm F.Q.D, but we
do not consider it authoritative, so we try referrals first.  In many
situations that heuristic would be inaccurate; for instance, hosts in
the mit.edu domain are typically in the realm ATHENA.MIT.EDU, not MIT.EDU.

> Can you point me to what might be the best resource to learn more about
> this feature - as I'm having a hard time understanding the full concept.
>  I wasn't previously aware that the cache could show two tickets that
> were actually the same.

We could probably stand to have better documentation for the client side
behavior of referrals.  Right now I believe all we have is at:
http://web.mit.edu/kerberos/krb5-latest/doc/admin/realm_config.html#mapping-hostnames-onto-kerberos-realms
and the documentation for the associated kdc.conf variables.