[37486] in Kerberos

home help back first fref pref prev next nref lref last post

Forwardable TGT - Windows vs MIT behavior?

daemon@ATHENA.MIT.EDU (Ray Van Dolson)
Sat Apr 23 12:42:06 2016

Date: Sat, 23 Apr 2016 09:41:47 -0700
From: Ray Van Dolson <rvandolson@esri.com>
To: kerberos@mit.edu
Message-ID: <20160423164147.GA12530@esri.com>
MIME-Version: 1.0
Content-Disposition: inline
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu

Using PuTTY from a domain-joined Windows 7 machine, with that machine's
PuTTY stack configured to allow credential delegation and connecting to
a RHEL7 server, also joined to AD but *not* configured in AD to be
trusted for delegation, I do not get a TGT added to my cache when I
connect.

However, if I use MIT Kerberos on the Windows side to obtain the ticket
and then configure PuTTY to prefer MIT over MS SPI, and connect to the
same RHEL7 machine, I *do* get a forwarded TGT (klist -f: Flags: FfPRA)

PuTTY w/ MS SSPI works *if* I go into AD and set the target server up
to be configured for delegation trust.

Can someone explain the difference in behavior?  Almost feels like the
ticket the MIT stack is providing to PuTTY is different than the MS
stack's ticket.

I also see this alluded to elsewhere[1].

Thanks,
Ray

[1] http://serverfault.com/questions/646854/putty-kerberos-gssapi-authentication/705889#705889
________________________________________________
Kerberos mailing list           Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

home help back first fref pref prev next nref lref last post