The purpose of Encrypted/Credentials/v1@X-GSSPROXY:

[yghorbal]

Hi,

I've successfully setup GSS-Proxy with NFS client and Constraint Delegation against Active Directory. I think I've understood how things are working but I still miss a couple of bits!
For reference, the config is

[service/nfs-client]
 mechs = krb5
 cred_store = keytab:/etc/krb5.keytab
 cred_store = ccache:FILE:/var/lib/gssproxy/clients/krb5cc_%U
 cred_usage = initiate
 allow_any_uid = yes
 impersonate = true
 euid = 0

• The first one is this rather mysterious/surprising Encrypted/Credentials/v1@X-GSSPROXY: ticket(s) that gets added to the users' default kerberos cache:

$ klist
Ticket cache: KCM:1850627282:33793
Default principal: [email protected]

Valid starting       Expires              Service principal
01/01/1970 01:00:00  01/01/1970 01:00:00  Encrypted/Credentials/v1@X-GSSPROXY:
01/01/1970 01:00:00  01/01/1970 01:00:00  Encrypted/Credentials/v1@X-GSSPROXY:

=> What are those for and how do they fit in the grand schema of things?

• The second one is the location of the actual Service Ticket (the one for nfs/[email protected]) got on behalf of the user. From KRB5_TRACE logs, I can see many MEMORY: references:

[754] 1713649111.465532: Resolving unique ccache of type MEMORY
[754] 1713649111.465533: Initializing MEMORY:PjKD2SW with default princ [email protected]
[754] 1713649111.465534: Storing [email protected] -> [email protected] in MEMORY:PjKD2SW
[754] 1713649111.465535: Storing [email protected] -> krb5_ccache_conf_data/proxy_impersonator@X-CACHECONF: in MEMORY:PjKD2SW
[754] 1713649111.465536: Storing [email protected] -> krb5_ccache_conf_data/refresh_time@X-CACHECONF: in MEMORY:PjKD2SW
[754] 1713649111.465537: Storing [email protected] -> krb5_ccache_conf_data/pa_type/krbtgt\/SOMEDOMAIN.COM\@SOMEDOMAIN.COM@X-CACHECONF: in MEMORY:PjKD2SW
[754] 1713649111.465538: Storing [email protected] -> krbtgt/[email protected] in MEMORY:PjKD2SW
[...]
[3831] 1713542008.050652: Get cred via TGT krbtgt/[email protected] after requesting nfs/[email protected] (canonicalize on)

I guess that GSS-Proxy is somehow storing some bits in a memory cache. /var/lib/gssproxy/clients/krb5cc_xxxx files get populated thow, but they only host TGT.
=> Is there any reasons why using MEMORY cache? (maybe it's mandatory in impersonation scenario?)

• Last but not least, for Constraint Delegation to actually work against Active Directory env, the first ticket requested for the host for itself on behalf of the user (the s4u2self part) needs to be forwardable in order to be accepted by AD and trigger the s4u2proxy part. Unfortunately, the default configuration of [libdefaults] section of /etc/krb5.conf after domain join through realmd does not have the forwardable set to true.

=> Is there any way for GSS-Proxy to enforce forwardability in the impersonation scenario? (regardless of /etc/krb5.conf setting)

[simo5]

* The first one is this rather mysterious/surprising `Encrypted/Credentials/v1@X-GSSPROXY:` ticket(s) that gets added to the users' default kerberos cache:

[..]
=> What are those for and how do they fit in the grand schema of things?

GSS-Proxy is used for privilege separation, however we do not want to litter the filesystem with expired ccaches and we want to leave the user in control of cacches, to that a kdestroy will allways work.
Therefore we encrypt the actual ticket in the system keytab (or a random key if a ketab is not available) and we place it back into the user's ccache as a special entry.
This way the user can manage the credential, but can't use it directly.

I guess that GSS-Proxy is somehow storing some bits in a memory cache. /var/lib/gssproxy/clients/krb5cc_xxxx files get populated thow, but they only host TGT. => Is there any reasons why using MEMORY cache? (maybe it's mandatory in impersonation scenario?)

I think this is an internal MIT GSSAPI implementation detail. It needs to keep around some ticket/config entry while requesting info from the KDC, but those should not be stored in a regular ccache.

* Last but not least, for Constraint Delegation to actually work against Active Directory env, the first ticket requested for the host for itself on behalf of the user (the s4u2self part) needs to be forwardable in order to be accepted by AD and trigger the s4u2proxy part. Unfortunately, the default configuration of `[libdefaults]` section of `/etc/krb5.conf` after domain join through `realmd` does not have the `forwardable` set to true.

=> Is there any way for GSS-Proxy to enforce forwardability in the impersonation scenario? (regardless of /etc/krb5.conf setting)

Not to my knowledge, but if you do not want to allow forwardable tickets for all users you can easily create a custom krb5.conf file only for gss-proxy and change the unit file to pass that configuration as the KRB5_CONFIG environment variable.

[yghorbal]

@simo5 thank for for taking the time to go over all the questions! It's clear for me now how it works.
Maybe one last question regarding the Encrypted/Credentials/v1@X-GSSPROXY cache entries, is there any known way to identify and thus purge old/irrelevant ones? Those ends up piling up!
Thank you!

[simo5]

What ccache type do you use?
I think they can only pile up with the FILE type as that type does not know how to remove old entries (it just marks them deleted), but with modern caches (KEYRING, KCM) that shouldn't happen.
In any case, for old caches they are just stored in order because the FILE ccache is basically treated as append only. The only way to remove them is to kdestroy and let the system recreate them as needed.

[yghorbal]

I'm using KCM (the one provided by SSSD) and what I'm seeing is that even in that case they do pile up.

$ klist
Ticket cache: KCM:1850627282:70691
Default principal: [email protected]

Valid starting       Expires              Service principal
01/01/1970 01:00:00  01/01/1970 01:00:00  Encrypted/Credentials/v1@X-GSSPROXY:
01/01/1970 01:00:00  01/01/1970 01:00:00  Encrypted/Credentials/v1@X-GSSPROXY:
01/01/1970 01:00:00  01/01/1970 01:00:00  Encrypted/Credentials/v1@X-GSSPROXY:
01/01/1970 01:00:00  01/01/1970 01:00:00  Encrypted/Credentials/v1@X-GSSPROXY:
01/01/1970 01:00:00  01/01/1970 01:00:00  Encrypted/Credentials/v1@X-GSSPROXY:
01/01/1970 01:00:00  01/01/1970 01:00:00  Encrypted/Credentials/v1@X-GSSPROXY:
01/01/1970 01:00:00  01/01/1970 01:00:00  Encrypted/Credentials/v1@X-GSSPROXY: