Re: Kerberised NFSv4 - everyone gets mapped to nobody on file access

On Mon, Apr 15, 2024 at 12:53 PM Andreas Kempe <kempe@lysator.liu.se> wrote:
>
> On Sun, Apr 14, 2024 at 12:30:22PM -0700, Rick Macklem wrote:
> > On Sun, Apr 14, 2024 at 8:26 AM Andreas Kempe <kempe@lysator.liu.se> wrote:
> > > Am I correct in thinking that Kerberos isn't really designed to be
> > > used for only authenticating the machine? Users having to always have
> > > their own valid Kerberos ticket doesn't really work for us.
> > Yes. The "host" keytab credential is a "hack". Kerberos calls them
> > service principals and they were not intended to authenticate a machine
> > when Kerberos was designed.
> >
> > If users are running cron jobs, then one way around the problem
> > is to have the KDC issue renewable tickets and then run a daemon
> > (can't remember the name, but it is easy to find and opensourced)
> > that renews TGTs. (This only works up to the renew limit of the KDC
> > config.)
> >
>
> I have seen that this should be possible, the Linux SSSD daemon can do
> that. We do still have the issue of users having to log on to every
> system after a reboot to init a ticket so I still don't think it would
> be ideal for us.
>
> > NFS-over-TLS (called RPC-over-TLS by the Linux folk) does allow
> > a client to provide a X.509 certificate during TLS handshake to
> > identify the client machine and the TLS encrypts everything on
> > the wire to avoid middleman attacks or snoopers.
> > It does not identify users on the server, unless TLS identity
> > squashing is used via the X.509 certificate to make all RPCs
> > done by a user. (This has the advantage that it is not "nobody",
> > but is only useful for things like laptops, that are only used by
> > one user. It does have the advantage that there are no tickets
> > to expire, although there is a, usually long, expiration on the X.509
> > certificate.)
> >
>
> If I'm running NFS with TLS without TLS identity squashing, does this
> mean that users are resolved the same way they are with sec=sys?
It depends on what mount options are used. For FreeBSD clients, sec=sys
is the default, so that is what will be used unless "sec=krb5" is specified.

I am not sure how the Linux client decides this.
(It may be sec=sys as well, but I am not sure?)

> If
> so, this could be the solution we are looking for if I can make sure
> that all our Linux systems that need to mount have a new enough Linux
> kernel to support it.
Yep. I know the kernel patches now exist, but I do not know what kernel
version you need to get them.

rick

>
> // Andreas Kempe