Re: Question about TGT forwarding
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 workstationstorage 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
RE: Question about TGT forwarding
On Thu, May 31, 2018 at 04:50:36PM -0400, Jason Edgecombe wrote: [...] > 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. Everything worked fine a > few weeks ago. Windows' own Kerberos client code will only send a delegated TGT if the service ticket contained the OK-AS-DELEGATE flag. If the KDC issuing the service ticket is Active Directory, it will only set the OK-AS-DELEGATE flag in the service ticket if the Active Directory object for the target of that service ticket has the UF_TRUSTED_FOR_DELEGATION flag set. In the "Active Directory Users and Computers" GUI, on the Delegation tab, choosing “Trust this user/computer for delegation to any service (Kerberos only)” enables that flag. So one possibility, I suppose, is that a few weeks ago you were using a service account that was configured that way and now you aren't. But if, as Ben points out, your Kerberos client code is some other Kerberos implementation then none of this may be relevant. Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
