Some questions about gssproxy.conf options · gssapi/gssproxy · Discussion #77

foonon
Jun 20, 2023

What's the difference between "impersonate" and "trusted"? Based on the man page, it seems that if enabled, "trusted" implies "impersonate"? Or am I reading that wrong?
What benefits does "allow_client_ccache_sync" provide? Why would I need to use it? If enabled, how do I know it's having an effect?
I've been using the default service/nfs-client configuration, and I'm finding that technical users with keytabs can also use gssproxy with the client programs for other Kerberized services (i.e., ldapsearch, ssh, curl). I'm not complaining about this, but I'm wondering if this should be configured more explicitly. If so, how?

Answered by simo5

"Impersonate" allows the use of Constrained Delegation (which needs to be also authorized by the KDC), while "trusted" allows users of the service to tell who to impersonate, which could be any other user.
Trusted needs to be used carefully, generally should be set only on services that restrict access to either root or a controlled service account.
After first ccache initialization (when TGT and first ticket is received) the cache is sent back encrypted to the client. Later on the client may request additional tickets, and does so by sending the received cache to the gss-proxy process that uses it to retrieve the new ticket and create a GSSAPI session. Given the original cache contao...

"Impersonate" allows the use of Constrained Delegation (which needs to be also authorized by the KDC), while "trusted" allows users of the service to tell who to impersonate, which could be any other user.
Trusted needs to be used carefully, generally should be set only on services that restrict access to either root or a controlled service account.
After first ccache initialization (when TGT and first ticket is received) the cache is sent back encrypted to the client. Later on the client may request additional tickets, and does so by sending the received cache to the gss-proxy process that uses it to retrieve the new ticket and create a GSSAPI session. Given the original cache contaons no ticket for the newtarget an new ticket needs to be requested to the KDC for each GSSAPI session establishment. For rare operations this is fine and perhaps even better. However if there are frequent session establishments from a client, it is better to update its cache so that there is no need to request fresh tickets every time. It is a tuning that depends on what the usage pattern is. Some configurations allow gss-proxy to use a file to store and fully manage ccaches, in which case this is not needed.
There is indeed no option to restrict acquiring tickets only for specific targets, if you have that need feel free to open a ticket with as much detail about the use case as possible (or you can also provide a patch if you feel you can implement this yourself).