Question about TGT forwarding

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Question about TGT forwarding

Edgecombe, Jason-2
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
[hidden email] | 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           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Question about TGT forwarding

Benjamin Kaduk-2
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           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

RE: Question about TGT forwarding

Thomas Maslen (tmaslen)
In reply to this post by Edgecombe, Jason-2
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           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Question about TGT forwarding

Jeffrey Altman-2
In reply to this post by Edgecombe, Jason-2
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





________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Question about TGT forwarding

Edgecombe, Jason-2
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
[hidden email] | 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 <[hidden email]
> 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
>
>
>
>
>
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Question about TGT forwarding

Benjamin Kaduk-2
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 0x60a10000 -> 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           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos