#kerberos — Public Fediverse posts

Aaaaaargh, verdammte Hütte: Einfach NEED_IDMAPD=yes und NEED_GSSD=yes in /etc/defaults/nfs-common setzen und alles funzt. Steht's in den gängigen Wikis/Dokus? Nö. Uff. #NFSv4 #Kerberos

I run #NFSv4 on my home network of #Debian systems. It works perfectly well.

I use #SSH to move from system to system and in the past was able to get #Kerberos to work as well between them.

So far I've never been able to get NFS and Kerberos to work at the same time and this bugs me. I will have to try harder to make it work.

I don't strictly need to make it work, all my systems are inside my firewall/NAT but it annoys me that I failed to make it work.

@photocyte ah yes, hashtags, forgot about those.

so, `mount` is setuid and mounting a filesystem as not-root is a totally acceptable and normal thing to be able to do, and the code is nominally set up to do it but it looks a heck of a lot like /[gs]ete?uid/ is being called in lieu of its counterpart, because the net effect is root needs a copy of the non-root user's kerberos ticket as well for it to work, which is SUPER annoying for e.g. ticket renewal

#nfs #nfs4 #nfsv4 #kerberos #krb5

@TomAoki @peteorrall @hl @xdydx I'm surprised ... I didn't expect this to come up in the "enterprise" realm, "just" using kerberized #NFSv4 instead should be pretty fine there and it's probably more the #soho environment that will profit most from some up-to-date #smb client in #FreeBSD 😎 ... but would certainly be very nice to get that!

Also interesting they finally want to move to #MIT #krb5 in base. I'll probably continue to build it from ports, so I can use #LibreSSL instead of #OpenSSL, but still nice, as I found you're e.g. forced to use base #kerberos with the NFS client.

@hl @xdydx #FreeBSD has only support for SMBv1, which you should absolutely avoid for security reasons, although you can probably configure #samba to still allow it ... but ... don't. Nowadays I'd prefer to say FreeBSD does not support mounting SMB shares.

There are some ports available implementing "modern" SMB (v2/v3) on top of #fuse, which might be an option, but in my experience, they're not perfectly reliable and performance isn't the greatest either.

If ever possible, work on the server side and see whether you can share via #NFS instead. Either #NFSv3 (which is only "secure" as long as your network is perfectly secure and you control all participating machines, but at least it doesn't pretend to do anything else), or #NFSv4 with #kerberos security.

@lattera @drscriptt Now here's some document in the hope it might help someone 😎

https://sekrit.de/webdocs/freebsd/nfs-jail-kerberos-samba.html

#FreeBSD #NFS #NFSv4 #jail #kerberos #kerberized #Samba #ActiveDirectory

@drscriptt I'll just dump my understanding of the issue with #kerberos, #nfsv4 and #samba (or #ActiveDirectory) now on here, so if you know better, please correct me 😉

A kerberized service needs an SPN to prove its identity towards clients. This SPN can be attached to any account, it's just best practice to have a dedicated service account. For nfs, it must be named "nfs/<host.fqdn>". The key for this SPN must be available to the server, that's why you have to export it and add it to /etc/krb5.keytab on the server.

To access the service, you need a "service ticket" for its SPN. This can be obtained with your kerberos TGT (ticket-granting ticket). In case of NFS, this is also needed for mounting. And here's the issue with system-wide mounts, there's no user logged into the domain, so you need a "host-based initiator". Basically a key present in the host's /etc/krb5.keytab that's used for the kinit procedure.

[...]

@drscriptt I'm still doing a lot of testing and I guess I now finally have a somewhat good understanding what's going on.

With a samba (Windows AD) domain, you should

* create a service account for the nfs-server and create the nfs SPN in that account, export keytab entries for just that SPN and add them to /etc/krb5.keytab on the NFS server

* set the "host" SPN as UPN on all machine accounts that are NFS clients, including the realm in the UPN, which enables the host-based initiator to work (authenticating as the machine account) for the system-wide mount

I'll try to write that down in some howto soon, #jailed #nfsv4 with #kerberos on #FreeBSD and a #samba domain...

I guess it won't necessarily apply to a directory managed in OpenLDAP though ... 😶