In which direction do you care for translation ?
GSS-Proxy does indeed uses only krb5.conf for authentication mapping purposes, but what you should below seem to be a id -> name translation, perhaps in order to set permissions ?
Are you having issues at authentication time ? With gss-proxy debug at level 3 you should see the full data exchanged as part of a GSS Accept_Sec_Context call, in the reply you should see what name was used.
Also keep in mind that normally NFS servers by default squash root to nobody, not sure if this is a factor. (In general using root over NFS is discouraged).
Simo.
On Tue, 2020-11-10 at 10:03 -0500, Jason Keltz wrote:
Hi.
I have a system configured to use krb5 NFS mounts on CentOS 7 along with gss-proxy. It's a bit of a different setup because the Kerberos server is part of Samba AD. Nonetheless, NFS mounts are working perfectly. The one thing I can't seem to figure out is NFS root. I've seen instructions online for adding translations to /etc/idmapd.conf, and I tried that, and it wasn't working. I then found instructions from Red Hat to do this type of setup in /etc/krb5.conf instead:
[realms] … EXAMPLE.COM = { … auth_to_local = RULE:[2:$1/$2@$0](host/nfsclient.example.com@EXAMPLE.COM)s/.*/root/ auth_to_local = DEFAULT }
This also doesn't seem to solve the problem. These lines, I'm assuming, go on the NFS server.
I even tried changing "host/nfsclient.example.com@EXAMPLE.COM" to .* for my test setup to see if anything would happen, but it didn't. It's not clear how I can verify whether those lines are being processed.
It wasn't even clear whether the "auth_to_local" lines were required in addition to the NFS translation lines, or separately.
I did my research and discovered what those lines mean. I also discovered those lines are required instead of the NFS translation lines when using gss-proxy.
The problem is, I can't really figure out how to debug this issue. With rpc.idmapd debugging I was seeing the following:
rpc.idmapd: nfsdcb: authbuf=gss/krb5 authtype=user rpc.idmapd: nfs4_uid_to_name: calling nsswitch->uid_to_name rpc.idmapd: nfs4_uid_to_name: nsswitch->uid_to_name returned 0 rpc.idmapd: nfs4_uid_to_name: final return value is 0 rpc.idmapd: Server : (user) id "0" -> name "root@eecs.yorku.ca" rpc.idmapd: nfsdcb: authbuf=gss/krb5 authtype=group rpc.idmapd: nfs4_gid_to_name: calling nsswitch->gid_to_name rpc.idmapd: nfs4_gid_to_name: nsswitch->gid_to_name returned 0 rpc.idmapd: nfs4_gid_to_name: final return value is 0 rpc.idmapd: Server : (group) id "0" -> name "root@eecs.yorku.ca" rpc.idmapd: nfsdcb: authbuf=gss/krb5 authtype=user rpc.idmapd: nfs4_uid_to_name: calling nsswitch->uid_to_name rpc.idmapd: nfs4_uid_to_name: nsswitch->uid_to_name returned 0 rpc.idmapd: nfs4_uid_to_name: final return value is 0 rpc.idmapd: Server : (user) id "65534" -> name "nfsnobody@eecs.yorku.ca" rpc.idmapd: nfsdcb: authbuf=gss/krb5 authtype=group rpc.idmapd: nfs4_gid_to_name: calling nsswitch->gid_to_name rpc.idmapd: nfs4_gid_to_name: nsswitch->gid_to_name returned 0 rpc.idmapd: nfs4_gid_to_name: final return value is 0 rpc.idmapd: Server : (group) id "65534" -> name "nfsnobody@eecs.yorku.ca"
(with no NFS translation lines in place)..
It makes sense that root@eecs.yorku.ca is not a valid Kerberos user. root is just a local user.
Might someone have a suggestion on how to debug the processing of the auth_to_local lines?
I've turned on gssproxy debugging level 2, but not really seeing anything.
Thanks,
Jason.
gss-proxy mailing list -- gss-proxy@lists.fedorahosted.org To unsubscribe send an email to gss-proxy-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/gss-proxy@lists.fedorahosted.or...