On 02/23/2016 10:14 PM, James Denton wrote:
Hello again,
I've made more progress on the issue.
In FreeIPA, setting the NFS client host to be managed by the FreeIPA server itself is
allowing gssproxy to work.
E.g. On the FreeIPA server (
freeipaserver.example.com):
kinit admin
ipa host-add-managedby
nfs-client.example.com --hosts=freeipa-server-example.com
I didn't run into this issue in the past because the above step was required in order
to get the keytab on the FreeIPA server (to be transferred to the client with scp). With
my current setup, I am running ipa-getkeytab on the FreeIPA clients directly so delegation
is not required at that stage. It is apparently required for gssproxy, however.
So now the only issue remaining is that if gssproxy is running when NFS share is mounted,
the logs are getting this repeatedly:
gssproxy[642]: (OID: { 1 2 840 113554 1 2 2 }) Unspecified GSS failure. Minor code may
provide more information, No credentials cache found
Additionally, clients are not able to access their shares using the cached credentials.
This behaviour does not occur before the client is joined to the FreeIPA domain.
But when the gssproxy is restarted at this stage using "systemctl restart
gssproxy", everything works perfectly.
I would appreciate any of your thoughts on the issue.
Do I get it right that the scenario is:
a) A client that is not enrolled
b) You add a host on the server
c) Use ipa-getkeytab on the client
You observe failures unless you restart gssproxy.
I think gssproxy needs to be restarted to read the keytab after you
configured it and provisioned the keytab. To the best of my knowledge
gssproxy reads keytab only at the beginning.
Thanks so much,
James
_______________________________________________
gss-proxy mailing list
gss-proxy(a)lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/gss-proxy@lists.fedorahosted.org
--
Thank you,
Dmitri Pal
Engineering Director, Identity Management and Platform Security
Red Hat, Inc.