Windows KDC - Delegation Option

[Greg Hudson]

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.