Re: [Samba] Samba4 and NFSv4

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



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
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos




[Index of Archives]     [CentOS]     [CentOS Announce]     [CentOS Development]     [CentOS ARM Devel]     [CentOS Docs]     [CentOS Virtualization]     [Carrier Grade Linux]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Linux USB]
  Powered by Linux