kerberos & cron - specifically nfsv4 w/sec=krb5p

[Russ Allbery]

Matt Garman <matthew.garman at gmail.com> writes:

> First question: say I have a user named "matt" on my systems.  Login
> authentication is controlled via Kerberos as well, so I have a principal
> "matt at MYDOMAIN.COM", secured with a password.  It seems that if I export
> the key to a file (in kadmin: "ktadd -k matt.keytab matt"), then the
> password no longer works.  Is this correct, that a password and keytab
> file are mutually exclusive?  That appears to be the case...

Normally when you create a keytab for a user, that process randomizes the
key, so it invalidates any old keys.  From the syntax you're using, you're
apparently using MIT Kerberos; with MIT Kerberos, you can run kadmin.local
on the KDC directly and then use ktadd with the -norandkey flag to extract
keys without changing them for a user.  However, using a separate
principal is generally better.

> Based on my assumption that I can't have both a password and valid key
> file, I tried to create a special principal, per the FAQ:

> kadmin: addprinc -randkey matt/cron
> kadmin: ktadd -k matt_cron.keytab matt/cron

> So now, in the crontab for user "matt", I prefix all commands with
> "kinit -k -t matt_cron.keytab matt/cron".  But jobs still fail with
> "permission denied" for the nfsv4 share.  After invoking the kinit
> command, I do have a valid TGT, verified with klist.

> So... what am I missing?

Either NFS doesn't understand matt/cron as a user, or the local daemon
that handles user credentials can't find the tickets.  I believe you do
have to be careful about how you name the ticket cache for NFS to pick it
up.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>