Re: Question about TGT forwarding
On Wed, Jun 06, 2018 at 05:08:19PM -0400, Jason Edgecombe wrote: > > Running "klist" when logged on to Windows 10 with my domain account shows > the following flags for my krbtgt/DOMAIN entry: > > Ticket Flags 0x60a1 -> forwardable forwarded renewable pre_authent > name_canonicalize That's the windows-native klist binary -- it might be interesting to see the KfW klist output, which you can get if you run it with the full path (e.g., C:\Program Files\MIT\Kerberos\bin\klist.exe IIRC) -Ben Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Question about TGT forwarding
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 0x60a1 -> 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 jwedg...@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 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 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 > > > > > Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
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
Re: Question about TGT forwarding
On Thu, May 31, 2018 at 04:50:36PM -0400, Jason Edgecombe wrote: > Hi everyone, > > We're noticing some odd behaviour 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. I've had to disable GSSAPI > authentication in openssh so that windows users can still get tickets on > the remote end. The use of "GSSAPI authentication" seems to imply that a third-party (i.e., not native WindowS) Kerberos implementation is in use. If so, which implementation, and which credentials cache type? > 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. The Windows behavior has changed from release to release; at some points TGTs in the Windows-native "LSA" cache were retrievable only for users that were not (local) Administrators. At this point the limitation may apply to all users, though; I have lost track. Regardless, the behavior of the Windows LSA should only be relevant if the Windows-native credentials are being used. With a Heimdal or MIT KfW implementation, an external tool could be used to obtain tickets outside of the LSA and use those for GSSAPI authentication+delegation, the same as on Linux. -Ben Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Question about TGT forwarding
Hi everyone, We're noticing some odd behaviour 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. I've had to disable GSSAPI authentication in openssh so that windows users can still get tickets on the remote end. 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. Any help is appreciated. 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 jwedg...@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. Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
