On Sat, Jan 13, 2007 at 04:32:28PM -0600, Christopher D. Clausen wrote: > 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] >
Erm, sure. I had some different film going on im my mind. You're right. We do use pam_krb5 for sudo and it works, there's just one problem though: docelic_admin# sudo su - docelic Access denied for this host su: Permission denied (Ignored) No directory, logging in with HOME=/ [EMAIL PROTECTED]:/$ So, as seen, first problem is that pam's check_host_attr = yes is getting in the way and not allowing login. (I need to see what hostname is being used that it fails). (The other problem is that PAM lets it through in spite of the error message, but this is a known pam_ldap bug and is fixed in newer versions). The other problem is that for the target user, the krb ticket is not issued and no afs tokens can be obtained. Maybe this will all fix itself after the problem nr. 1 is solved, as that will eliminate the negative value in the pam module stack. I need to see more about this. > ---- > > 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/ it would surely be better to do it the way you suggest, but from reading the given URL (from the previous email I was replying to) I got an impression that you wouldn't be able to connect if you didn't have a kerberos-enabled client in some way. Is this true, or you would just be assigned the default realm? > > 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. > It's great. I had a 3/3 miss rate with that email, so it's great that you cared to park a comment, this way we're back on the right track. > <<CDC > Enjoy, -doc > > _______________________________________________ > HCoop-SysAdmin mailing list > [email protected] > http://hcoop.net/cgi-bin/mailman/listinfo/hcoop-sysadmin _______________________________________________ HCoop-SysAdmin mailing list [email protected] http://hcoop.net/cgi-bin/mailman/listinfo/hcoop-sysadmin
