On Thu, 6 Jun 2013, Ritter, Marcel wrote:
Newer versions of nfs-utils (>= 1.2.4) support the HOSTNAME$ format (treated like a UPN) used by Samba/Windows, which makes things easier (and could/should work out of the box with a keytab created by samba itself).
I have tried creating a Samba4 user object with a suitable UPN using msktutil on the DC (this is successfully entered into the database):
# OU=Computers # HOST=<short hostname> # msktutil -c -b CN=$OU \ -k nfs-$HOST.keytab \ --computer-name nfs-$HOST \ --upn nfs/$HOST.test.cornell.edu \ --service nfs/$HOST.test.cornell.edu \ --server `hostname` \ --dont-expire-password \ --hostname $HOST.test.cornell.edu \ --enctypes 0x3
and then importing this keytab into the host's keytab with ktutil (so, not using "net ads keytab add"). Verified the keytab with klist. Get permission denied when trying to mount with sec=krb5. Various different enctypes all get the same result.
I tried also building nfs-utils 1.2.8 from source and installing that on the NFSv4 server (using the NFSv4 server as a client for this test). All I get then, no matter what I put in the keytab, is:
rpc.gssd[1679]: ERROR: GSS-API: error in gss_set_allowable_enctypes(): GSS_S_BAD_MECH (An unsupported mechanism was requested) - Unknown error
The build of nfs-utils (via rpmbuild) appeared clean but I suspect that there may be something wrong with it. Still using the 2.6.32-358.6.2.el6 kernel.
I tried the workaround suggested in:
https://bugzilla.redhat.com/show_bug.cgi?id=720479
just in case, but it made no difference.
Running out of ideas!
-Steve
On Sat, 8 Jun 2013, Steve Thompson wrote:
Running out of ideas!
Well, I managed to solve this one. It turned out to be nothing to do with Samba4, nor the version of nfs-utils (1.2.3-36) or the version of the kernel (2.6.32-358.6.2.el6) on the NFS server and client. It was in the /etc/exports file; I was exporting /mnt/exports (the NFSv4 root with fsid=0) with sec=sys:krb5 and /mnt/exports/data (a file system), also with sec=sys:krb5, but also /mnt/data (the real file system, which is bind-mounted on to /mnt/exports/data), this time without specifying sec=. The latter was as a service to clients using NFSv3. It transpired that by adding sec=sys:krb5 to the latter export, the NFSv4+krb5 mounts all started working. I could argue that this is a bug, but whatever, it is now working.
Notes:
* allow_weak_crypto=yes is REQUIRED in krb5.conf for this software version combo.
* a separate user object is REQUIRED with the UPN nfs/fqdn. I add this using msktutil on the client when the client is joined to the domain. Using "net ads keytab add nfs" is NOT sufficient, since it adds an SPN and not a UPN.
Steve
Let's see if on my third attempt I can spell "NFS" properly :)
On Tue, 11 Jun 2013, Steve Thompson wrote:
- allow_weak_crypto=yes is REQUIRED in krb5.conf for this software version combo.
- a separate user object is REQUIRED with the UPN nfs/fqdn. I add this using msktutil on the client when the client is joined to the domain. Using "net ads keytab add nfs" is NOT sufficient, since it adds an SPN and not a UPN.
Aw crap, I hate it when I do that. It turns out that allow_weak_crypto=yes is NOT required at all, provided that the nfs/fqdn UPN that is created supports the necessary enctypes. I original had --enctypes=0x3 when I created the UPN with msktutil; by recreating the UPN without using --enctypes at all, allow_weak_crypto=yes is no longer needed on either client or server, and NFSv4 mounts work just fine with everything essentially stock. It is still true that a UPN must be created, and "net ads keytab add" is not sufficient. This is with a Samba4 domain, btw.
I still have an issue with user access to the NFSv4 mount, and a workaround for it, but that's for another time.
Steve
On Fri, 14 Jun 2013, Steve Thompson wrote:
I still have an issue with user access to the NFSv4 mount, and a workaround for it, but that's for another time.
And now is another time (but I am at the point on giving up on this for now, as it has become a large consumer of time).
To reiterate, I am trying to get Keberized NFSv4 to work with CentOS 6.4 clients in a Samba4 domain, using sssd and Samba 4.0.5 (no winbind). Now, CentOS 6.4 uses kernel 2.6.32-358.6.2.el6 and nfs-utils 1.2.3-36. First of all, the Samba4 KDC (a separate pair of systems) appears to be working, DNS (samba4+bind9+dlz) is working (forward and reverse), and NFSv4 is working just fine with sec=sys (ie no Kerberos), so I believe the basic infrastructure to be sound, including ID mapping. I am using the sec=sys case in production with Samba4, so I know that to be good (and, interestingly, it feels a lot snappier than NFSv3).
NFSv4 mounts with sec=krb5 work fine as long as I create a suitable UPN in the Samba database. On the client and server:
# kinit Administrator # FQDN=`hostname` # msktutil \ --base "CN=Computers" \ --keytab /etc/krb5.keytab \ --dont-expire-password \ --no-pac \ --computer-name nfs-$HOST \ --hostname $FQDN \ --service nfs/$FQDN \ --upn nfs/$FQDN \ --user-creds-only
and the nfs/... entries show up within the client and server's /etc/krb5.keytab and look correct:
# klist -ke Keytab name: FILE:/etc/krb5.keytab KVNO Principal -------------------------------------------------------------------------- 1 host/<fqdn>@<REALM> (des-cbc-crc) 1 host/<fqdn>@<REALM> (des-cbc-md5) 1 host/<fqdn>@<REALM> (arcfour-hmac) 1 host/<fqdn>@<REALM> (aes128-cts-hmac-sha1-96) 1 host/<fqdn>@<REALM> (aes256-cts-hmac-sha1-96) 1 host/<shortname>@<REALM> (des-cbc-crc) 1 host/<shortname>@<REALM> (des-cbc-md5) 1 host/<shortname>@<REALM> (arcfour-hmac) 1 host/<shortname>@<REALM> (aes128-cts-hmac-sha1-96) 1 host/<shortname>@<REALM> (aes256-cts-hmac-sha1-96) 1 <SHORTNAME>$@<REALM> (des-cbc-crc) 1 <SHORTNAME>$@<REALM> (des-cbc-md5) 1 <SHORTNAME>$@<REALM> (arcfour-hmac) 1 <SHORTNAME>$@<REALM> (aes128-cts-hmac-sha1-96) 1 <SHORTNAME>$@<REALM> (aes256-cts-hmac-sha1-96) 1 HOST/<fqdn>@<REALM> (des-cbc-crc) 1 HOST/<fqdn>@<REALM> (des-cbc-md5) 1 HOST/<fqdn>@<REALM> (arcfour-hmac) 1 HOST/<fqdn>@<REALM> (aes128-cts-hmac-sha1-96) 1 HOST/<fqdn>@<REALM> (aes256-cts-hmac-sha1-96) 2 nfs-<shortname>$@<REALM> (arcfour-hmac) 2 nfs-<shortname>$@<REALM> (aes128-cts-hmac-sha1-96) 2 nfs-<shortname>$@<REALM> (aes256-cts-hmac-sha1-96) 2 nfs/<fqdn>@<REALM> (arcfour-hmac) 2 nfs/<fqdn>@<REALM> (aes128-cts-hmac-sha1-96) 2 nfs/<fqdn>@<REALM> (aes256-cts-hmac-sha1-96)
Here /data is the exported bind mount that is underneath the fsid=0 exports entry:
# mount -t nfs4 -o sec=krb5 <server_fqdn>:/data /mnt # (works)
I can browse the mount point as root and all permissions and ownerships are correct, except of course that I cannot descend into directories for which root (aka nobody) does not have permissions, as expected.
Now as a user (me, with UID 1002), using the server as a client (but using a separate client makes no difference), I can't even browse:
$ kinit $ ls /mnt ls: cannot access /mnt: Permission denied
and that's as far as I can get. From /var/log/messages:
rpc.gssd[7564]: using FILE:/tmp/krb5cc_1002 as credentials cache for client with uid 1002 for server <server_fqdn> rpc.gssd[7564]: using environment variable to select krb5 ccache FILE:/tmp/krb5cc_1002 rpc.gssd[7564]: creating context using fsuid 1002 (save_uid 0) rpc.gssd[7564]: creating tcp client for server <server_fqdn> rpc.gssd[7564]: DEBUG: port already set to 2049 rpc.gssd[7564]: creating context with server nfs@<server_fqdn> rpc.gssd[7564]: WARNING: Failed to create krb5 context for user with uid 1002 for server <fqdn>
I have of course researched this at length, and found lots of instances of folks seeing the same "Failed to create krb5 context" message, but no-one with the same combination of OS and Samba4, and no resolutions.
I have also tried a Fedora 18 client and server (kernel 3.9.5-201.fc18, nfs-utils 1.2.7-6) with a different but equivalent pair of Samba4 domain controllers. Again, NFSv4 with sec=sys works fine, and with sec=krb5 it fails in *exactly* the same way as for CentOS.
Using "nfs ads keytab add nfs..." properly creates an SPN, and this is not sufficient, on both CentOS and Fedora.
Any ideas? Please stop me from drinking so much coffee. TIA!
-Steve
-
Steve Thompson