Kerberos Ldap Integration
Rodrigo Castro
rdccosmo at gmail.com
Wed Jun 11 09:31:17 EDT 2008
Thanks a lot turbo and all. I'll study the best approach to apply here in
the Uni.
On Wed, Jun 11, 2008 at 6:28 AM, Turbo Fredriksson <turbo at bayour.com> wrote:
> >>>>> "Rodrigo" == Rodrigo Castro <rdccosmo at gmail.com> 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 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
> Rodrigo> <daniel.savard at gmail.com>
> Rodrigo> wrote:
>
> >> 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.
>
--
__________________________________
Rodrigo de Castro Cosme
Ciência da Computação - Universidade Federal do Espírito Santo
Suporte mailing list - suporte at inf.ufes.br
MSN - rdccosmo at gmail.com
More information about the Kerberos
mailing list