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