Kerberos Ldap Integration

[Rodrigo Castro]

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