On Tue, Sep 9, 2014 at 5:22 PM, Cedric Blancher <cedric.blanc...@gmail.com> wrote: > I think part of the problem is that you are using Linux (SLES, RHEL or > Centos doesn't matter), and the Linux NFS client implementation does > not support negotiation for the authentication in violation of RFC > 3530. > > So if you want to use Kerberos5 with NFS on SLES or RHEL/Centos you a) > must have proper tickets in your cache and use kswitch before calling > mount and b) you must always specify auth=krb5p or krb5i if you want > Kerberos authentication.
I think there are two (at least?) "authentications" taking place, and you might be addressing the wrong one. It's also possible that I'm hopelessly lost, but bear with me. :) I would call "authentication 1" the *machine's* authentication that allows the mount to take place. All the client servers do the mount at boot-time. I have created machine principles in my kerberos database. Each machine has its specific key exported to /etc/krb5.keytab so that it can do a krb5p mount. Though Linux may not support authentication negotiation, I don't believe I care, as I have the exported shares set up for krb5p only. Likewise, on each client machine's /etc/fstab file, I explicitly pass the sec=krb5p option to mount.nfs4. So I *think* I have the mounting setup correct. What I call "authentication 2" is the actual user- and file-level permissions, i.e. who can see what file. The share is mounted regardless. But at this point, under what circumstances is root allowed to see various users' files? How is it that root can "authenticate" as user XYZ without knowing XYZ's password, under the case I outlined in the original email? Thanks! Matt ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
