gssproxy nfsclient and caching?

[jfossheim-skyfritt]

Hello all,

I am somewhat confused on exactly how caching works of client's host principals. If any?

I had this strange case, where I was supposed to mount up a share from another (non-trusted) kerberos realm. The Rocky (Red Hat Enterprise) laptop is enrolled in a FreeIPA-domain (REALM1.COM), and I use a NFS-server in the domain every day.

I tried to add the client's nfs/principal (in REALM2.COM) to /etc/krb5.keytab, but I could only get access denied when trying to mount the share in question. I tried to remove the nfs/principial (in REALM1.COM) from /etc/krb5.keytab but no sigar. Only when the nfs/principial (in REALM2.COM) was the only principial in the keytab-file, was I able to mount the share from the server. But when I returned to my original keytab file, containing a host/principial and a nfs/principial (in REALM1.COM) and the new nfs/principial (in REALM2.COM) and restarted all nfs-related service, everything continues to work as I expected in the first place. Both shares work, and I can access files according to my cacched kerberos-tickets.

Any inputs to help me grasp excactly how this works? And why it wouldn't in the first place?

Might be related to this issue?

#65

[simo5]

Once you have caches primed the keytab is not used anymore unless you need to re-acquire a TGT. So the problem is probably an inability to figure out what principal to use to obtain the necessary TGT. Multi-homed systems like this are tricky as many factors influence what is being used including existing data int he caches.

Without detailed knowledge of the setup it i hard to diagnose.

[jfossheim-skyfritt]

I am somewhat reluctant to experiment to much with the laptop, that now works smoothly, but I might want to setup similar setups in the future.

It seems that the trick was to only have the correct nfs/hostname@REALM-principial in the keytab, do a mount, and restore a keytab with all principals in place. But it doesn't completely make sense either. I guess there is something at work here, that I don't exactly understand. I have not tested on debian-setups without gssproxy, for instance. And I am not completely sure on how rpc.gssd and gssproxy work together on the client, either. And there should be a way to specify which principal to use via the mount-command, or per domain in gssproxy.conf or something similar.

Any tips for articles/documentation that explains how the different component work together, clearly?

[simo5]

Gssproxy can't know which domain you are trying to connect to, only gssd can provide the correct principal when it tries to source credentials.
In theory you could have different configurations and sockets from gssproxy if you used namespacing, but tat is only really useful for containers, not for mixed use like on a laptop.

[jfossheim-skyfritt]

So what you are saying is that gssd digs through the keytab file? and feeds whatever keytab it decides to be the relevant one to gssproxy?

I see that gssd both have a keytab file option and a REALM-option, maybe I can investegate those if/when I encounter the same phenomenon again?

[simo5]

No, what I am saying is that rpc.gssd needs to construct the correct principal to ask gssproxy to use, then gssproxy will find the right one in the keytab.
The REALM option may be the one to use.