Re: Using ksu/sudo with Kerberos

2010-10-09 Thread Brian Candler
On Fri, Oct 08, 2010 at 06:16:31AM -0700, rommu...@googlemail.com wrote: On Oct 5, 10:03 am, Brian Candler b.cand...@pobox.com wrote: sudo's testing for group membership seems a lot more attractive in that regard. Can it test this using LDAP, too? Sure: using nss_ldap then you ldap uid,

Re: Using ksu/sudo with Kerberos

2010-10-08 Thread rommu...@googlemail.com
On Oct 5, 10:03 am, Brian Candler b.cand...@pobox.com wrote: sudo's testing for group membership seems a lot more attractive in that regard. Can it test this using LDAP, too? -- Julian Kerberos mailing list Kerberos@mit.edu

Re: Using ksu/sudo with Kerberos

2010-10-05 Thread Brian Candler
On Mon, Oct 04, 2010 at 03:47:00PM -0500, Christopher D. Clausen wrote: Note that depending upon your SSH setup, adding user principals to root's .k5login (or auth_to_local rules) might allow one to login directly as root on the system via SSH. ISTM that leaves a bit of an administrative

Re: Using ksu/sudo with Kerberos

2010-10-05 Thread Guillaume Rousse
Le 04/10/2010 23:56, Russ Allbery a écrit : Ken Dreyer ktdre...@ktdreyer.com writes: On Mon, Oct 4, 2010 at 3:38 PM, Russ Allbery r...@stanford.edu wrote: Yup. You may want to also disable public key authentication. We're enabling kerberos for several services at my organization, and we

Re: Using ksu/sudo with Kerberos

2010-10-05 Thread Russ Allbery
Guillaume Rousse guillaume.rou...@inria.fr writes: Le 04/10/2010 23:56, Russ Allbery a écrit : There unfortunately isn't any way that I know of to allow GSSAPI and public key authentication via ssh for regular users but require GSSAPI alone for root authentication, so we usually just turn

Using ksu/sudo with Kerberos

2010-10-04 Thread Brian Candler
I am wondering, what are people using instead of sudo in an Kerberized environment? So far I can see the following options: (1) create separate principals for each user who should have root access, e.g. candl...@foo.example.com candlerb/ad...@foo.example.com Then map */admin to the

Re: Using ksu/sudo with Kerberos

2010-10-04 Thread Russ Allbery
Brian Candler b.cand...@pobox.com writes: (1) create separate principals for each user who should have root access, e.g. candl...@foo.example.com candlerb/ad...@foo.example.com Then map */admin to the root account using auth_to_local, and people can use ksu to switch. We do

Re: Using ksu/sudo with Kerberos

2010-10-04 Thread Christopher D. Clausen
Russ Allbery r...@stanford.edu wrote: Brian Candler b.cand...@pobox.com writes: (1) create separate principals for each user who should have root access, e.g. candl...@foo.example.com candlerb/ad...@foo.example.com Then map */admin to the root account using auth_to_local, and

Re: Using ksu/sudo with Kerberos

2010-10-04 Thread Russ Allbery
Christopher D. Clausen cclau...@acm.org writes: Russ Allbery r...@stanford.edu wrote: We do this, except we use .k5login with a specific list of principals that should have access to root. I wouldn't use auth_to_local for... Note that depending upon your SSH setup, adding user principals to

Re: Using ksu/sudo with Kerberos

2010-10-04 Thread Ken Dreyer
On Mon, Oct 4, 2010 at 3:38 PM, Russ Allbery r...@stanford.edu wrote: Yup. You may want to also disable public key authentication. We're enabling kerberos for several services at my organization, and we were just having this same discussion. Can you elaborate on why you would disable pubkey?

Re: Using ksu/sudo with Kerberos

2010-10-04 Thread Russ Allbery
Ken Dreyer ktdre...@ktdreyer.com writes: On Mon, Oct 4, 2010 at 3:38 PM, Russ Allbery r...@stanford.edu wrote: Yup. You may want to also disable public key authentication. We're enabling kerberos for several services at my organization, and we were just having this same discussion. Can you

Re: Using ksu/sudo with Kerberos

2010-10-04 Thread Abe Singer
FWIW, In my previous job, we modified sudo (relatively simple patch, I'll have to dig it up) to use kerberos authentication with a principal of the format user/sudo@REALM. (sudo supports kerberos auth, but using the user's login principal, which AFAIC is a horrible mistake security-wise). I'm