Multi user/server access?

[Red Squirrel]

I sorted asked this in another thread but thought I'd start a thread on it. If I have multiple users and multiple servers, what is the easiest way to set it up so that I have unified access across all systems?

Ex: I have a file server, let's call it SAN, but it's basically just a Linux box sharing NFS shares and is configured so only the servers that need to access it can.

Now I have two servers, Server1 and Server2. Let's just say they are VM servers but it does not really matter. Both those servers have a LUN mounted off SAN via NFS. Now when you mount something normally the permissions of whoever is accessing it matter, and not the permissions of whoever mounted it. This is where things can get really confusing, as the local permissions on the SAN might be root, or some other user/group. Those are local users, so the user on the other two servers trying to access it will often be access denied, unless I go on server1 as root, and chown/chmod it appropriately. This then makes the permissions invalid on the SAN or any other machine, but they are valid on server1. Now how do I get both server1 and server2 to have proper access to these? I also want to read up on ACLs, would it fix this situation?

Similar situations are true when dealing with rsync and pretty much any other file tools.

Do I need to look into using LDAP for all my servers or is there perhaps an easier way to deal with multi user/server access situations? Just trying to clean stuff up, as my current setup is kinda ugly, and I will be introducing a SAN soon which may complicate things as my file system has lot of various permissions based on the folders/programs that need to access those folders so really not sure how it will play out once that file system is moved from local to NFS. I could use iSCSI but I rather use NFS as it's better designed for multi server accessing the same FS.

 

[Crusty]

For the most part all you should be concerned with is making sure your UID/GIDs are the same across all machines.

If you need to constantly be adding/removing users and changing passwords then an LDAP solution is obviously best because the toolset will give you alot of functionality.

However, if you really only need to sync things up once you can always just copy your /etc/passwd, /etc/shadow, and /etc/group files around to all the machines.

Another solution is to just specify the same GID/UID to the adduser command when you create the users on new installs.

 

[Red Squirrel]

Actually I was reading that but was not sure if it was really all there was to it. Guess that might be the best route for me then.

Just curious though, let's assume a corporate setting, what stops somebody from setting up a server/vm and making a user with matching UID/GID on a corporate server then accessing information? Of course NFS would need to be configured in a way where that VM can access it. Though in a corporate setting, would the NFS server be treated as a SAN where only the servers can physically access it? That's probably what I'll end up doing anyway, not that security is that much a concern being just me here, but I always like to try to use best practices anyway.

 

[Crusty]

Actually I was reading that but was not sure if it was really all there was to it. Guess that might be the best route for me then.

Just curious though, let's assume a corporate setting, what stops somebody from setting up a server/vm and making a user with matching UID/GID on a corporate server then accessing information? Of course NFS would need to be configured in a way where that VM can access it. Though in a corporate setting, would the NFS server be treated as a SAN where only the servers can physically access it? That's probably what I'll end up doing anyway, not that security is that much a concern being just me here, but I always like to try to use best practices anyway.

Security? If you're creating users, you've obviously got root access to the servers/network.

 

[Red Squirrel]

Security? If you're creating users, you've obviously got root access to the servers/network.

No, I mean what stops somebody from bringing their own system that they have root access to, create a user on that system, then wont they be able to mount and access data on systems they don't have root access to?

I guess in a proper setup environment that foreign system's IP would not be allowed to connect to that NFS share though... But let's just say they make it static to match a valid server's IP and that server happens to be down. Guess they'd still need to also know the name of the share, IP of the server and the GID/UID of a valid user. I know it would not work for root because root squash (IIRC) would most likely be enabled.

 

[Crusty]

No, I mean what stops somebody from bringing their own system that they have root access to, create a user on that system, then wont they be able to mount and access data on systems they don't have root access to?

I guess in a proper setup environment that foreign system's IP would not be allowed to connect to that NFS share though... But let's just say they make it static to match a valid server's IP and that server happens to be down. Guess they'd still need to also know the name of the share, IP of the server and the GID/UID of a valid user. I know it would not work for root because root squash (IIRC) would most likely be enabled.

Like I said, security. You've got all sorts of problems if you're allowing any random person to plug in foreign hardware into your network. It's all part of the game, if you want your data and systems to be secure you have to take care in every aspect of your network, and that includes physical access.

 

[theevilsharpie]

No, I mean what stops somebody from bringing their own system that they have root access to, create a user on that system, then wont they be able to mount and access data on systems they don't have root access to?

I guess in a proper setup environment that foreign system's IP would not be allowed to connect to that NFS share though... But let's just say they make it static to match a valid server's IP and that server happens to be down. Guess they'd still need to also know the name of the share, IP of the server and the GID/UID of a valid user. I know it would not work for root because root squash (IIRC) would most likely be enabled.

IP-based access control is very basic, and is not recommended on untrusted networks for the exactly the reason your describe.

For secure end-user access, you would use an LDAP database to store the user account credentials and access rights, and Kerberos to authenticate the user. IPSec encryption is available for environments that require even more protection of in-transit data.

 

[Red Squirrel]

Like I said, security. You've got all sorts of problems if you're allowing any random person to plug in foreign hardware into your network. It's all part of the game, if you want your data and systems to be secure you have to take care in every aspect of your network, and that includes physical access.

Yeah knew that, I was just curious if Linux had it's own layer of security to combat that as most corporate networks that I've seen don't really take extra measures to stop a foreign machine from entering the network other than having policies against it. Without something like port security throughout the entire network one could easily start accessing all sorts of data by bringing their own Linux laptop or what not. Not that it's an issue for me at home though, I will stick with the basic model of making the user's match up and leave it at that. Might mess with LDAP/kerberos and other advanced stuff in a lab environment though.

 

[mv2devnull]

Some call NFS "Not For Security". The problem is same for all OS. NFSv4 did add support for non-trivial authentication methods, such as Kerberos. If your server requires that, then the clients cannot fake to be what they don't have Kerberos keys for.