Question about TGT forwarding

[Jeffrey Altman]

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




-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4080 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mailman.mit.edu/pipermail/kerberos/attachments/20180601/08a5cddf/attachment.bin