Windows KDC - Delegation Option

[Vipul Mehta]

Yes, the TGT is passed directly by the host.

Please read the section "Messages in the Forwarding Process" here :
http://technet.microsoft.com/en-us/library/4a1daa3e-b45c-44ea-a0b6-fe8910f92f28

It explains the steps clearly with the diagram.


On Sat, Apr 26, 2014 at 3:34 AM, Ben H <bhendin at gmail.com> wrote:

> 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
>>
>
>


-- 
Regards,
Vipul