linux server - centralized user management

Question

I'm setting up a couple of linux servers (with ssh,apache,gitolite), but I want centralized user management. So far I've set-up LDAP directory support, which works great. But here's the catch: I want certain user U to have different access to server A than to server B. Let's say I want user U to have access specifications like this: - server A: access to home folder only - server B: access to home folder and /mnt/ folder - server C: on this server the user U is root user

I also want to be able to quickly change the permissions: revert/grant user permissions, like granting user U to change everything in /mnt.

So main question is: what should I look into (kerberos, radius, ...?) that support different access regulations (permissions) on different servers.

Thanks

Answer 1

A simple but useful login restriction mechanism is available in most distros under /etc/security/access.conf to define access rules for 'user A is allowed to login to Hosts A, B and C but not D' type configurations. You can specify by group, by user, from hosts, from subnet, etc.

As others have mentioned, you can control the deployment of such changes with a tool like cfengine or puppet.

And also as others have mentioned, you can use 'sudo' (configured via /etc/sudoers) to control root-like access to specific binaries from accounts or groups in LDAP. It's quite flexible. man sudo / man sudoers

And one more time as others have mentioned, you can use POSIX ACLs if classic user/group/other rwx permissions are insufficient to control access to filesystem objects by group or by user.

Answer 2

If you're talking about filesystem permissions, then you can probably do what you want with a detailed ACL setup using POSIX acls, and layered groups, and having your group information delivered via LDAP.

If you permission levels are fairly static, then it's probably good enough to set up basic groups with logical permission blocks like "full access to /mnt", and then use LDAP to deal with adding/removing that group from a user's account.

If you want more dynamic control over permissions, then you'll have to look at how to change permissions or ACLs on the systems in question. One way of pushing out changes in ACL or filesystem permissions would be through a tool like Puppet or Chef, which let you manage configuration changes across machines. You could handle everything through one of these tools (eg, including account creation and group membership), or you could store account/group information in LDAP and just push out ACL changes.

In terms of "on this server the user U is root user", there's nothing that I can think of that will let you do this per se. The root user is the root user, and other users are not - end of story. You could change another user's uid to 0, but this is ugly, ugly, ugly. What you can do is use group membership to control who can use the sudo command to gain root privileges, and again use LDAP to deliver group membership to the servers in question.

Bear in mind that group membership changes take effect when you login, so some changes may be delayed, and also take into account any NSS caching of LDAP results done in your environment (eg, through nscd)

Answer 3

The first two items can be handled by ownership and groups with or without LDAP.

Changing access is should be easier if you use ACLs which can use userid and groups.

Having a user be root on on server will make them root on all servers. To be root the UID must be 0. Allowing any user to login as root is bad security practice. sudo which is the normal method for granting root access to users has full capabilities to restrict access by host and/or hostgroups. The usual host group is ALL. Changing the content of /etc/sudoers will not kill any running processes.

You may want to implement cfengine, puppet, or a similar tool to roll out your changes. This will ease planned access changes, and provide some documentation to what you have done. Changes can be done quickly if required, but I would be very concerned if frequent fast changes were required.

The groups a user has are set a login, so revoking groups will not modify the access of logged in users. Changes in file access will have immediate effect for new accesses. I haven't verified the impact on open files, but expect the original access will apply.

Look at the pam_check_ options in /etc/ldap.conf for some of the options that can be used with LDAP and pam.

Answer 4

what if you create group AdminServerC in LDAP and then add to /etc/sudoers on Server C below statement? :

%AdminServerC        ALL=(ALL) ALL