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
smime.p7s
Description: S/MIME Cryptographic Signature
________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos