| raw e-mail | index | archive | help
On Mon, Apr 15, 2024 at 12:53=E2=80=AFPM Andreas Kempe <kempe@lysator.liu.s= e> wrote: > > On Sun, Apr 14, 2024 at 12:30:22PM -0700, Rick Macklem wrote: > > On Sun, Apr 14, 2024 at 8:26=E2=80=AFAM Andreas Kempe <kempe@lysator.li= u.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=3Dsys? It depends on what mount options are used. For FreeBSD clients, sec=3Dsys is the default, so that is what will be used unless "sec=3Dkrb5" is specifi= ed. I am not sure how the Linux client decides this. (It may be sec=3Dsys 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?>