This is a discussion on Re: Kerberos Ldap Integration - Kerberos ; >>>>> "Rodrigo" == Rodrigo Castro writes: Rodrigo> I guess I haven't made myself clear. In my work Rodrigo> environment we have many labs. Some of them have root Rodrigo> priveleges to administrate their own lab. So with their Rodrigo> root ...
>>>>> "Rodrigo" == Rodrigo Castro
Rodrigo> I guess I haven't made myself clear. In my work
Rodrigo> environment we have many labs. Some of them have root
Rodrigo> priveleges to administrate their own lab. So with their
Rodrigo> root account they can become any ldapuser. This is
Rodrigo> undesirable. Is there any kerberos/ldap configuration to
Rodrigo> disable this?
This can't be avoided. If they are root on the machine, they have
full access _to that machine_, including any home directories etc
for users only in LDAP.
HOWEVER, there is (at least) one way around this. Use AFS as
storage for user home directories etc... Then set appropriate
access control for the directories.
You could also use NFS (with the "squash_root" or whatever the
option in the exports was - it's been more than eight years since
I touched NFS last .
That way, it doesn't matter if the are root, they won't have access
to the directories any way. In the first case, they must have a
valid Kerberos V ticket to get a token for the AFS share.
In the other case (NFS), the root access is 'squashed' and they have
'anonymous' access on the share in question. That require that the
access mode on the directories are smart enough to stop this.
There might be other network file system which will give you the
same solution, but other than that there's no way to stop a local
root to have full access on the local machine!
Rodrigo> On Tue, Jun 10, 2008 at 10:28 AM, Daniel Savard
>> You cannot prevent root to su to any other local user. This is
>> why root is called a superuser. This has nothing to do with
>> Kerberos or LDAP, this is an OS issue.
Another, more cumbersome solution would be to stop root access completely,
and instead use sudo. Sudo can be setup so that there are 'command groups'
(groups of accepted commands) and those groups can be applied to users.
I don't have that config any more, but I used it a couple of years ago.
The sudoers(5) man page have extensive examples on how to set this up.
And this can be 'ldapified' (i.e. with external patch - included with
Debian GNU/Linux if I'm not mistaken), the sudoers file can be 'put'
in the LDAP database...
It's just a matter of what you mean by 'administrate there own labs'.
Being a little clever, you can write sudo rules instead of giving them
full root access.