Question about TGT forwarding

[Jason Edgecombe]

Hi Jeffrey,

All of the Windows 10 and RHEL7/CentOS7 machines are domain joined. All
user accounts are domain accounts. The ssh client on windows is putty 0.70.
GSSAPI authantication and credential delegation are enabled in the putty
settings and the GSSAPI library order preference is MIT, Microsoft, then
user-specified (none). No  3rd-party Kerberos libraries or tools are
installed on the Win10 machines. It's purely the Microsoft native Kerberos
implementation. MIT Kerberos and Heimdal are not in the mix at all.

Running "klist" when logged on to Windows 10 with my domain account shows
the following flags for my krbtgt/DOMAIN entry:

Ticket Flags 0x60a10000 -> forwardable forwarded renewable pre_authent
name_canonicalize


As an extra data point, This might have started changing behavior after the
Linux machines were upgraded from Centos/RHEL 7.4 to 7.5.

I'm going to play around with the Credential delegation settings on the
machine account in AD and see how well that works.

Thanks,
Jason

---------------------------------------------------------------------------
Jason Edgecombe | Linux Administrator
UNC Charlotte | The William States Lee College of Engineering
9201 University City Blvd. | Charlotte, NC 28223-0001
Phone: 704-687-1943
jwedgeco at uncc.edu | http://engr.uncc.edu |  Facebook
---------------------------------------------------------------------------
If you are not the intended recipient of this transmission or a person
responsible for delivering it to the intended recipient, any disclosure,
copying, distribution, or other use of any of the information in this
transmission is strictly prohibited. If you have received this transmission
in error, please notify me immediately by reply e-mail or by telephone at
704-687-1943.  Thank you.

On Fri, Jun 1, 2018 at 4:30 PM, Jeffrey Altman <jaltman at secure-endpoints.com
> wrote:

> On 5/31/2018 4:50 PM, Jason Edgecombe wrote:
> > Hi everyone,
> >
> > We're noticing some odd behavior on our Windows clients where the Windows
> > clients are not forwarding the TGT to our Linux servers. People can login
> > to the Linux servers from windows clients, but "klist" shows no tickets
> > after login. Linux clients forward the TGT just fine. In case it matters,
> > we just moved our Linux home directories from a NAS with Kerberized SMB
> to
> > a Linux NFS server with Kerberized NFS.
>
> There are aspects of this post that make no sense to me.
>
> You say that everything worked fine a few weeks ago and you imply that
> the only change that was made was a transition from SMB to NFS for home
> directories.
>
> You also imply but do not explicitly state that the Windows clients are
> Active Directory domain joined machines and the end users logged into
> those systems using a domain account with either a password or smart card.
>
> There is no obvious connection between the replacement of the home
> directory file system storage mounted by the linux workstation and
> the failure of SSH GSS-API + Credential Delegation between the windows
> client and the linux workstation.
>
>   windows   ---->    linux          ---->   home directory
>   client             workstation            storage
>
> Clearly there is more to this story that you are failing to describe.
>
> > I've had to disable GSSAPI authentication in openssh so that windows
> > users can still get tickets on the remote end.
>
> Without GSSAPI authentication there is no possibility of delegation but
> you did not specify that the OpenSSH server was configured to request
> delegation.
>
> Nor was it specified what SSH client is being used on Windows and how it
> is configured.  Is it even attempting to delegate?
>
> Does the SSH client use the Windows Kerberos SSP or does it relying upon
> MIT Kerberos or Heimdal for GSS-API support?
>
> Nor were any details provided about the ticket flags on the client's TGT.
>
> > I have a disagreement with our AD guru on whether or not TGTs are
> expected
> > to be forwarded and if that is a security risk.
>
> TGT forwarding is a security risk.  The question is under which
> circumstances is the practice an acceptable risk.
>
> As has been pointed out by another list member, the Windows domain
> provides finer grained control over credential delegation than is
> supported by MIT Kerberos or Heimdal.  The domain administrator can
> whitelist service principals to which the Windows client is permitted to
> delegate.
>
> Jeffrey Altman
>
>
>
>
>