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(a)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(a)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(a)AD.EECS.YORKU.CA: aes256-cts/D0C0
[31897] 1605136730.732641: AP-REQ ticket: J1$(a)AD.EECS.YORKU.CA ->
host/j2.ad.eecs.yorku.ca(a)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(a)AD.EECS.YORKU.CA: aes256-cts/D0C0
[31897] 1605136730.732665: AP-REQ ticket: J1$(a)AD.EECS.YORKU.CA ->
host/j2.ad.eecs.yorku.ca(a)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(a)AD.EECS.YORKU.CA: aes256-cts/D0C0
[31897] 1605136635.104659: AP-REQ ticket: jas(a)AD.EECS.YORKU.CA ->
host/j2.ad.eecs.yorku.ca(a)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.