Windows KDC - Delegation Option

[Ben H]

That's interesting - thank you.  I was able to actually validate what you
stated by installing MIT Kerberos on my Window system and then configuring
Putty's GSSAPI option to use the MIT GSSAPI libraries as preference.
My first attempt with kfw-4.0.1 was unsuccessful and I suspect it has to do
with how 4.01 integrates into the Windows LSA cache - I didn't seem able to
separate my Windows tickets from the MIT ones (init/destroy in one location
reflected in the other).  I suspect I may have been able to find a way to
configure it, but 4.01 seems very turnkey and I couldn't quickly find some
way to customize this behavior.

When I backed down to kfw-3.2.2 I was able to see a separation in the
credentials and then when setting the MIT GSSAPI higher in the preference
order, it indeed forwarded the creds despite the computer object not being
trusted.  When i placed Windows SSPI higher in the preference, it once
again failed to delegate.

That test confirms and solidifies this concept for me much better, but I
still have some questions regarding the actual passing of the tickets
between these machines.  I apologize that I may exacerbating what is
standard traffic, but in the context of forwarded tickets I have some
confusion.

FIRST, I kinit (-f) to get a TGT for my user on my host station.  When I
examine with klist I see a single ticket of the following format:

Default principal: jsmith at MYDOMAIN.LOCAL
Valid starting     Expires            Service principal
04/25/14 16:31:06  04/26/14 02:31:06  krbtgt/MYDOMAIN.LOCAL at MYDOMAIN.LOCAL
        Flags: FIA

The traffic on the wire consists of a single AS-REQ/AS-REP (exclusive of
preauth and too_big) as to be expected.

THEN, I initiate my SSH connection using this forwardable ticket and the
result is the following:

On my host station:

Default principal: jsmith at MYDOMAIN.LOCAL

Valid starting     Expires            Service principal
04/25/14 16:31:06  04/26/14 02:31:06
krbtgt/MYDOMAIN.LOCAL at MYDOMAIN.LOCAL
<-----------------original ticket (#1)
        Flags: FIA
04/25/14 16:34:02  04/26/14 02:31:06  host/centos64-01.mydomain.local@
     <--------------new ticket (#2)
        Flags: FA
04/25/14 16:34:02  04/26/14 02:31:06
 host/centos64-01.mydomain.local at MYDOMAIN.LOCAL
<----------------------new ticket (#3)
        Flags: FA

On my destination station:

Default principal: jsmith at MYDOMAIN.LOCAL

Valid starting     Expires            Service principal
04/25/14 16:34:02  04/26/14 02:31:06  krbtgt/MYDOMAIN.LOCAL at MYDOMAIN.LOCAL
        Flags: FfA


NOW, this shows that 2 new tickets have been received on my host station,
and one ticket has been received (forwarded) to my destination.

What I am confused about is that the wire shows only the transmission of
two TGS-REQ/TGS-REP pairs from my host station to the KDC.  There is no
Kerberos exchange at all from the destination to the KDC.
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)?

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 seems to be the TGS-REQ that created #2, but what is this secondary
ticket #3 that exists with the additional appended Realm and why is that
not shown in any exchange on the wire?
Does it have anything to do with the CANONICALIZE request?

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

Feel free to point me to any specific RFC sections which describe the
specific traffic and ticket issuance I am confused on - though a bit of a
layman's explanation won't hurt either!

TIA


On Fri, Apr 25, 2014 at 1:48 PM, Vipul Mehta <vipulmehta.1989 at gmail.com>wrote:

> Your understanding is correct but credential delegation requirements are
> API dependent instead of platform.
>
> For Unix :
> Putty uses MIT Kerberos - GSS API. When you enable delegation in putty it
> requests GSS_C_DELEG_FLAG instead of GSS_C_DELEG_POLICY_FLAG which doesn't
> check ok_as_delegate_flag, hence there is no need to set delegation option
> in Active Directory for credential delegation.
>
> For Windows:
> Putty uses SSPI in my opinion which requires delegation option in Active
> Directory to be set for credential delegation as it checks
> ok_as_delegate_flag.
>
> This is all based on my understanding of Kerberos. Someone having more
> experience can please correct if i am wrong here.
>
> On Fri, Apr 25, 2014 at 11:40 PM, Ben H <bhendin at gmail.com> wrote:
>
>> From what I am reading here it would appear that this behavior is
>> expected as the Unix systems (MIT) will forward a ticket regardless of the
>> ok_as_delegate flag.  IOW, Windows systems require the host to show
>> ok_as_delegate in order to forward a ticket, whereas Unix systems do not.
>>
>>
>>
>
> --
> Regards,
> Vipul
>