WTF is there absolutely nothing useable on the market to allow let's say 100 users to log in onto any of 50 computers and have their home directory mounted from a central server.

- LDAP: does not work with Samba or NFS
- Plain Kerberos... argh how about no?
- Samba Domain Controller: Cannot get it to run
- Active Directory: Windows based, expensive

"Does not work with Samba" is usually caused by the hash-based user logon of Samba.

"Does not work with NFS" is usually: Is not Kerberos

@dunkelstern

What does "does not with with NFS" mean? You can use LDAP as source of user information (using nsswitch.conf) and then UIDs will be consistent across all the machines so configured. What else does NFS require?

@robryk then you have to tightly control that noone can "accidentially" mount the nfs tree on a device on which he has root and can give themselves any uid he wants. In addition, if not secured with kerberos all NFS traffic is un-encrypted and could be sniffed. You'll need `krb5i` if you want to use NFS on a somewhat public network.

@dunkelstern

Ah, you don't trust the terminals. I see.

The only way to avoid using Kerberos that I know of is something that requires quite a bit of scripting: set up a VPN that clients connect to only when a user logs in (and that gives different internal IPs depending on which user authenticated themselves) and use IP-based restrictions in nfs exports. (Alternatively replace VPN with IPSec and dynamic, logged-in-user-dependent, additional IPs.)

@dunkelstern

But also consider how you can realistically avoid trusting the terminals. If they are not assigned to individual users, how does a user verify that the terminal they intend to enter their password on/authenticate themselves in any other way is not running malicious software?

@robryk direct example on where it should be used: Makerspace, we have some PCs that all members of the space should be able to use (for CAD or Office stuff around the space) but I cannot forbid anyone to bring their Laptops and hack away on their own things. Ideally they should be able to use the NAS from their private PCs too, so NFS is out because I cannot enroll all private PCs into a shared Kerberos domain. I could use NFS for the PCs of the space but then i'd have to implement 802.1X

@dunkelstern

OK, but then the situation is somewhat simpler: each terminal has a fixed user. That could even be done by just having a wireguard network (with the list of peers managed manually) and IP-based NFS exports.

@robryk That's a problem too. If you only have one user account per terminal then you could leak logged in browser sessions to the next user, etc.

but the VPN could be a part of the solution, if only the terminals can connect to that and nfs only exports on the private network.

Will not fix the problem with maintaining two password stores if the private laptop of someone should be able to access their data. (That has to be SMB for windows).

@dunkelstern

I'm confused.

If a terminal is owned and permanently assigned to a signle user, there is no next and previous user. You can assume that all traffic coming from that machine (recognized by posession of a secret, e.g. of a wireguard private key) is on behalf of that user.

If you have a shared terminal, then:
- anyone using it would anyway trust it (if an attacker gets root on it, they can impersonate anyone who tries to log in on it later),
- you can treat it as a run of the mill multiuser Linux machine to get separation between users.

So, you can allow people to declare whether they want shared terminals to be able to mount their homedirs, and then trust the shared terminals to claim what user is logged in. You can recognize the shared terminals by possession of a secret, just like private ones (if someone gains root there, they can impersonate future users of that terminal anyway, so being able to exfiltrate the secret doesn't change things massively).

@robryk yes that was my path of thinking with one vpn secret per terminal. Then you can use NFS over the VPN as the encryption of that channel makes it unsniffable on the network. UIDs via LDAP or by rsyncing the passwd file in the worst case.

But I probably still need Samba for the machines of some users that prefer to use their own laptops. And as I am seemingly unable to create a samba directory server installation that contains samba and ldap in one package i cannot sync the passwords.

@dunkelstern

> But I probably still need Samba for the machines of some users that prefer to use their own laptops.

Why? You can give them VPN creds, give them a fixed IP in the VPN, and tell the nfs server to assume (via anonuid option in exports) that all traffic from that IP corresponds to their UID of the laptop's owner.