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 <bhen...@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@MYDOMAIN.LOCAL > Valid starting Expires Service principal > 04/25/14 16:31:06 04/26/14 02:31:06 krbtgt/MYDOMAIN.LOCAL@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@MYDOMAIN.LOCAL > > Valid starting Expires Service principal > 04/25/14 16:31:06 04/26/14 02:31:06 krbtgt/MYDOMAIN.LOCAL@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@MYDOMAIN.LOCAL > <----------------------new ticket (#3) > Flags: FA > > On my destination station: > > Default principal: jsmith@MYDOMAIN.LOCAL > > Valid starting Expires Service principal > 04/25/14 16:34:02 04/26/14 02:31:06 krbtgt/MYDOMAIN.LOCAL@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.1...@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 <bhen...@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 ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos