Hello,
When I've setup new filers in our environment, I always enable Kerberos when I do an 'nfs setup' (as well as joining a Windows domain w/'cifs setup'). As a result of doing this, I noticed that /etc/krb5.keytab is created as part of the setup process. This allows us to enable sec=krb5 at our leisure and when we configure nfs.v4 options on the filer and stop/start 'nfs', "things just work". Cool.
However, when an existing filer has already been setup, that is, the filer already had a 'cifs setup' and has NOT had Kerberos enabled for NFS, I've noticed that /etc/krb5.keytab is not changed when I enable Kerberos during an 'nfs setup'. No matter whether or not I stop/start 'nfs' after I'm done with 'nfs setup', I'm unable to use NFSv4 on the filer until I re-run the entire cifs AND nfs setup (a closer view of the messages file suggests that the filer can't find a service principal for 'nfs' in its keytab). It appears then that enabling NFSv4 on the filer is not an online event as I'd expect and that I have to terminate all of my cifs sessions so that I can run through the cifs setup again. Uggh.
Can someone confirm if they've seen this behavior before? Or am I just missing something? Outside of running 'ktpass' on the Windows KDC and securely copying krb5.keytab from it to the filer, is there another way I can generate a new krb5.keytab or update the existing krb5.keytab on the filer? Or is there a utility I can use to see what lives in the krb5.keytab on the filer? 'klist -k -e ...' doesn't seem to like the format of it.
-- Nate