[Freeipa-users] problems with NFS service principal

[jcnt at use.startmail.com]

On Friday, November 6, 2015 3:24 AM, Alexander Bokovoy <abokovoy at redhat.com> wrote:
> On Thu, 05 Nov 2015, jcnt at use.startmail.com wrote:
>>On Thursday, November 5, 2015 1:54 PM, Rob Crittenden
>> <rcritten at redhat.com> wrote:
>>> jcnt at use.startmail.com wrote:
>>>> Hello everyone,
[...]
> 
> Your workflow should be something like this (using IPA CLI as an example
> here):
> 1. Create a service with 'ipa service-add'
> 2. Associate a key with a service with 'ipa-getkeytab' and store it in a
>    keytab -- either directly on the server where service is running or on
>    any other IPA client.
> 3. Deliver the keytab from step (2) to a server where it should be if
>    needed. In case of clustered configuration deliver the keytab to all
>    cluster nodes which will be operating as the service.
> 
>    Do not run 'ipa-getkeytab' multiple times as each run invalidates
>    previously obtained keytab.
> 
> 4. Use the keytab to kinit and obtain initial ticket granting ticket
>    (TGT) for the service principal periodically. This either has to be
>    supported by an application itself or run with a wrapper that kinits
>    periodically. On RHEL 7, CentOS 7, and Fedora use GSS-PROXY to
>    perform automatic renewal, this is much cleaner way of doing it.
> 
> If your NAS appliance has issues like below it only says that NFS server
> side did not accept your configuration. Thus, you need to look into the
> NAS appliance logs to say what is wrong there.

To eliminate NAS appliance I am following section 16.3.1
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/kerb-nfs.html#krb-nfs-server
literally on a fresh CentOS 7 lab network consisting of one IPA server, one IPA client and a stand alone NFS server.
For IPA server I created nfs service using
ipa service-add nfs/fds.example.org
followed by
ipa-getkeytab -s fds.example.org -p nfs/fds.example.org -k /tmp/nfsserverfds.keytab
then used ktutil to merge into host keytab.
klist -k confirms that host and nfs principals are present.
created /etc/exports like /home *(rw,insecure,sec=krb5) and enabled nfs-server service
(I also disabled NFSv3)
krb5 mount between IPA client and IPA server works without any problems.

# mount -vvv -o sec=krb5 fds:/home /mnt
mount.nfs: timeout set for Sun Nov  8 10:59:53 2015
mount.nfs: trying text-based options 'sec=krb5,vers=4,addr=192.168.1.3,clientaddr=192.168.1.131'

However, when I repeat exactly the same service-add and getkeytab steps for a stand alone NFS server, mount is denied.

kinit -k nfs/nfsserver.example.org
works (I added default realm in /etc/krb5.conf)

Starting gssproxy in debug mode like
/usr/sbin/gssproxy -di shows following during mount attempt:

Debug Enabled
Client connected (fd = 11) (pid = 2157) (uid = 0) (gid = 0) (context = system_u:system_r:kernel_t:s0)
gp_rpc_execute: executing 9 (GSSX_ACCEPT_SEC_CONTEXT) for service "nfs-server", euid: 0, socket: /run/gssproxy.sock
gp_rpc_execute: executing 9 (GSSX_ACCEPT_SEC_CONTEXT) for service "nfs-server", euid: 0, socket: /run/gssproxy.sock
gp_rpc_execute: executing 9 (GSSX_ACCEPT_SEC_CONTEXT) for service "nfs-server", euid: 0, socket: /run/gssproxy.sock
gp_rpc_execute: executing 9 (GSSX_ACCEPT_SEC_CONTEXT) for service "nfs-server", euid: 0, socket: /run/gssproxy.sock
gp_rpc_execute: executing 9 (GSSX_ACCEPT_SEC_CONTEXT) for service "nfs-server", euid: 0, socket: /run/gssproxy.sock
gp_rpc_execute: executing 9 (GSSX_ACCEPT_SEC_CONTEXT) for service "nfs-server", euid: 0, socket: /run/gssproxy.sock

/usr/sbin/rpc.gssd -vvv -f
shows only
beginning poll

Does anyone know how to enable more verbosity from NFS components to find out what is missing in stand alone server configuration?

Regards,
Josh.