On Wednesday, March 21, 2007 01:25:26 PM +0200 Nikolai Tenev <[EMAIL PROTECTED]> wrote:
> On server one (server1) in krb5.conf I have a record: > > auth_to_local = { > RULE:[2:$2](support)s/^.*$/root/ > } > > On server two (server2) in krb5.conf I have a record: > > auth_to_local = { > RULE:[2:$2](support)s/^.*$/root/ > RULE:[2:$2](developer)s/^.*$/root/ > } Doing authorization this way is dangerous, because it effectively grants privileges based on the mere existance of a principal, and assumes that no principal will ever be created that should not have these privileges. A better approach is to distribute lists of authorized developers and support staff which can be used in constructing a .k5login file for root. > When client1 is logged in from his workstation1 as root on server2, the > ticket of client1 is forwarded If you don't trust the machine you're connecting to, including all the people who have privileged access to it, then don't do that. Whenever you type a password on a machine, or forward credentials, agent connections, or X11 connections, you are granting that machine, and whoever controls it, the power to act as you. Giving your credentials to an untrusted machine is inherently unsafe; there are no tricks to get around that fact. Most ssh clients can be configured to forward credentials, agent connections, and X11 connections only to specific hosts. Your support staff should forward these only to trusted machines; that is, only to machines where only trusted staff have privileged access. They should also only ever type passwords at such machines, and never at an untrusted machine where some other person has root access. In our facility we go a step further; privileged users are not allowed to type passwords on or forward credentials to any machine where an untrusted person has any access, privileged or not. -- Jeffrey T. Hutzelman (N3NHS) <[EMAIL PROTECTED]> Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos