Davor Ocelic <[EMAIL PROTECTED]> wrote: > On Thu, Jan 11, 2007 at 06:23:45PM -0500, Michael Olson wrote: >> I'm waiting on the outcome of Justin's suggestion to use /etc/keytab >> (and the follow-up that I just sent to that) before creating the keys >> for various daemons. This won't block normal daemon >> installation/configuration. > > Let's go this route. Create /etc/keytabs/ and put all > keytabs we'll use there. Each user or service in its own file. > > So for each user we will do, within kadmin: > > ktadd -k /etc/keytabs/NAME.keytab NAME > > The file will already have mode 600, we will just have > to chown it appropriately. > > Christopher's advice to only export the DES key (by default > there are two key types) is good; look up a few emails > back on instructions how to do it.
Actually, my advice was to use RC4-HMAC and DES3-HMAC-SHA1 and to NOT use DES except were required (should only be used for AFS service principal and for older Solaris and Mac OS machines.) > We'll have to do this only for a few daemons and system accounts > now, in the beginning. > > We will also need to do this for a lot of users on the system, > actually for anyone that we will want to su/sudo to (to say, > resolve support tickets). But > for those accounts I suggest the existing /etc/krb5.keytab > because it's the default location, so we won't have to specify > the keytab file every time, and only the root user will use > it so permissions won't be a problem. Wait, what? Why do users need keytabs? You probably do want to use pam_krb5 for sudo, if needed. If users need to fix daemons, they should already have read access to keytabs for their own daemons and they should be able to kinit -kt /path/to/keytab [EMAIL PROTECTED] ---- As to using some Apache auth module, you want to use the Debian libapache2-mod-authkerb package. You do NOT want a PAM based solution. I'd like to be able to forward Kerberos tickets from my workstation to the webserver to login without needing to type an additional password. This increases security b/c even root on the remote can't my Kerberos password through this method. Additionally, there is an apache module that uses AFS PTS groups for authorization: http://chu.in-chemnitz.de/download/ Of course, you are all free to ignore me, but I really think Kerberos credential forwarding is the way to go. And since users can directly control AFS groups (if needed) I think it would be more useful to use PTS directory for authorization through the webserver instead of LDAP. <<CDC _______________________________________________ HCoop-SysAdmin mailing list [email protected] http://hcoop.net/cgi-bin/mailman/listinfo/hcoop-sysadmin
