So I have two test machines that I set up because of this same problem
on my secure offline network. One of the test machines is a server that
has FreeIPA and NFS running on it, the other test machine is a client
that mounts two NFS shares from the server using krb5i sec.
Upon initial install, everything works as it is supposed to. The domain
users can log in just fine, the mount mounts perfectly.
If I remove the client from the domain using:
ipa-client-automount --uninstall
ipa-client-install --uninstall
And then on the server:
ipa-client-automount --uninstall
ipa-server-install --uninstall
then delete the ca.crt, run sss -E (to clear the sssd caches), rm
/tmp/krb5*
and then reinstall the server:
ipa-server-install
service sshd restart
kinit admin
ipa service-add nfs/server.dar.lan
ipa-getkeytab -s server.dar.lan -p host/server.dar.lan -k
/etc/krb5.keytab
ipa-getkeytab -s server.dar.lan -p nfs/server.dar.lan -k
/etc/krb5.keytab
ipa-client-automount
and reinstall on the client:
ipa-client-install
ipa-client-automount
I believe I now have the same setup as I had before.
I can kinit and get a ticket:
Ticket cache: FILE:/tmp/krb5cc_61520_TinxaO
Default principal: ad...@dar.lan
Valid starting ExpiresService principal
02/03/17 12:54:02 02/04/17 12:53:59 krbtgt/dar@dar.lan
My domain users can log in to their desktops.
But I can't mount the shares.
I get:
mount.nfs4: timeout set for Fri Feb 3 12:58:36 2017
mount.nfs4: trying text-based options
'sec=krb5i,proto=tcp,port=2049,rsize=8192,wsize=8192,timeo=14,intr,addr=137.67.205.1,clientaddr=137.67.205.11'
mount.nfs4: mount(2): Permission denied
mount.nfs4: access denied by server while mounting
server:/NFS_SHARE/USERS
mount.nfs4: timeout set for Fri Feb 3 12:58:36 2017
mount.nfs4: trying text-based options
'sec=krb5i,proto=tcp,port=2049,rsize=8192,wsize=8192,timeo=14,intr,addr=137.67.205.1,clientaddr=137.67.205.11'
mount.nfs4: mount(2): Permission denied
mount.nfs4: access denied by server while mounting
server:/NFS_SHARE/admin
Originally I chased permissions, but when I started looking at
/var/log/messages on the server, I noticed that rpcgssd was complaining
about a wrong principal.
On the server I executed kadmin.local and then listprincs
K/m...@dar.lan
krbtgt/dar@dar.lan
kadmin/server.dar@dar.lan
kadmin/ad...@dar.lan
kadmin/chang...@dar.lan
ldap/server.dar@dar.lan
host/server.dar@dar.lan
HTTP/server.dar@dar.lan
nfs/server.dar@dar.lan
s_shar...@dar.lan
host/as1.dar@dar.lan
and then a getprinc on nfs/server.dar@dar.lan:
Principal: nfs/server.dar@dar.lan
Expiration date: [never]
Last password change: Thu Feb 02 15:31:24 EST 2017
Password expiration date: [none]
Maximum ticket life: 1 day 00:00:00
Maximum renewable life: 7 days 00:00:00
Last modified: Thu Feb 02 15:31:24 EST 2017
(nfs/server.dar@dar.lan)
Last successful authentication: Thu Feb 02 16:52:16 EST 2017
Last failed authentication: Fri Feb 03 12:09:14 EST 2017
Failed password attempts: 1
Number of keys: 4
Key: vno 3, aes256-cts-hmac-sha1-96, no salt
Key: vno 3, aes128-cts-hmac-sha1-96, no salt
Key: vno 3, des3-cbc-sha1, no salt
Key: vno 3, arcfour-hmac, no salt
MKey: vno 1
Attributes: REQUIRES_PRE_AUTH
Policy: [none]
looking at my keytab, klist -ke /etc/krb5.keytab
12 host/server.dar@dar.lan
21 nfs/server.dar@dar.lan
33 host/server.dar@dar.lan
43 host/server.dar@dar.lan
53 host/server.dar@dar.lan
63 host/server.dar@dar.lan
72 nfs/server.dar@dar.lan
82 nfs/server.dar@dar.lan
92 nfs/server.dar@dar.lan
102 nfs/server.dar@dar.lan
I saw I had two extra older kt's so I used kadmin.local to remove them
with modprinc. Not sure where they came from. . .
I again tried to mount, this time using -vvv in /etc/sysconfig/nfs for
rpcgssd, rpcsvcgssd, and rpcbind and /var/log/messages output this on
the server (I'll only paste the data from one mount attempt as there is
two mounts and they're complaining identically.):
Feb 3 12:25:32 server rpc.svcgssd[4796]: leaving poll
Feb 3 12:25:32 server rpc.svcgssd[4796]: handling null request
Feb 3 12:25:32 server rpc.svcgssd[4796]: svcgssd_limit_krb5_enctypes:
Calling gss_set_allowable_enctypes with 7 enctypes from the kernel
Feb 3 12:25:32 server rpc.svcgssd[4796]: WARNING:
gss_accept_sec_context failed
Feb 3 12:25:32 server rpc.svcgssd[4796]: ERROR: GSS-API: error in
handle_nullreq: gss_accept_sec_context(): GSS_S_FAILURE (Unspecified GSS
failure. Minor code may provide more information) - Wrong principal in
request
Feb 3 12:25:32 server rpc.svcgssd[4796]: sending null reply
Feb 3 12:25:32 server rpc.svcgssd
