On 11/11/2020 5:57 PM, Jason Keltz wrote:
On 11/11/2020 4:34 PM, Simo Sorce wrote:
On Wed, 2020-11-11 at 16:24 -0500, Jason Keltz wrote:
Hi Simo,
I've continued to experiment.
I noticed that in /etc/krb5.conf, if I define:
AD.EECS.YORKU.CA = { auth_to_local = RULE:[1:$1@$0](.*)s/.*/root/ auth_to_local = DEFAULT }
... then any file I write actually gets mapped to root on the NFS client. On the other hand if I use:
auth_to_local = RULE:[2:$1/$2@$0](.*)s/.*/root/
.. then it does not work.
I just want to see what gssproxy is seeing - user@REALM, or host/user@REALM because I can't make it work. However, even with log level up high, gssproxy doesn't seem to divulge that information to me. How would I find it?
How did you set the debug level ?
At level 1 you should already get logging of responses which include the service name used.
However that will happen only at session establishment (At mount, or the first time a new user walks into the mount point).
After session establishment gssproxy is not involved anymore.
HTH, Simo.
j1 will be mounting j2.
On j2, I set gssproxy debug level to 1 via /etc/gssproxy/gssproxy.conf. I commented the auth_to_local lines I added to krb5.conf. I restarted gssproxy, and nfs-server.
On j1, I mount j2 as root.
All I see on the server is:
Nov 11 17:52:25 j2 gssproxy[30115]: [CID 12][2020/11/11 22:52:25]: gp_rpc_execute: executing 9 (GSSX_ACCEPT_SEC_CONTEXT) for service "nfs-server", euid: 0,socket: /run/gssproxy.sock Nov 11 17:52:26 j2 gssproxy[30115]: [CID 12][2020/11/11 22:52:26]: gp_rpc_execute: executing 9 (GSSX_ACCEPT_SEC_CONTEXT) for service "nfs-server", euid: 0,socket: /run/gssproxy.sock
Now on j1 I cd into /mnt. There is nothing new on j2 log.
In j1 log:
Nov 11 17:52:25 j1 gssproxy[24710]: [CID 13][2020/11/11 22:52:25]: gp_rpc_execute: executing 6 (GSSX_ACQUIRE_CRED) for service "nfs-client", euid: 0,socket: (null) Nov 11 17:52:25 j1 gssproxy[24710]: gssproxy[24711]: (OID: { 1 2 840 113554 1 2 2 }) Unspecified GSS failure. Minor code may provide more information, Client 'host/j1.ad.eecs.yorku.ca@AD.EECS.YORKU.CA' not found in Kerberos database Nov 11 17:52:26 j1 gssproxy[24710]: [CID 13][2020/11/11 22:52:26]: gp_rpc_execute: executing 6 (GSSX_ACQUIRE_CRED) for service "nfs-client", euid: 0,socket: (null) Nov 11 17:52:26 j1 gssproxy[24710]: gssproxy[24711]: (OID: { 1 2 840 113554 1 2 2 }) Unspecified GSS failure. Minor code may provide more information, Client 'host/j1.ad.eecs.yorku.ca@AD.EECS.YORKU.CA' not found in Kerberos database
How do I know what the Kerberos server is seeing when root enters /mnt?
I set KRB5_TRACE in the gssproxy systemd file, and was able to see that when I mount, this is logged:
31897] 1605136730.732640: Decrypted AP-REQ with server principal host/j2.ad.eecs.yorku.ca@AD.EECS.YORKU.CA: aes256-cts/D0C0 [31897] 1605136730.732641: AP-REQ ticket: J1$@AD.EECS.YORKU.CA -> host/j2.ad.eecs.yorku.ca@AD.EECS.YORKU.CA, session key aes256-cts/7182 [31897] 1605136730.732642: Negotiated enctype based on authenticator: aes256-cts [31897] 1605136730.732643: Authenticator contains subkey: aes256-cts/75C8 [31897] 1605136730.732645: Creating AP-REP, time 1605136725.715634, subkey aes256-cts/5373, seqnum 215357562 [31897] 1605136730.732661: Destroying ccache MEMORY:internal_31902 [31897] 1605136730.732664: Decrypted AP-REQ with server principal host/j2.ad.eecs.yorku.ca@AD.EECS.YORKU.CA: aes256-cts/D0C0 [31897] 1605136730.732665: AP-REQ ticket: J1$@AD.EECS.YORKU.CA -> host/j2.ad.eecs.yorku.ca@AD.EECS.YORKU.CA, session key aes256-cts/7182 [31897] 1605136730.732666: Negotiated enctype based on authenticator: aes256-cts [31897] 1605136730.732667: Authenticator contains subkey: aes256-cts/F956 [31897] 1605136730.732669: Creating AP-REP, time 1605136725.715654, subkey aes256-cts/9848, seqnum 677303300 [31897] 1605136730.732685: Destroying ccache MEMORY:internal_31902
When I change into the directory, as me, I see this:
[31897] 1605136635.104658: Decrypted AP-REQ with server principal host/j2.ad.eecs.yorku.ca@AD.EECS.YORKU.CA: aes256-cts/D0C0 [31897] 1605136635.104659: AP-REQ ticket: jas@AD.EECS.YORKU.CA -> host/j2.ad.eecs.yorku.ca@AD.EECS.YORKU.CA, session key aes256-cts/5FF0 [31897] 1605136635.104660: Negotiated enctype based on authenticator: aes256-cts [31897] 1605136635.104661: Authenticator contains subkey: aes256-cts/F714 [31897] 1605136635.104663: Creating AP-REP, time 1605136635.34123, subkey aes256-cts/43E0, seqnum 389443622 [31897] 1605136635.104679: Destroying ccache MEMORY:internal_31902
But when I change into the directory as "root", nothing is logged into KRB5_TRACE.
I enable the auth_to_local rule: auth_to_local = RULE:[1:$1@$0](J1$.*)s/.*/root/ again, and it doesn't work but then I realized that the $ in J1 could be escaped, and the rule now becomes:
BUT... auth_to_local = RULE:[1:$1@$0](J1$@AD.EECS.YORKU.CA)s/.*/root/
... which finally works!!!
Persistence does pay off I guess. I'd still like your help understanding those other GSS errors, but I'll get back to that tomorrow as a separate issue.
Jason.