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(a)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(a)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(a)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(a)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(a)eecs.yorku.ca"
(with no NFS translation lines in place)..
It makes sense that root(a)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(a)lists.fedorahosted.org
To unsubscribe send an email to gss-proxy-leave(a)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...
--
Simo Sorce
RHEL Crypto Team
Red Hat, Inc