Matt Garman <[email protected]> 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 > "[email protected]", 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 ([email protected]) <http://www.eyrie.org/~eagle/> ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
