Windows KDC - Delegation Option

[Ben H]

Great - thanks Greg - beginning to be much clearer.

So the TGT from B is actually a full request for the forwardable ticket
(not just a notification) and it gets sent right to the remote machine and
not cached locally.
I can confirm this with the issued time stamp not changing on the host, but
showing the current time on the remote.

Regarding the first question about the same ticket being cached with
different names... I'm sure this output has led to confusion with me
before, as I can't often justify what some of the tickets in the cache are
for:

Is there some way to show a mapping that these two tickets are really
identical?
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?
Is it possible to avoid this situation by a more thorough configuration of
krb5.conf?
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?)

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.

TIA




On Fri, Apr 25, 2014 at 5:45 PM, Greg Hudson <ghudson at mit.edu> wrote:

> On 04/25/2014 06:04 PM, Ben H wrote:
> > 04/25/14 16:34:02  04/26/14 02:31:06  host/centos64-01.mydomain.local@
> >         Flags: FA
> > 04/25/14 16:34:02  04/26/14 02:31:06
>  host/centos64-01.mydomain.local at MYDOMAIN.LOCAL
> >         Flags: FA
>
> These are the same ticket cached under two different names.
>
> When a client cannot determine the realm of a remote host
> authoritatively (via krb5.conf [domain_realm] in a typical setup), it
> tries to use referrals using the client principal realm.  Internally, a
> service principal is represented with an empty realm to mean "we don't
> know the realm yet."  Once the ticket is obtained, it is cached under
> the canonical service name with realm, and also under the internal "we
> don't know the realm yet" name so that the referral request does not
> have to be repeated.
>
> > Can I assume this means that the FfA krbtgt on the destination station
> > was passed directly from the host over the application (ssh) and no
> > additional tickets are necessary (at least until destination needs to
> > request one on my behalf)?
>
> Correct, but the ticket that was forwarded to the remote server was not
> cached on the client.
>
> > Additionally, the two TGS-REQ/TGS-REP pairs transmitted between host and
> > KDC are of the following nature:
> > A - KDC_REQ_BODY is for host/centos64-01.mydomain.local FORWADABLE,
> > CANONICALIZE
> > B - KDC_REQ_BODY is for krbtgt/MYDOMAIN.LOCAL FORWARDABLE, FORWARDED
> >
> > I don't understand how A and B map to ticket's #2 and #3 above.
>
> A maps to tickets #2 and #3.  B maps to the ticket in the remote realm's
> cache.
>
> > Additionally, what purpose is request B performing?  Is it simply a
> > request to tell the KDC that my ticket *has* been forwarded to a remote
> > system?  If so what is the necessity for this notification and response
>
> For two reasons, one no longer important in most deployments:
>
> 1. Tickets can have IP address restrictions, in which case you need to
> get a new TGT with the address of the remote host.  IP address
> restrictions have fallen out of favor because of NATs, but they used to
> be common.
>
> 2. The new TGT has a different session key from your original TGT, which
> means the remote host cannot use that credential to decrypt
> communications made using your original TGT.
>